Researchers have described a new, previously unknown Python implant: TWINLOOT. The threat focuses on stealing login credentials and then moving through the target network—using a striking approach where the TWINLOOT SharePoint Teams attack chain is fully hidden in the Microsoft cloud environment.
What makes TWINLOOT stand out isn’t only what it can do, but also how it establishes connections. Tasks run through SharePoint Online and Microsoft Graph; interactive access is handled via Teams relays; and transport is supported by a headless browser that makes traffic almost indistinguishable from legitimate sessions.
What is TWINLOOT and what is it used for?
TWINLOOT is a modular framework that runs as a Python implant and is equipped with security and stealth techniques (such as PyArmor hardening). In the observation from the investigation, the malware is seen during a campaign that ran in July 2026. Its core function is clear: receive instructions, exfiltrate data, execute commands, and arrange persistence on the system.
According to the technical report, the attack is also cloud-native. That means the command-and-control (C2) isn’t set up “standalone,” but is concealed in services that are typically viewed as trusted within Microsoft 365.
C2 hidden inside Microsoft 365: SharePoint Online and Graph API
One key component of TWINLOOT is the use of SharePoint Online file dead-drops. The implant pulls task instructions via the Microsoft Graph API, with the system periodically (as mentioned in the study: every 15 seconds) checking for new tasks in a SharePoint drive-like structure.
To make the traffic look plausible, the Graph communication is powered by a headless instance of the victim’s Edge browser. This gives the network traffic a pattern that closely matches normal browser activity, which should make detection harder.
Interactive access and lateral movement via Teams TURN
In addition to the “dead drop” route, TWINLOOT uses a second channel for interaction with the operator. Microsoft Teams is used as the transport mechanism, specifically by abusing TURN relays.
The result is that the operator can set up a reverse SOCKS5 tunnel back to their own environment. On the attacker’s machine, a listener then appears on 127.0.0.1:1080, after which network traffic is proxied through the tunnel to internal targets.
Crucially, connections to internal services (such as SMB on 445, RDP on 3389, WinRM on 5985, and MSSQL on 1433) appear externally as if the compromised host is communicating with them normally from within the network.
Stealing credentials with pixel-perfect fake lock screens
For lateral movement, the implant needs usable authentication data. According to the investigation, TWINLOOT does this with pixel-perfect cloned lock screens.
The fake lock screen is launched when the operator issues the command “credz_waiting”. The passwords entered are then encrypted and sent back to the attackers via the SharePoint channel. After that, the fake lock screen automatically closes.
A notable detail: the input is not validated via Windows authentication to check whether the correct system password was entered. No matter what is entered, the victim sees an error message—thereby increasing the chance that the system will ultimately prompt for (and accept) the correct password again.
Initial access: Teams social engineering with PowerShell
Researchers assess that initial access likely goes through social engineering via Microsoft Teams. The attacker poses as IT support and convinces a victim to run a PowerShell command.
This PowerShell task is responsible for downloading an archive containing a Python runtime and a compiled payload of around 39 MB, with a bootstrap file that acts as a loader for TWINLOOT (called: bootstrap-fat.pyc).
Persistence: four methods for continued access
Once active, TWINLOOT wants to keep running. The investigation names four persistence methods:
- TypeLib COM scriptlet hijack
- GhostTask-style TaskCache manipulation
- Self-update via a reobf.json manifest
- A method based on an open-source tool Swarmer
The fourth method is especially interesting because it targets creating stealthy registry information in HKCU (HKEY_CURRENT_USER) without administrative rights. To do so, a mandatory Windows profile hive is prepared in offline mode, so that the contents of NTUSER.MAN can take precedence over NTUSER.DAT when Windows loads the user profile.
According to the report, this marks the first time this persistence approach has been observed in the wild.
Why this model makes detection harder
The main defensive challenge isn’t only the malware itself, but the combination of transport- and service-abuse. TWINLOOT uses:
- SharePoint Online for dead drops and task processing via Graph
- Teams TURN for WebRTC-based relays for interactive access
- The victim’s own Edge browser traffic as a “carrier” for Graph communication
All of this leads to C2 traffic that, in terms of timing and context, looks more like legitimate Microsoft behavior. As a result, traditional network- or IOC-based detections may be less effective—especially when the attacks don’t require unusual infrastructure.
Broader pattern: TURN relay abuse appears across multiple threat groups
This isn’t the first time TURN relays have been used as a hiding layer. In earlier reports, researchers for example saw Backdoor.Turn, linked to ransomware activity, where C2 communication was concealed via Microsoft Teams relays.
Later variants were also described that use similar TURN mechanisms—though with different implementations. The similarities point to a broader trend: multiple actors, in a relatively short period, converge on the same “solution direction” for C2 traffic.
Implications for defenders: what can you do now?
Because TWINLOOT targets credentials, lateral movement, and misuse of trusted Microsoft services, organizations should address both technical gaps and detection gaps.
Start by improving visibility around cloud applications and sessions. Think about logging and alerting for abnormal Graph activity, unusual SharePoint access patterns, and correlation between Teams-related events and PowerShell downloads or runtime deployments.
It’s also wise to enforce strong security around accounts and privilege levels. That reduces impact if a credential is stolen through social engineering, lock-screen deception, or similar techniques.
For broader context on AI- and vulnerability-driven threats, you can also read how attackers find ways to bypass security in AI-driven vulnerabilities: why patching isn’t enough.
Quick checklist for a suspicious Teams incident
- Check whether a PowerShell command was executed via Teams by a user posing as IT support.
- Look for unusual downloads of Python runtimes or compiled Python payloads.
- Watch for suspicious Graph API calls to SharePoint, especially patterns that resemble polling for “dead drops.”
- Investigate suspicious internal connections after a credential-theft moment (SMB/RDP/WinRM/MSSQL).
Conclusion
TWINLOOT SharePoint Teams is an example of how attackers use Microsoft services to hide C2 and interaction chains. By using SharePoint Online and Graph for task processing, abusing Teams TURN for reverse SOCKS5 access, and placing headless Edge between the implant and the network, it becomes extra difficult for defenders to recognize something “off” early on.
The message is clear: security isn’t only about patching—it also depends on identity protection, detection of misuse of cloud behavior, and limiting damage once credentials have been compromised.
If you want more examples of AI-like or cloud-driven deception and attack patterns, AI speed attacks: rethinking cybersecurity is a useful starting point for looking at speed and automated threats.
Finally: treat Teams and SharePoint as critical links in your threat model—because in attacks like this, they aren’t the “victim,” they’re the camouflage.
Source: https://thehackernews.com/2026/08/twinloot-abuses-sharepoint-and-teams-to.html
