In July 2026, Ontinue's Cyber Defense Center caught an intrusion that started the way most do now: a Microsoft Teams call from someone posing as IT support, talking a target into running a PowerShell command. That command pulled down an archive containing a full Python runtime and a 39 MB compiled payload, bootstrap-fat.pyc. The loader unpacked into an implant Ontinue named TWINLOOT, which gave the attacker two separate ways to control the infected machine. One was a dead-drop on SharePoint: TWINLOOT checked in there every 15 seconds over Microsoft's own Graph API, the same channel a legitimate app would use, to pick up new commands. The other was a tunnel built on SOCKS5, a protocol that routes traffic through a single relay point, running over either a direct encrypted connection or Microsoft Teams' own relay servers.
What makes TWINLOOT worth writing about isn't the social engineering, which is ordinary at this point. It's that the SharePoint channel doesn't run as a separate malicious process reaching out over the network. It runs inside a headless instance of the victim's own Microsoft Edge browser, driven through the Chrome DevTools Protocol. Every request to graph.microsoft[.]com looks exactly like the browser traffic it actually is, because it is the browser. Ontinue notes this same "drive the victim's own browser as C2 transport" idea showed up independently in at least two other pieces of malware within the same month. That's not one group being clever. It's a technique multiple actors landed on independently.
How the browser-as-C2 channel works
Tasking arrives through a SharePoint dead-drop that TWINLOOT polls every 15 seconds via the Graph API, executed through the headless Edge/CDP session rather than a raw HTTP client. To a network monitor, or to Microsoft's own telemetry on the tenant, this is indistinguishable from a user's browser legitimately hitting SharePoint. There's no unusual user agent, no off-profile TLS fingerprint, no connection to infrastructure that isn't already Microsoft's.
Credential theft works the same way it always has, with one specific twist: when the operator sends a credz_waiting command, TWINLOOT throws up a fake lock screen and captures whatever the victim types. It doesn't validate the password against anything before encrypting it and uploading it to the SharePoint dead-drop. It just harvests the string. That's a deliberate simplification: verifying a password would require the kind of local check that's easier to notice, so the implant skips it and lets the operator sort out which captures are real later.
Once credentials land, the SOCKS5 tunnel (bound locally to 127.0.0.1:1080) turns them into lateral movement: RDP on 3389, WinRM on 5985, SMB on 445, MSSQL on 1433, all pivoted through the same channel that looks like ordinary Teams or browser traffic from the outside.
What the persistence layer looks like
TWINLOOT doesn't rely on one persistence mechanism. Ontinue documented four: a TypeLib COM scriptlet hijack, GhostTask-style manipulation of the Windows TaskCache, a self-update path driven by a manifest file (reobf.json), and registry hive corruption built from a tool called Swarmer combined with the RegLoadAppKeyW API and the offline registry library offreg.dll. That last one is the most notable: Ontinue's writeup states it persists "without being detected by security software even in the absence of administrator access." It's not exploiting a bug to get that resilience. It's composing legitimate, documented Windows APIs in a way nothing is watching for.
Being honest about what caught this
The Hacker News writeup doesn't say what tipped Ontinue's investigators off. There's no failed validation check, no crash, no resource limit that gave it away, the way there sometimes is with noisier malware. It surfaced during an investigation, not because any single control flagged it. That absence is itself worth sitting with: TWINLOOT is built specifically to not produce the kind of signal that trips a detection rule. Attributing its capture to some defense working as intended would be giving that defense credit the evidence doesn't support.
Why the standard mitigations don't close the gap
The obvious response is more of what's already standard: Teams-focused social-engineering training, DLP or CASB policies watching SharePoint for anomalous access patterns, EDR behavioral rules looking for pythonw.exe spawning unusual child processes, and monitoring for TaskCache or registry-hive anomalies. All reasonable, all worth doing.
None of it addresses the actual problem, which is that the C2 traffic is legitimate traffic. You can't write a detection rule against "the victim's own Edge browser talking to Microsoft's own Graph API using the victim's own session" without either accepting a flood of false positives or blocking SharePoint outright. The persistence mechanisms have the same issue: RegLoadAppKeyW and offreg.dll aren't malware APIs, they're registry APIs, used the way Windows allows them to be used. Detection built to spot "bad behavior" has nothing to key on when the behavior is, by construction, indistinguishable from good behavior.
The question detection can't ask, but known-good enforcement does
Every defense described above is trying to answer the same question: does this traffic, or this process, or this registry write, look wrong? TWINLOOT's entire design is an answer to that question: no, it doesn't, because it's built out of legitimate components used through legitimate channels.
Known-good enforcement doesn't ask that question at all. It asks a narrower one, at the point of execution: was this specific binary ever authorized to run here? Under that model, it doesn't matter how convincingly bootstrap-fat.pyc's network traffic mimics a real Edge session, or how legitimate RegLoadAppKeyW looks in isolation. pythonw.exe executing an unrecognized, non-allowlisted compiled payload is simply not a permitted event, independent of what that payload does once it's running or how quiet it manages to be. The camouflage TWINLOOT was built around stops mattering, because known-good enforcement was never looking at behavior to begin with.
TWINLOOT isn't dangerous because it slipped past one specific rule. It's dangerous because its authors built it to never generate a signal that any behavior-based rule could catch. That's exactly the class of technique where detection has a ceiling, and it's exactly where an enforcement model built on authorization rather than behavior doesn't care how good the disguise is.
