TWINLOOT Hides C2 Inside Microsoft SharePoint

A new Python-based malware framework called TWINLOOT runs its entire command-and-control operation through Microsoft’s own cloud infrastructure — SharePoint Online being the documented tasking channel — without ever touching attacker-controlled servers on the network wire.

Ontinue security researchers published the technical analysis, shared with The Hacker News. Their description: “TWINLOOT is a modular, PyArmor-hardened Python implant designed to operate its entire command-and-control infrastructure inside trusted Microsoft services. Tasking flows through SharePoint Online file” reads/writes. Dark Reading’s coverage adds that the framework steals credentials and achieves persistence on infected hosts.

The actual problem here

Most enterprise network security tools — DLP, NGFW, proxy filters, SIEM alert rules — are built around the assumption that Microsoft 365 traffic is benign. They whitelist it, skip inspection, or flag deviations from Microsoft IP ranges rather than deviations from expected access patterns within those ranges.

TWINLOOT exploits that assumption by design. From the network perimeter, an infected host looks like an employee using SharePoint. Nothing about the traffic pattern triggers conventional IP or domain-reputation controls.

This is the same class of technique as WMIC-style LOLBin abuse — the attacker uses the defender’s trusted toolchain against them. The difference is that cloud-hosted C2 doesn’t go away when Microsoft removes a binary; the “tool” is an entire SaaS platform.

What to do

There is no patch for this. TWINLOOT is not exploiting a Microsoft vulnerability — it’s abusing legitimate SharePoint functionality. The response is behavioral detection and audit log coverage.

Priority actions:

1. Enable Microsoft 365 Unified Audit Logging if it isn’t already on. This is the primary telemetry source for spotting anomalous SharePoint access — repeated polling of document libraries from endpoints, at machine-cadence intervals, from accounts that wouldn’t normally read those files. Without audit logs, you are flying blind. Microsoft’s documentation covers the setup; it’s included with most M365 business licenses at no extra cost.

2. Add PyArmor runtime artifacts to your EDR detection policy. TWINLOOT is obfuscated with PyArmor. The runtime drops recognizable artifacts (typically pytransform.pyd or the equivalent loader stub). A behavioral rule flagging PyArmor execution in unusual process trees catches the implant at load time, regardless of which cloud service it uses for C2.

3. Review SharePoint access anomalies in your M365 audit logs. Look for service accounts or user accounts executing high-frequency file read operations on SharePoint at non-human intervals, especially from endpoints rather than servers. Automated polling at regular intervals from an endpoint is not a pattern that appears in normal human SharePoint usage.

4. Check for Python interpreter execution on endpoints where it doesn’t belong. If Python isn’t a standard developer tool in your environment, unexplained Python processes — particularly those spawning from unusual parents or running obfuscated code — are worth investigating.

Bottom line

TWINLOOT’s primary novelty is operational security, not technical sophistication. A PyArmor-hardened Python script is not novel malware engineering. What’s novel is the deliberate decision to route all C2 through a Microsoft service that defenders routinely trust and under-monitor.

If your detection stack treats all Microsoft 365 traffic as inherently safe, TWINLOOT will operate silently in your environment. Unified Audit Logging and endpoint behavioral rules are the practical fix. Get audit logging turned on first.

For the full technical breakdown, read Ontinue’s report via The Hacker News.