Common Threads, Shared Failures: Final Thoughts on the Typhoon APT Threat

Ymir Vigfusson

May 29, 2025

If you’ve followed our deep dives on Volt, Salt, and Flax Typhoon, you’ve seen how today’s most dangerous adversaries don’t breach networks with ransomware or flashy exploits; they inherit trust. They operate within the permissions, credentials, and tools your environment already trusts. And once they’re in, your systems treat them like insiders. Because, technically, they are.

This final post in the Typhoon series stitches together what we’ve learned and reframes the core question. Not "How do we keep them out?" but: "How do we prove every command is legitimate?"

The Shared Lifecycle: Land, Gather, Move

Each Typhoon actor follows their own playbook while sharing many similarities with their approach. The goal is to get in, get intelligence, and get lateral movement.

Volt Typhoon embedded itself inside telecom, energy, and defense infrastructure, living off the land using PowerShell, WMI, and SOHO routers. They stayed silent, evaded detection, and waited for the right geopolitical moment.

Salt Typhoon focused on long-term espionage. It used spear-phishing, supply chain infiltration, and credential theft to build redundant, persistent access—targeting defense contractors, telecoms, and their upstream vendors.

Flax Typhoon took a broader approach, compromising cloud providers, public sector systems, and financial firms by stealing session cookies, hijacking OAuth tokens, and moving laterally across environments without triggering alerts.

Different APTs, different targets, but the same fatal flaw: every successful campaign exploited the assumption that a valid session means a valid user.

A Note on Brass Typhoon

While this series focused on the Volt, Salt, and Flax groups, it’s worth noting that Brass Typhoon (also linked to state-aligned cyber espionage) has recently emerged with similar tactics. Like the others, they exploit session trust, identity sprawl, and endpoint blind spots to persist inside trusted environments. Their inclusion further reinforces the common thread we’ve seen throughout: these attackers don’t need new malware—they weaponize trust.

Unlike the others, Brass Typhoon is known for blending traditional cyber-espionage with disruptive operations, often leveraging social engineering at scale and more aggressively targeting operational technology (OT) environments. Their inclusion further reinforces the common thread we’ve seen throughout: these attackers don’t need new malware because they weaponize trust.

The Inherited Session Problem

Let’s break down the recurring failure mode:

Stage Technique Why It Works
Initial Access RDP exposure, VPN compromise, spearphishing Public-facing, often unmonitored, uses trust
Recon Browser token extraction, Active Directory queries Legitimate tools, rarely flagged
MFA Session Hijack Pass-the-token, session cookie reuse No login alerts because the session authentication was done by an authorized person
Lateral Movement PowerShell remoting, PsExec, WMI Looks like admin activity
Persistence Scheduled Tasks, registry run keys Appears native, signed binaries

These attackers aren’t sidestepping your controls, they’re abusing your assumptions.

Session Integrity Is a Lie

We’ve all designed systems where login equals trust. But here’s the uncomfortable truth: once an attacker hijacks a valid session, your controls go blind.

Want proof?

mstsc.exe /v:corp-dc01

Looks like an IT admin initiating a remote desktop session. But what if it’s an attacker reusing a stolen VPN token on your machine to pivot into a domain controller? The session logs show a valid user from a valid source IP. Your SIEM and EDR remain quiet. Unless you can prove who initiated that session or who is generating commands, you don’t know.

Identity tools authenticate access at the start of the login session. Once authenticated, the session is active until an event that triggers additional authorization/authentication, a session timeout, or a logout event. In other words, the authentication has no way to verify how that session is used even seconds after successful authentication. 

Why Keystrike Is Different

Keystrike doesn’t assume a session is valid. It forces every command to prove it came from physical input on a trusted device.

Trust Model Assumes Misses Failure Mode
Traditional IAM Login = Identity Token theft, cookie replay Attacker inherits full access
Behavior Analytics Anomaly = Bad Low-noise attacker behavior High false negatives
Keystrike Verified physical input = Authentic Nothing Blocked at the source

Keystrike’s Verification Pipeline:

  1. Keyboard or mouse input is cryptographically signed by the workstation.
  2. Keystrike passes the attestation to the server.
  3. The server discards any input missing the attestation.

No attestation = no command. It’s that simple. The server withholds any input until it receives proof that the input was physically made on the workstation.

This isn't just continuous authentication because Keystrike uses zero trust principles and assumes the session could be compromised without attestation. 

What This Means for Security Teams

If you’re responsible for protecting critical infrastructure, healthcare systems, telecom networks, or defense supply chains, you already know the stakes. You’ve deployed MFA. Hardened VPNs. Tuned EDR and SIEM. Trained staff to investigate anomalies.

But it’s not enough. Because attackers like the Typhoon APT groups don’t break past your defenses—they shadow your legitimate users as they walk right through them.

The fix isn’t another alert or detection model. It’s a new root of trust:

Can you prove who’s behind every command that runs in your environment?

If not, your attack surface includes every command in every trusted session.

Final Words: It’s Time to Rethink Where Trust Begins

The Typhoon actors succeeded not because you missed a patch or forgot a firewall rule, but because their activity looked like your legitimate users’ activity. They blended into your trust model.

Keystrike gives you the high-fidelity signal your team needs to attest:

  • Proof of presence
  • Proof of intent
  • Cryptographic verification of every action

No assumptions. No inherited trust. No silent failures. When trust is your battleground, continuous, intent-based  authenticity is your strongest defense.

Test your environment: Pick a random admin session. Ask yourself—do you know who’s behind that keyboard right now? With Keystrike, you can. Schedule a demo or test your session integrity in minutes at Keystrike.com.

Deploy Keystrike in 20 Minutes

Try Keystrike in Your Environment for 30 Days