Ymir Vigfusson
May 13, 2025
You’ve probably adopted some Zero Trust principles. You verify identities, enforce MFA, and monitor endpoints. Maybe you segment your network and audit access policies regularly. These are all smart moves. But if you’ve ever faced a breach that started with a valid login and somehow spiraled into a domain-wide compromise, you’ve already encountered the fatal assumption: that a valid session means a trusted user.
Flax Typhoon thrives on that gap. This advanced persistent threat sidesteps traditional controls by living off the land - using legitimate credentials, hijacked sessions, and tools already installed in your environment. In this walkthrough, we’ll show how they operate, where your current defenses fall short, and why verifying session authenticity - not just identity - the missing link.
Let’s put this in context. Flax Typhoon didn’t appear overnight. Their tactics matured over time, evolving with the industry’s defenses.
They aren't smash-and-grab operators. Their objective is to stay hidden, escalate only when needed, and move through your environment like a ghost. If you’ve reviewed incident timelines that show weeks of undetected internal access - this is the kind of adversary you’re dealing with.
Flax Typhoon doesn’t waste effort. They target organizations where stealth and strategic access matter most. If your organization operates critical infrastructure, handles proprietary data, or has geopolitical relevance - you’re in their scope.
Here’s where we’ve seen them operate:
Regionally, they focus on North America, Western Europe, and East Asia - often exploiting local gaps in regulatory or logging maturity. CISA put out a joint advisory detailing some of the methods and targets that the Typhoon APT groups have exploited. The groups specialize in targeting sensitive, and air-gapped systems.
If you’ve got machines that “don’t touch prod” or aren’t tightly monitored - those are often their beachheads.
Let’s walk through their playbook. If you've ever responded to a lateral movement incident and wondered, “How did this jump from that dev VM to domain admin?” - this is how. Each phase breaks tools you rely on - because they assume users are who they claim to be.
This is where most orgs still hope to stop attackers. But Flax Typhoon doesn’t need malware. They use phishing, supply chain tampering, or simply reuse leaked credentials.
Simply adding to the registry is stealthy way to trigger a Run action:
That’s a simplified persistence trick using registry run keys. No obvious malware, and EDR should catch this. The challenge is that it also may not.
The first box they compromise? Almost always low value. But that’s the point. It’s the entry, not the goal.
Once in, they don’t run Metasploit or a well-known, noisy executable. They run PowerShell. They check Active Directory memberships. They harvest credentials from LSASS using tools like ProcDump or nanodump.
You’ve probably blocked Mimikatz - only to see attackers dump memory with signed Microsoft tools instead. There are many ways that these exploits can play out.
Example:
Then they exfiltrate those creds - or replay session tokens silently. And if you're relying on your Identity Provider logs to catch that, then you're already behind.
This is where containment often fails. They connect to other machines using valid credentials over RDP, WinRM, or PsExec. No new malware. No unusual ports. Just standard tooling.
Example lateral move:
They’re using valid sessions harvested in the previous phase. MFA won’t challenge them again. EDR won’t alert because everything’s signed. And SIEM? It sees a valid user running valid commands from a valid endpoint.
By now, they’re pivoting through your environment faster than most detection rules can update.
You’ve likely deployed all of these, and maybe even rely on them heavily. But here’s how each one breaks down when sessions - not identities - are compromised:
The key problem is this: our tooling assumes that once a session is established, that session is under the sole control of the authorized user. Flax Typhoon abuses that trust relentlessly.
CISA, MITRE, and other agencies have issued bulletins pointing to:
The takeaway is clear: if you’re only tracking credentials and IPs, you’re missing the attacker already inside.
This is where Keystrike flips the table. Instead of trusting that an authenticated session still means an authorized user, Keystrike verifies that every single command originates from real physical input.
You can think of it as enforcing a root of trust grounded in physical presence.
If someone tries to move laterally using a hijacked session - say, via stolen cookies or RDP replay - Keystrike blocks the interaction before it hits the network.
Keystrike is not signature-based and works where anomaly detection doesn’t. It’s physical hands on keyboards. Keystrike proves by verified keyboard and mouse activity that the command is genuine. No attestation = no command.
You’ve put in the work - MFA, EDR, SIEM tuning, Zero Trust. And yet, attackers like Flax Typhoon still slip through. Not because you missed something, but because the system trusts sessions to stay authentic after initial authentication.
They exploit that trust. They hijack a legitimate session and from that moment on, your defenses have done all they can do, yet the intruder is able to roam and act as if they are you.
This isn’t a failure of effort. It’s a failure of assumptions.
Keystrike changes that by enforcing something attackers can’t fake: physical presence. It verifies that every command actually came from the person you think it did.
We built it because we’ve stood where you stand - trying to defend users in environments built on trust that no longer holds up.
Try Keystrike in Your Environment for 30 Days
