When Valid Credentials Don't Mean "Authorized": What the Salt Typhoon Breach Teaches Critical Infrastructure Defenders

By Norris CornellIAM  | SCADA CybersecurityDecember 19, 2024

Executive Summary

In October 2024, U.S. authorities confirmed that Chinese state-sponsored actors—tracked as Salt Typhoon—had compromised at least nine major U.S. telecommunications providers. The breach, which persisted for over a year undetected, accessed call records from more than one million users, intercepted private communications of high-profile political figures, and compromised CALEA lawful intercept systems designed for law enforcement use.

This wasn't a sophisticated zero-day exploit. It was something more fundamental—and more dangerous.

Salt Typhoon succeeded because modern telecommunications infrastructure makes the same trust assumption that plagues industrial control systems, cloud services, and satellite networks:

Valid input equals legitimate intent.

This article examines what actually happened in the Salt Typhoon breach, why detection failed for so long, and what it reveals about a systemic vulnerability pattern I call "Inputs Lie"—a failure mode that extends far beyond telecommunications into every sector of critical infrastructure.

Part 1: The Breach Nobody Saw Coming

Timeline and Scope

October 2024: FBI and CISA publicly confirm PRC state-sponsored compromise of U.S. telecommunications infrastructure.

Not for days. Not for weeks. For over a year.

The scope of compromise included:

• At least 9 confirmed U.S. telecommunications providers including Verizon, AT&T, T-Mobile, Lumen Technologies, and others

• Call detail records (metadata) from 1+ million users

• Content interception of fewer than 100 individuals including Donald Trump, JD Vance, Harris campaign staff, and congressional personnel

• Access to CALEA lawful intercept systems—the very infrastructure designed to support law enforcement surveillance

• Global reach extending to 80+ telecommunications companies across dozens of countries

By January 2025, the U.S. Treasury Department sanctioned Sichuan Juxinhe Network Technology Co., a Chinese firm identified as providing direct support to Salt Typhoon operations.

What Made This Different

This wasn't a typical smash-and-grab intrusion. Several factors made Salt Typhoon particularly dangerous:

Multi-Year Persistence: Active presence in networks from approximately 2022-2023, discovered only in September 2024.

Living-Off-the-Land Techniques: Attackers used legitimate administrative tools already present in telecom environments—SSH, SNMP, Telnet, standard network management utilities. No custom malware. No exotic exploits.

Strategic Intelligence Value: Access to lawful intercept target lists revealed which individuals were under U.S. surveillance, allowing adversaries to identify compromised intelligence operations and operational security failures.

Infrastructure Mapping: Visibility into network topology, routing behavior, and interconnections between telecommunications providers and critical infrastructure sectors.

The implications extend far beyond telecommunications. When adversaries can monitor who talks to whom, when, how often, and under what legal authority, they're not just stealing communications—they're mapping the nervous system of critical infrastructure.

Part 2: The Technical Attack Chain

Based on public government advisories and threat intelligence reporting, the attack progressed through four distinct phases:

Phase 1: Initial Access via Internet-Facing Vulnerabilities

Salt Typhoon exploited known vulnerabilities in internet-facing network devices:

Ivanti Connect Secure VPN vulnerabilities:

• CVE-2023-46805 (Authentication bypass)

• CVE-2024-21887 (Command injection)

Cisco vulnerabilities in router and security appliances (specific CVEs not publicly confirmed but consistent with advisory patterns)

Why These Worked:

Telecommunications providers face unique patching challenges:

• 24/7 uptime requirements for public safety communications

• Complex interdependencies between network elements

• Vendor-specific maintenance windows

• Regulatory constraints on service interruptions

These constraints create windows where known vulnerabilities remain exploitable for extended periods.

Phase 2: Credential Theft and Lateral Movement

Once inside the network perimeter, attackers focused on credential harvesting:

Configuration Files: Network devices often store credentials in configuration backups, particularly for automation and orchestration systems.

Management Protocols: SSH keys, SNMP community strings, and administrative passwords allowed movement between network segments.

Trust Relationships: Telecom networks are designed with implicit trust between management systems. Once attackers had management-plane credentials, lateral movement looked like routine administration.

Critical Insight: The attackers didn't need to "break in" repeatedly. Valid credentials granted ongoing access that appeared completely legitimate to security monitoring systems.

Phase 3: Strategic Network Visibility

With management-plane access established, Salt Typhoon gained visibility into:

BGP Routing Tables: Border Gateway Protocol routing information revealed traffic paths, peering relationships, and interconnections to other networks and critical infrastructure.

Network Topology: Complete understanding of network architecture, including redundant paths, backup systems, and points of interconnection.

Lawful Intercept Target Lists: Perhaps most significantly, access to CALEA systems revealed which phone numbers and individuals were under active U.S. law enforcement surveillance.

Important Clarification: There is no confirmed evidence that Salt Typhoon performed large-scale BGP route manipulation or traffic hijacking. The primary risk was visibility and intelligence collection, not confirmed traffic redirection. However, the capability to understand routing behavior creates the foundation for future active attacks.

Phase 4: CALEA System Compromise

The Communications Assistance for Law Enforcement Act (CALEA) requires telecommunications carriers to design systems capable of supporting lawful surveillance when presented with court orders.

How CALEA Systems Work:

• Carriers maintain isolated infrastructure for handling lawful intercept requests

• Law enforcement submits court orders specifying targets

• Systems capture content and/or metadata for specified communications

• Access is supposed to be tightly controlled and audited

What Salt Typhoon Accessed:

Public statements from CISA and the FBI confirm that information "subject to U.S. law enforcement requests pursuant to court orders" was copied. This means attackers:

1. Identified which individuals were under active surveillance

2. Potentially accessed the same intercepted communications

3. Could have modified or deleted evidence of their own activities

4. Gained intelligence about U.S. counterintelligence operations

The Strategic Implications:

When adversaries know who's being watched, they can:

• Identify compromised agents or operations

• Adjust operational security practices

• Feed disinformation through surveilled channels

• Map U.S. intelligence priorities

This transforms a surveillance capability designed for law enforcement into a counterintelligence goldmine for nation-state adversaries.

Part 3: Why Detection Failed

Salt Typhoon remained undetected for 1-2 years. Understanding why reveals systemic challenges in defending complex, operational infrastructure.

Challenge 1: Legitimate Tools, Illegitimate Intent

The Problem: Attackers used standard administrative tools already present in every telecom environment:

• SSH for remote management

• SNMP for device monitoring

• Network management platforms

• Backup and configuration tools

Why It Matters: Security monitoring systems are tuned to detect anomalous behavior. When attackers use legitimate tools with valid credentials, the activity appears completely normal.

Detection Gap: Traditional signature-based or IOC-focused detection cannot identify this threat. The "signature" is normal administrative activity.

Challenge 2: Credential-Based Trust Without Continuous Verification

I've watched this pattern for 20 years across operational environments: We trust inputs that look right.

Telecommunications systems (like most critical infrastructure) make a fundamental assumption:

Valid credential + Valid protocol format = Trusted action

What systems DON'T verify:

• Is this the same device that authenticated earlier?

• Is this user in their normal geographic location?

• Does this activity match historical behavior patterns?

• Should this administrative action be happening at this time?

• Has the user's risk context changed since initial authentication?

The credential was valid. The session was valid. The protocol format was correct.

But the intent was malicious.

This is what I call the "Inputs Lie" problem.

Challenge 3: Management Networks as Low-Visibility Environments

Operational Priority: Customer-facing systems receive intense monitoring because outages directly impact revenue and service availability.

Management Plane Reality: Management networks, CALEA systems, and administrative infrastructure often receive less intensive monitoring because:

• They're lower traffic volume

• They're assumed to be "trusted" environments

• Operational teams focus on availability, not necessarily security

• Audit log retention may be shorter

Result: Attackers operated in the least-monitored portions of the network—exactly where strategic intelligence lives.

Challenge 4: Multi-Vendor Complexity

Modern telecommunications networks span:

• Dozens of equipment vendors

• Hundreds or thousands of network elements

• Multiple management systems with different logging formats

• Disparate security tooling with limited integration

Correlation Challenge: Detecting an attack chain that moves from:

Vendor A's VPN appliance →

Vendor B's router →

Vendor C's management system →

Vendor D's CALEA platform

…requires log correlation across incompatible formats, disparate time stamps, and systems that may not even share the same authentication infrastructure.

Even mature security operations centers struggle with this level of complexity in real-time.

Part 4: The "Inputs Lie" Pattern Across Critical Infrastructure

Salt Typhoon exposed a vulnerability pattern that extends far beyond telecommunications. I call it "Inputs Lie" because systems across every sector of critical infrastructure make the same dangerous assumption:

If the input is formatted correctly and authenticated properly, it must be legitimate.

Industrial Control Systems (ICS/OT)

Modbus Protocol Example:

A Modbus command to set a register value looks like this:

Function Code 0x06 (Write Single Register)

Register Address: 0x0064

Value: 0x1234

If the format is valid and arrives from an "authorized" network segment, the PLC executes it.

What Modbus Doesn't Verify:

• Should this command source be sending write commands?

• Is this value within expected operational parameters?

• Does this command timing match normal operational patterns?

• Has the system state changed since initial authentication?

Why the Purdue Model Mattered:

Network segmentation (the Purdue Model) was designed to create trusted zones. If you're inside Level 2 (Supervisory Control), you're assumed to be legitimate.

Until someone steals credentials and bypasses your segmentation.

Now you're facing the same problem Salt Typhoon exploited: valid credentials create a permission structure that doesn't ask ongoing questions about intent.

Not because ICS operators don't know better. Because replacing a 20-year-old PLC means downtime that impacts production, potentially violates EPA emissions permits, or creates safety hazards. The operational constraints are real.

Cloud and SaaS Environments

Session Token Problem:

Modern web applications issue session tokens after successful authentication:

User authenticates → Receives JWT or session cookie →

Token valid for 2-24 hours → Full access granted

What Happens When Tokens Are Stolen:

An attacker with a stolen session token gains full access until expiration. The system trusts the token, not the session context.

What's NOT Verified:

• Geographic location (user in Virginia, then Beijing 10 minutes later)

• Device fingerprint (session token used from new device)

• Behavioral patterns (unusual API calls, bulk data downloads)

• Time-based context (access during unusual hours)

Cloud providers are increasingly implementing continuous verification, but the default model is still: valid token = trusted access.

GNSS and Timing Infrastructure

GPS Spoofing:

GPS receivers trust signals that match expected format:

C/A code structure matches →

Navigation message format valid →

Signal timing appears correct →

Position solution accepted

What's Missing: Cryptographic authentication of civilian GPS signals.

Result: Receivers accept spoofed signals that "look right" even when they're completely fabricated.

Critical Infrastructure Impact:

• Power grid timing synchronization

• Financial trading timestamps

• Cellular network synchronization

• Emergency response coordination

All depend on GPS signals that can be spoofed without cryptographic verification.

The Cross-Domain Pattern

Same core problem. Different implementations:

Domain	Trusted Input	Missing Verification
Telecom	Valid credentials	Device identity, behavior, timing
ICS/SCADA	Correct protocol format	Command source legitimacy, operational context
Cloud	Valid session token	Geographic consistency, device fingerprint
GNSS	Signal structure match	Cryptographic signal authentication
BGP Routing	Valid route announcement	Origin verification, path validation

In every case: Format compliance ≠ Trust

Part 5: What Defense Actually Looks Like

The good news? The defenses exist. Salt Typhoon's access was detectable—just not with security models built for 1990s threat assumptions.

Defense Layer 1: Behavioral Analytics and Anomaly Detection

What This Catches:

"Admin account logged in from Beijing 10 minutes after accessing from Virginia"

• Detection: Physically impossible travel

• Response: Force re-authentication, alert SOC

"Session token being used from device that's never touched the network before"

• Detection: Device fingerprinting + historical pattern analysis

• Response: Terminate session, require device registration

"Bulk data export from CALEA system at 3 AM on Sunday"

• Detection: Timing + volume + system criticality scoring

• Response: Block action, alert management immediately

Implementation Reality:

This requires:

• SIEM or behavioral analytics platform

• Baseline of normal behavior (3-6 months minimum)

• Tuning to reduce false positives

• Integration with authentication systems for automated response

OT/ICS Consideration: Behavioral analytics work for management networks and supervisory systems but can't add latency to real-time control loops. Deploy at network boundaries, not inline with control commands.

Defense Layer 2: Risk-Based Continuous Authentication

The Shift:

From: "Authenticate once, trust for session duration"To: "Continuously evaluate risk and re-challenge when needed"

Implementation:

Initial Login: Username + Password + MFA

├─ Low Risk Action (view reports): No re-auth needed

├─ Medium Risk (config change): Require MFA every 30 min

└─ High Risk (CALEA access): Fresh MFA + manager approval

Risk Factors Evaluated:

• Geographic location and velocity

• Device fingerprint and trust status

• Time of day and day of week

• Type of resource being accessed

• Recent security events or threat intelligence

Example: A user who normally works 9 AM - 5 PM EST from a company laptop suddenly tries to access CALEA systems at 2 AM from an unrecognized device in Southeast Asia.

Response: Deny access, force full re-authentication with manager approval, alert security team.

Defense Layer 3: Device Identity and Fingerprinting

The Problem Salt Typhoon Exploited:

Valid credentials worked from any device. There was no binding between "this user" and "this specific device."

Modern Approach:

User Authentication: Who you are

Device Authentication: What you're using

Context Verification: Where you are + When you're accessing

Implementation:

• Certificate-based device authentication

• Hardware-backed TPM or secure enclave verification

• Device posture assessment (patching status, EDR presence)

• Deny access from unregistered or non-compliant devices

Even with stolen credentials, attackers can't access systems from their own infrastructure.

Defense Layer 4: Immutable Audit Logging

Salt Typhoon's Advantage:

With admin credentials, attackers could potentially delete or modify logs that recorded their activities.

Solution: Write-Once, Verified Logging

Architecture:

Production Network

    ↓

Log Collection (real-time streaming)

    ↓

Write-Once Storage (separate network segment)

    ↓

Cryptographic Verification (hash chain or blockchain)

Key Requirements:

• Logs streamed to separate network (attacker can't reach it)

• Write-once storage (immutable, can't be deleted)

• Cryptographic verification (tampering is detectable)

• Separate authentication (admin creds don't grant log access)

Result: Even with complete network compromise, attackers can't erase evidence of their activities.

Defense Layer 5: Zero Trust for OT/ICS

The Challenge:

You can't add authentication delays to real-time control commands. A Modbus write to a PLC needs to complete in milliseconds, not seconds.

The Solution:

Zero Trust doesn't mean "authenticate every command."It means "trust nothing, verify everything—at the right layer."

OT-Viable Zero Trust Architecture:

Layer 1: Network Segmentation + Enforcement

• Microsegmentation at the firewall/switch level

• Default deny between zones

• Explicit allow rules for known-good traffic patterns

Layer 2: Command Verification (NOT Authentication Delay)

Control Command Sent

    ↓

Network Tap (zero latency)

    ↓

Parallel Verification System (out-of-band)

    ↓

Alert if: Unknown source / Invalid value / Wrong timing / Unexpected sequence

Layer 3: Continuous Monitoring

• Protocol analysis for format compliance

• Statistical anomaly detection for value ranges

• Sequence validation for operational logic

• Response time monitoring for latency injection

Critical Point: Verification happens in parallel, not inline. Real-time control commands aren't delayed, but unauthorized or anomalous commands trigger immediate alerts and forensic capture.

This works because:

• No latency added to control loops

• Defense operates at network/visibility layer

• Doesn't require changes to legacy PLCs or protocols

• Scales to existing infrastructure

Part 6: The Strategic Reality

When Chinese APT groups can:

• Sit undetected in telecommunications networks for 1-2 years

• Access lawful intercept systems designed for law enforcement

• Learn which of their agents are under U.S. surveillance

• Map critical infrastructure interconnections at the network topology level

The question isn't "Can they compromise our systems?"

The question is: "When they activate those capabilities, will we detect it fast enough to respond?"

Understanding the Adversary Model

Salt Typhoon represents a fundamentally different threat:

Traditional Cybercrime:

• Motivated by financial gain

• High volume, low sophistication

• Noisy, detectable behavior

• Short dwell time (hours to days)

Nation-State APT (Salt Typhoon Model):

• Strategic intelligence collection

• Unlimited resources and patience

• Stealthy, blends with legitimate activity

• Multi-year persistence campaigns

• Living-off-the-land techniques

For Critical Infrastructure Defenders:

This means:

• Assume breach (it may have already happened)

• Focus on detection and response time, not just prevention

• Prioritize visibility into management planes and "trusted" systems

• Implement continuous verification, not just perimeter defense

• Prepare for attackers who understand your operational constraints

Part 7: For Critical Infrastructure Defenders

If your security model assumes:

• Network location = authorization → Zero Trust challenges this

• Valid credentials = legitimate user → Continuous verification required

• Protocol format = trusted source → Behavioral analysis needed

• One-time authentication = ongoing trust → Risk-based re-authentication

You're defending against 1990s threats with 1990s assumptions.

Salt Typhoon proved that nation-states aren't exploiting technology—they're exploiting trust assumptions.

The Hard Questions to Ask Your Team

1. If an attacker stole admin credentials today, how long would it take us to detect unauthorized access?

   • Hours? Days? Weeks? Never?

2. Can we correlate security events across our multi-vendor infrastructure?

   • Do our logs even share a common timestamp source?

3. Do we monitor management plane activity as intensively as customer-facing systems?

   • When was the last time someone reviewed CALEA system access logs?

4. Can attackers with admin credentials delete or modify their own audit trails?

   • Are our logs truly immutable and independently verified?

5. Do we re-verify user identity and intent after initial authentication?

   • Or do valid credentials grant unlimited access until session expiration?

These aren't comfortable questions. But Salt Typhoon proves they're necessary ones.

Part 8: The Bottom Line

Salt Typhoon didn't break encryption. They didn't invent new attack vectors. They didn't need to exploit zero-days.

They just operated inside systems that equate:

Valid input = Legitimate intent

That's the vulnerability.

And if you're securing critical infrastructure—telecommunications, energy, water, transportation, or industrial control systems—it's probably in your environment right now.

What's Coming Next

This is Part 1 of the "Inputs Lie" series examining trust failures across critical infrastructure.

Part 2 will examine:

• BGP routing trust models and why route origin validation isn't deployed

• CALEA governance and the security implications of lawful intercept infrastructure

• ICS protocol trust assumptions (Modbus, DNP3, TriStation)

• Cloud session security and the limitations of token-based authentication

• Practical implementation of continuous verification in OT environments

Part 3 will provide actionable guidance:

• Risk-based architecture for OT Zero Trust

• Log correlation strategies for multi-vendor environments

• Behavioral analytics tuning for critical infrastructure

• Incident response for long-dwell-time adversaries

About the Author

Jack Cornell is a Controls Management Specialist with nearly 20 years of electronics technician experience and a Master's degree in SCADA Cybersecurity from Wilmington University. He previously held DoD Secret clearance and has been a BSides Delaware volunteer and organizer since 2015.

Jack's research focuses on the convergence of telecommunications, cloud services, and industrial control systems security, with emphasis on how adversaries exploit trust assumptions in critical infrastructure protocols. His work bridges traditional IT security with the operational realities of OT environments.

Connect: CornellSecurity.com

References and Further Reading

Government Sources

1. FBI and CISA Joint Statement (November 13, 2024)

   
   

   "People's Republic of China (PRC) Targeting of Commercial Telecommunications Infrastructure"

   
   

   https://www.cisa.gov/news-events/cybersecurity-advisories

2. FCC Fact Sheet (December 4, 2024)

   
   

   "Implications of Salt Typhoon Attack and FCC Response"

3. U.S. Treasury Department (January 2025)

   
   

   "Sanctions on Sichuan Juxinhe Network Technology Co."

4. CISA Advisory (December 2024)

   
   

   "Enhanced Visibility and Hardening Guidance for Communications Infrastructure"

Technical Reporting

5. Wall Street Journal (October 2024)

   
   

   "Chinese Hackers Believed to Have Targeted Trump, Vance Cellphones"

6. New York Times (November 2024)

   
   

   "U.S. Investigating Breach of Telecommunications Systems by Chinese Hackers"

7. New Lines Institute (October 2024)

   
   

   "2024: When China's Salt Typhoon Made Cyberspace Tidal Waves"

8. Mandiant Threat Intelligence (2024)

   
   

   "APT41 and Chinese Cyber Espionage Operations"

Industry Analysis

9. NIST Cybersecurity Framework

   
   

   "Zero Trust Architecture" (SP 800-207)

10. ICS-CERT Advisories

    
    

    Industrial Control Systems security advisories and recommended practices

Discussion

What patterns are you seeing in your critical infrastructure that rely on format compliance instead of intent verification?

Are you implementing continuous verification in your OT environments? What challenges have you encountered?

How long would it take your team to detect Salt Typhoon-style activity in your management networks?

I'm actively researching these questions and would value perspectives from practitioners in telecom, energy, water, and industrial sectors.

Connect on LinkedIn or drop a comment on CornellSecurity.com