What Salt Typhoon Reveals About Hidden Software Risk in Critical Infrastructure

Salt Typhoon is a covert, multi-year espionage campaign by a Chinese state-sponsored group, targeting U.S. telecommunications providers and government networks. Its success is rooted in weaknesses that threat reports have characterized as serious supply chain risk.

Once inside, the operators didn’t rely on novel exploits—they used stolen credentials, exploited known vulnerabilities in outdated or unpatched systems, and took advantage of legacy components, often inherited through third-party infrastructure or IT service providers. These were introduced via the software supply chain, for example, through device procurement, vendor updates, or vendor-managed platforms, without effective validation.

The group escalated privileges and moved laterally using “living off the land” techniques, leveraging trusted administrative tools to avoid detection, and sustain access with known backdoors like GhostSPY and remote access trojans such as DeadRAT. Even internal phishing campaigns were more effective because compromised accounts came from within trusted systems. In large telecom networks with tens of thousands of employees and complex vendor ecosystems, these inherited flaws and trusted footholds created ideal conditions for a long-running compromise.

Salt Typhoon continues to present an active threat. In the wake of its exposure, the directive from U.S. Cyber Command is clear: assume compromise. All systems, even those previously considered secure, must now be treated as potentially compromised. That level of operational caution reflects how deep and durable the attackers’ access has become, and how little visibility defenders have into the specific systems they’ve compromised.

Catching up on Salt Typhoon

In our July webinar, we explored how the operation works, how attackers move laterally, blend with legitimate processes, and maintain access by hiding in firmware for over a year.

The scale and duration of this intrusion aren’t signs of advanced zero-days. They reflect unmonitored software and forgotten firmware. Once inside, Salt Typhoon deployed malware to blend with normal traffic, sustain access, and quietly exfiltrate data for months.

For telecom operators, networking vendors, and national infrastructure providers, Salt Typhoon is a reminder that a single compromise can silently persist for months or years. Without continuously monitoring binaries and firmware, attackers can operate undetected, undermine trust in vendor-supplied systems, and potentially disrupt critical services.

Watch the Salt Typhoon analysis webinar

If Log4j Was the Alarm, Salt Typhoon Is the Aftershock

When Log4Shell hit in 2021, security teams raced to identify vulnerable instances of Log4j. But in many environments, especially those involving embedded systems or vendor-supplied firmware, those libraries weren’t visible in SBOMs.

Salt Typhoon exposes that same blind spot at a larger scale, with many devices running firmware that has never been independently validated, including legacy networking equipment still in service for years without review. The software inside these systems is riddled with hidden components: third-party libraries, misconfigurations, and insecure defaults that no one has accounted for.

As we explored in What Software Updates Can Still Get Wrong, patches and upgrades often bring new code, new dependencies, and new vulnerabilities. Without visibility into what actually changed, organizations are flying blind. Salt Typhoon takes full advantage of that.

Most Software Risk Lives Below the Surface

What connects Log4j and Salt Typhoon is the uncomfortable reality that most organizations still don’t know what’s in their software, especially once it’s compiled, inherited from a vendor, or delivered as a black box.

Even teams generating SBOMs may be working from source manifests or package declarations, omitting the compiled libraries and embedded components actually present in production binaries. That disconnect leaves exploitable gaps.

Attackers have figured this out. Rather than looking for what was declared, they're targeting what actually executes.

The response to Salt Typhoon underscores a painful truth: most detection and prevention tools are looking in the wrong places. Endpoint agents, patch management platforms, and SIEMs have missed the compromises because the firmware and operating system components aren’t being actively analyzed, or even inventoried, after deployment. Security teams assume that what was scanned and verified in source code remains valid in the compiled software, even after builds, updates, and vendor modifications. Salt Typhoon shows how dangerous that assumption can be.

Treat Binaries Like First-Class Citizens

Closing this visibility gap means going deeper than traditional scanning. This means analyzing the actual binaries in your environment, not just the build instructions that created them, especially when you don’t have access to the source code.

NetRise gives teams the ability to uncover embedded secrets, hardcoded credentials, and outdated dependencies hiding inside compiled firmware. Our platform detects default passwords, and other dangerous misconfigurations that persist long after deployment. With ZeroLens, teams can map weaknesses in binaries directly to CWE categories and prioritize remediation. And with Trace, they can detect behavioral changes and new risks introduced by updates, even when source code is unavailable.

These insights are critical for incident response, compliance, and long-term software assurance, especially in sectors where systems are difficult to patch or replace.

Salt Typhoon Made the Risk Clear. Compliance Is Catching Up.

Government agencies and military networks are among the hardest hit, prompting urgent reviews of how firmware is sourced, secured, and monitored across defense and telecom systems. These sectors rely heavily on hardware and software vendors, and in many cases, visibility into the software inside those devices is often limited to what the vendor chooses to disclose, leaving organizations without independent confirmation of software integrity.

In sectors like healthcare, telecom, and energy, many systems in use today rely on legacy software that hasn’t been reviewed in years, a reality reflected by the slow pace of modernizing those systems. SBOM adoption, while growing (particularly in healthcare under FDA influence), remains inconsistent. And without standardized tooling or supply chain transparency, software components in critical infrastructure can go undocumented from procurement to deployment.

As reported by ITPro, U.S. Cyber Command advises that “all US forces must now assume their networks are compromised” in the aftermath of Salt Typhoon, a shift that reflects just how deep and undetected these intrusions went.

As regulatory frameworks like EO 14028, NIST CSF 2.0, and the EU Cyber Resilience Act take hold, we can no longer overlook the need for visibility into these systems. Binary analysis enables teams to meet those mandates with confidence and uncover risk where traditional tools fall short.

Final Takeaways

Log4j revealed the dangers of invisible software components.

Salt Typhoon shows how attackers exploit firmware blind spots to maintain long-term access.

Binary analysis, ZeroLens CWE mapping, and Trace build comparison give organizations the tools to detect, prioritize, and respond to software supply chain risk, before attackers take advantage of it.

Want to know what’s really in your software?

NetRise gives you the visibility to validate what’s there, and what’s changed.

Watch the full webinar

Schedule a demo