Salt Typhoon: How China Hacked the World's Largest Telecoms — And How It Could Have Been Detected

For years before anyone noticed, Chinese hackers were sitting inside AT&T, Verizon, and T-Mobile networks — and listening. They read government officials’ messages, watched law enforcement requests come in, and exfiltrated customer records at will. When the breach finally came to light, the FBI called it “the worst telecom hack in American history.”

TL;DR

Salt Typhoon is a Chinese APT active since 2019, linked to China’s Ministry of State Security

The group breached 200+ telecom companies across 80+ countries, including AT&T, Verizon, and T-Mobile

They accessed the US government’s lawful intercept platform (CALEA) — watching who law enforcement was targeting

Attack chain: edge device exploitation → persistence → packet capture → exfiltration

Detection was hard but not impossible — network traffic anomalies and log gaps were the tell

Why This Matters to You

Salt Typhoon is not a US-only problem. By August 2025, the FBI confirmed the campaign had reached over 80 countries. European telecoms were targeted in October 2025. Canadian providers were breached via Cisco vulnerabilities. If your organization runs any telecom infrastructure, cloud services, or internet-facing Cisco devices, you are a potential target.

From a blue team perspective, this campaign is an invaluable case study: how do you detect an APT specifically engineered to be invisible?

Who Is Salt Typhoon?

Salt Typhoon (also tracked as OPERATOR PANDA, RedMike, UNC5807, GhostEmperor) is a Chinese state-nexus APT that has been active since at least 2019. The NSA, FBI, CISA, and 12 partner nations formally attributed the campaign to three Chinese technology companies providing cyber capabilities to China’s Ministry of State Security (MSS) and the People’s Liberation Army (PLA).

What sets Salt Typhoon apart from many other threat actors is their operational patience. They don’t deploy ransomware or conduct smash-and-grab data theft. They sit inside networks for months or years, quietly collecting intelligence.

The Attack Chain — Step by Step

Stage 1: Initial Access via Edge Devices

Salt Typhoon doesn’t target end-user workstations — they go straight for network infrastructure: firewalls, routers, and VPN gateways. These devices are attractive targets because they:

Are directly internet-facing
Process all network traffic
Often go unpatched for months or years
Generate fewer logs than servers

The group exploited known vulnerabilities in Cisco IOS XE devices and Citrix NetScaler Gateway appliances. One example: CVE-2025-5777 (Citrix NetScaler), which allowed unauthenticated remote code execution.

# Identifying exposed Cisco devices (defender's perspective — asset inventory)
shodan search "cisco IOS XE" country:US org:"AT&T"

# Check firmware version against known vulnerable releases
# Cisco IOS XE WebUI exploit indicator — look for this in access logs:
grep "webui/logoutconfirm.html" /var/log/nginx/access.log

Stage 2: Establishing Persistence — GhostSpider

After gaining access, the group deployed GhostSpider — a modular, fully in-memory backdoor. What makes it so difficult to detect:

No files on disk — runs entirely in memory, invisible to file-based AV
DLL hijacking — loads inside a legitimate Windows process
Modular architecture — each capability loaded on demand, minimizing footprint
Encrypted C2 communications — blends into normal HTTPS traffic

Stage 3: Passive Network Interception — JumbledPath

This is Salt Typhoon’s tactical signature. Rather than stealing files or databases, they deployed JumbledPath:

Written in Go (fast, cross-platform)
Captures raw network packets directly on Cisco devices
Intercepts all traffic — calls, messages, metadata
Clears its own log entries after execution
Routes traffic through jump-hosts to complicate attribution

This allowed them to read communications before encryption or after decryption — directly at the telecom infrastructure layer.

Stage 4: CALEA — The Lawful Intercept System Was Compromised

Perhaps the most alarming revelation: Salt Typhoon gained access to the CALEA system (Communications Assistance for Law Enforcement Act). This is the US legal infrastructure that allows law enforcement to conduct court-authorized wiretaps.

The implications: the attackers could see:

Which individuals law enforcement was actively investigating
What data had been requested from telecoms
Private communications of US government officials

Blue Team: Detection Opportunities

Here’s the critical question: what went wrong with detection? And more importantly: what could have been done differently?

Detection Point 1: Abnormal Management Interface Requests

# Look for this anomaly in Cisco syslog / SIEM
# Unusual HTTP requests to IOS XE management interface

# Splunk query
source="cisco:ios"
| where uri_path LIKE "%/webui/%"
| stats count by src_ip, uri_path
| where count > 10
| sort - count

In a normal environment, the management interface should never receive requests from unknown external IPs. Every such alert warrants investigation.

Detection Point 2: Unusual Process Loading (DLL Hijacking)

GhostSpider loads through legitimate processes. Detection requires behavioral process monitoring — what child processes does an application spawn, which DLLs does it load.

# Sigma rule for suspicious DLL loading
title: Suspicious DLL Load from Unusual Path
logsource:
    product: windows
    category: image_load
detection:
    selection:
        ImageLoaded|contains:
            - '\AppData\Local\Temp\'
            - '\ProgramData\'
        Image|endswith:
            - '\svchost.exe'
            - '\lsass.exe'
    condition: selection
level: high
tags:
    - attack.defense_evasion
    - attack.T1574.002

Detection Point 3: Outbound Connections From Edge Devices

A Cisco router or firewall should not initiate connections to external servers — it only forwards traffic for others. If an edge device starts creating outbound TCP connections to unknown IPs, that’s a strong indicator of compromise.

# Netflow analysis: detect outbound connections from edge devices
# Look for connections that aren't normal management traffic (NTP, DNS, syslog)

# Using Zeek/Bro logs:
cat conn.log | zeek-cut id.orig_h id.resp_h id.resp_p proto duration bytes \
  | awk '$1 == "10.0.0.1"' \        # edge device IP
  | awk '$5 > 300' \                 # connections longer than 5 minutes
  | sort -k6 -rn                     # largest data transfers first

Detection Point 3b: Analyze Suspicious Payloads and Hashes

When hunting for GhostSpider artifacts, you may encounter encoded payloads, suspicious file hashes, or obfuscated commands in memory dumps. Our Security Decoder automatically identifies hash types (MD5, SHA-256, NTLM), decodes Base64 and hex-encoded payloads, and flags PowerShell obfuscation patterns — all client-side, nothing leaves your browser.

Detection Point 4: Log Gaps — JumbledPath Erases Its Tracks

JumbledPath is designed to wipe its activity from Cisco device logs. This creates a paradoxical signal: missing logs are themselves an alert.

If your Cisco device normally produces 500 log lines per hour and suddenly produces 50, something is wrong.

# Detect devices that have stopped sending logs
# Splunk query: devices with significantly reduced log volume

| tstats count WHERE index=network_devices
    by host _time span=1h
| streamstats window=24 current=f avg(count) as avg_count by host
| where count < avg_count * 0.2
| table host, count, avg_count

MITRE ATT&CK Mapping

Technique	MITRE ID	Detection Method
Network Device CLI	T1059.008	Cisco AAA logs, CLI command auditing
Traffic Duplication	T1020.001	Netflow anomalies
DLL Side-Loading	T1574.002	EDR process behavior monitoring
Indicator Removal	T1070	Log volume drop alerts
Network Sniffing	T1040	Promiscuous mode detection
Multi-hop Proxy	T1090.003	Unusual connection chains

What You Can Do Today

Immediate Actions (This Week)

Inventory all edge devices — do you know every Cisco, Juniper, and Palo Alto device in your environment? Are they running the latest firmware?
Check Cisco IOS XE versions — CVE-2023-20198 and related critical vulnerabilities were exploitable for months before most customers patched

Enable configuration change monitoring — if a router config changes, you need to know immediately:

# Using Oxidized for automated config comparison
oxidized reload
# Review changes with git diff
git -C /var/lib/oxidized/repos/network.git log --oneline -10

Enable Netflow/IPFIX on all edge devices — without network traffic visibility, you cannot detect anomalies
Segment management traffic — the management interface should only be reachable from a dedicated out-of-band management network, never from the public internet

Longer-Term Improvements

Zero Trust for network devices — every management connection requires MFA, even internal ones
Network Detection and Response (NDR) — a solution that analyzes network behavior in real time, not just logs
Regular penetration tests targeting edge device configurations specifically
Active threat hunting for MITRE ATT&CK T1040/T1020 activity patterns

The Bigger Picture

Salt Typhoon succeeded in part because telecom infrastructure is built on trust. Internal network traffic isn’t supposed to be dangerous. Edge devices aren’t supposed to be attack vectors.

That mental model is obsolete. Every network component is a potential attack surface, and each should have:

Least-privilege access
Complete audit logging
Regular configuration validation
Behavior-based monitoring

Salt Typhoon is not just a telecom problem. It’s a warning for every organization that assumes their network’s internal components are inherently safe.

If you’re actively hunting for Salt Typhoon indicators, our SOC Log Analyzer can parse Cisco syslog entries, Netflow logs, and generic network log lines — paste raw log data and get structured analysis instantly.

Zero Trust vs. Real Attacks — how a Zero Trust architecture would have limited Salt Typhoon’s lateral movement
Wazuh Threat Hunting — practical guide to detecting network anomalies with open-source SIEM
C2 Without Owning a C2 — how APT groups hide C2 traffic inside legitimate network flows