TwinLoot Turns Microsoft 365 into a Command Center for Attacks on Corporate Networks

A Python framework that lives in the Microsoft cloud

Researchers at the Ontinue Cyber Defense Center have identified TwinLoot, a modular malware framework written in Python that brings the living off the land model to the cloud. Rather than relying solely on tools already available in Windows, the framework builds command and control by abusing legitimate Microsoft Azure and Microsoft 365 services.

The campaign was still active in July, when the malware modules were recovered. The activity was detected on August 18, 2026.

TwinLoot uses SharePoint Online and the Microsoft Graph APIs to exchange commands and data, Microsoft Teams to obtain interactive access, and Microsoft Edge to make communications generated by the compromised device appear more legitimate. Its traffic can therefore blend in with normal user and application activity across corporate environments.

The Python modules were protected with PyArmor 9.2.5. Once the embedded configuration was decrypted, researchers uncovered an architecture built around multiple operational channels designed to limit the attacker’s visibility and preserve control after the initial compromise.

SharePoint, Graph, and Teams become the C2 infrastructure

The command-and-control component uses SharePoint Online as an exchange point based on a dead drop model: the attacker places commands or data in a cloud location, and the malware retrieves them through legitimate Microsoft APIs.

The Microsoft Graph APIs serve as the application-layer channel. Instead of connecting to a suspicious server or a domain with a poor reputation, TwinLoot communicates with infrastructure that is widely used across corporate networks.

The framework also incorporates Microsoft Teams’ TURN relay infrastructure. Normally used to facilitate interactive communications, this technology is leveraged to maintain an operational connection to the infected system. The result is a channel that may appear consistent with Teams-generated traffic, particularly when it is analyzed without correlating identities, endpoints, and cloud activity.

Microsoft Edge further helps conceal Graph API requests. The browser installed on the victim’s device is used to transport communications, while browser automation and the possible use of headless components make it harder to distinguish malicious activity from that of a corporate application.

According to the researchers’ assessment, TwinLoot is the first framework they have observed to combine Microsoft 365 dead drops, abuse of the Teams TURN relay, and browser-based transport in a single architecture.

Capabilities: credential theft, command execution, and internal network pivoting

TwinLoot includes a Windows credential-stealing module. The malware displays a fake lock screen designed to resemble the legitimate operating system interface and asks the user to enter their password.

Credentials are collected even when the attempt fails. If the password is incorrect, the victim sees a message consistent with a normal authentication error and can try again. If the subsequent entry succeeds, the suspicious behavior may not be immediately apparent.

This logic allows passwords to be captured without necessarily producing obvious signs for the user. Unexpected authentication prompts or lock screens appearing outside the normal workflow should therefore be investigated, particularly if they recur.

The framework can also execute arbitrary commands on the compromised system. This allows the attacker to gather information, alter endpoint behavior, and prepare additional operations.

The component most relevant to lateral movement is an interactive SOCKS5 proxy. The proxy routes traffic through the infected process and may provide access to internal network resources that are not directly exposed to the Internet. A single compromised computer can thus become a pivot point for reconnaissance, access to other systems, and interaction with corporate services.

Persistence without administrative privileges

TwinLoot also uses a persistence technique that researchers have named “Corrupting the Hive Mind.” The method creates a mandatory profile hive offline using legitimate Windows APIs.

The technique does not require administrative privileges and does not directly modify the Registry during installation. As a result, it may not generate the events typically associated with Registry changes or privilege elevation.

This reduces the effectiveness of some traditional detection rules. An organization looking only for altered Registry keys, administrative processes, or elevated activity may fail to detect the persistence mechanism.

Ontinue describes this as the first malicious use of the technique observed in real-world activity. The persistence mechanism exploits native operating system functionality and leaves a smaller operational footprint than techniques based on conspicuous configuration changes.

Careful preparation, but attribution remains uncertain

The observed architecture points to seven weeks of preparation. Before operational deployment, two expired domains, a dedicated Azure AD application, and a SharePoint site intended to serve as a dead drop appear to have been set up.

The Python framework also incorporated a tool originally presented at a technology conference. The domains had been prepared several weeks before the rest of the infrastructure.

The operation has not been attributed to a specific group. The level of integration between offensive security, Python, cloud identities, and Microsoft services suggests the possible involvement of a professional operator or a developer with advanced expertise in the Azure and Microsoft 365 ecosystems.

The versions of the affected Microsoft products have not been disclosed, nor have IP addresses, domains, hashes, or other specific indicators. No CVE identifiers, CVSS score, or inclusion in CISA’s KEV Catalog have been reported; accordingly, there is no KEV listing date or mitigation deadline to provide.

How to hunt for TwinLoot without relying solely on indicators

Traffic to Microsoft 365 should not be considered trustworthy by default. Defense should focus on deviations from the expected behavior of users, devices, applications, and services.

Organizations should establish baselines for SharePoint, Teams, and the Graph APIs, taking volume, frequency, timing, destinations, and access methods into account. Unusual sequences of Graph calls—especially when associated with an account or device that does not normally make them—warrant investigation.

OAuth applications and Azure AD consent grants should also be reviewed. Unexpected applications, disproportionate permissions, or new integrations with SharePoint and Graph may indicate preparation of the C2 channel.

SharePoint and Teams telemetry should be correlated with endpoint data. Sites, files, relay sessions, and anomalous communication flows become particularly meaningful when they coincide with unusual use of Edge, browser automation, Python scripts, or PyArmor-protected modules.

Detection rules should also cover repeated authentication prompts, unexpected lock screens, and failed access attempts followed by successful authentication. In the case of TwinLoot, the password entered by the user may already have been captured.

Finally, defenders should look for signs consistent with a SOCKS5 proxy, unexpected interactive connections, and access to internal resources from endpoints that do not normally perform administrative or pivoting activities. Correlating identity, cloud, and endpoint data is essential: analyzing these three layers separately leaves significant room for the attacker to operate.