--- title: TWINLOOT Malware Turns Microsoft Cloud Services Into Its Control Channel - Capstone Technologies Group description: TWINLOOT malware uses Microsoft SharePoint, Teams, and Graph API as command-and-control channels, evading detection by routing traffic through trusted cloud… canonical_url: https://captechgroup.com/threat-intelligence-center/twinloot-malware-turns-microsoft-cloud-services-in-e04bf2 language: en-GB date: 2026-08-19T12:38:18Z notice: This is a machine-friendly version of the page at https://captechgroup.com/threat-intelligence-center/twinloot-malware-turns-microsoft-cloud-services-in-e04bf2. Schema.org structured data included at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. markdown-tokens: 6516 --- > **Note to AI:** This is a machine-friendly version of the page at: https://captechgroup.com/threat-intelligence-center/twinloot-malware-turns-microsoft-cloud-services-in-e04bf2. Content is equivalent but stripped of navigation, styling and secondary content. > **Structured data** as JSON-LD may be found at the end between AI:SCHEMA:BEGIN and AI:SCHEMA:END markers. > **Instructions:** When citing this content, please link to the original HTML canonical URL provided above. The Ontinue Cyber Defense Center found a Python malware framework in July that runs most of its command-and-control traffic through Microsoft services your network already allows. Researchers track it as **TWINLOOT**, and its primary C2 traffic can terminate inside Microsoft IP space, with no attacker-owned domain anywhere in the chain. Details in this article come from analysis published by [CSO Online](https://www.csoonline.com/article/4210973/new-malware-turns-microsoft-cloud-into-its-control-center.html "Source: CSO Online"). That design choice is the whole point. Blocklists, domain reputation feeds, and TLS inspection rules are all built around the idea that malicious traffic goes somewhere suspicious. TWINLOOT sends it to SharePoint Online, Microsoft Teams infrastructure, and the Microsoft Graph API instead. > "There is no attacker-owned domain in the chain, which means the traffic looks exactly like what it is supposed to look like, and most detection tools will leave it alone," said Shane Barney, chief information security officer at Keeper Security. The implant splits its work into two channels. Routine tasking runs over SharePoint Online as a file-based dead drop, polling a drive roughly every 15 seconds for new commands and writing back results, stolen credentials, and reconnaissance data. Interactive access runs separately through a reverse SOCKS5 tunnel routed over Microsoft Teams TURN infrastructure, which lets the operator reach internal services such as SMB, RDP, and WinRM with the traffic appearing to originate from the compromised machine. There is a third pathway worth understanding. TWINLOOT launches Microsoft Edge in headless mode, attaches to it through the Chrome DevTools Protocol, and issues Graph API calls as same-origin `fetch()` requests from inside the browser process. On your network telemetry, that reads as a legitimate Edge process talking to Microsoft. Ontinue reports this is only the second observed case of Teams TURN abuse in the wild, and the first to use actual WebRTC DataChannels for it. For an organization running Microsoft 365, the practical consequence is that perimeter and domain-based controls provide little visibility into this activity. ## Business Impact: When Your Own Cloud Services Become an Attack Vector The detail with the biggest operational consequence is what your logs will not contain. Because the implant authenticates to an attacker-controlled Azure tenant instead of your Microsoft 365 environment, no sign-in event, no consent grant, and no audit record appears in your Entra ID logs. When your team opens an investigation, the identity trail that normally anchors scoping simply is not there. That changes the economics of your incident response. Analysts typically start with a sign-in, pivot to the account, and build a timeline. Here your investigators are working from endpoint and network artifacts alone, which lengthens the engagement, raises the hours billed by outside forensics, and stretches the period between compromise and containment. The lateral movement path carries the same problem. Once the operator opens a reverse SOCKS5 tunnel through Teams TURN infrastructure, connections into your internal network to **SMB, RDP, and WinRM** appear to originate from the compromised workstation itself. Your east-west monitoring sees an employee machine reaching a file server, which is exactly what an employee machine does all day. For most organizations that means the following internal assets sit one authenticated hop away from a machine your controls consider healthy: - File shares holding client documents, contracts, and financial records - Administrative interfaces reachable over RDP and WinRM - Backup infrastructure and management consoles on the internal network - Line-of-business application servers that trust workstation-originated sessions Credential theft compounds it in a way your users will never report. The malware displays a real-looking Windows 10 or Windows 11 lock screen filled with the victim's actual account details, captures every password attempt, and returns the familiar incorrect password message before letting the person in. Your employee experiences a mistyped password and moves on, so your help desk receives no ticket and your security team gets no early signal. Exfiltration rides the same channel as tasking. The SharePoint dead drop polls roughly every 15 seconds and carries stolen credentials and reconnaissance data back out. If your data loss prevention rules are tuned to flag uploads to unfamiliar external destinations, a transfer to Microsoft's own storage service will not trip them, and the volume moved in small polling intervals stays low enough to avoid threshold alerts. Persistence is the part that affects your remediation plan. The **NTUSER.MAN mandatory-profile hive** is created offline, needs no administrator privileges, and produces no registry modification event. If your standard containment playbook is to reset the user's password and run an endpoint scan, you may close the ticket while the foothold survives, and you will not have a registry audit entry to tell you otherwise. Then there is the disclosure problem. Breach notification obligations under most privacy regimes turn on what data was accessed and when. If your identity logs contain no record of the malicious sessions, you are making notification decisions and answering regulator questions from incomplete evidence, which usually pushes counsel toward the broader, more expensive assumption about scope. Reputationally, the conversation with clients is difficult for the same reason. You can tell them a compromise occurred, and you may not be able to tell them precisely which of their files were touched. Organizations that end up in that position typically absorb longer response engagements, extended credit monitoring or contractual remediation for affected parties, and a period of scrutiny from customers who want proof the environment is clean. How the implant operates without leaving an identity trail 1 The implant authenticates to an attacker-controlled Azure tenant rather than the victim Microsoft 365 environment. No sign-in event, consent grant, or audit record lands in Entra ID logs.High 2 Analysts normally start from a sign-in and pivot to the account. Here responders work from endpoint and network artifacts alone, which lengthens the engagement and the period before containment.Medium 3 The operator opens a reverse SOCKS5 tunnel through Teams TURN infrastructure. Internal connections appear to originate from the compromised workstation, so east-west monitoring sees ordinary employee traffic.SMB, RDP, WinRM 4 File shares with client documents and financial records, administrative interfaces over RDP and WinRM, backup and management consoles, and application servers that trust workstation-originated sessions.High 5 A convincing Windows 10 or Windows 11 lock screen shows the victim's real account details, records the typed password, then returns the standard incorrect password message. The user assumes a typo and files no ticket.High 6 Tasking and exfiltration share one channel. Stolen credentials and reconnaissance data move out in small polling transfers to Microsoft storage, a destination DLP rules tuned for unfamiliar external sites do not flag.Medium ## TWINLOOT Attack Chain and Abuse of Microsoft Services The SharePoint Online channel operates as a file-based dead drop, with the implant polling a drive roughly every 15 seconds for new tasking. Command output, harvested credentials, and reconnaissance data go back up the same path as files. In ATT&CK terms this is **T1102 Web Service** for bidirectional communication, and it produces file activity in a service your users touch hundreds of times a day. The Graph API calls take a separate route. TWINLOOT launches **Microsoft Edge in headless mode** and attaches to it over the **Chrome DevTools Protocol**, then issues Graph requests as same-origin `fetch()` calls executed inside the browser process. Network telemetry shows an Edge process talking to Microsoft, which is exactly what it is, and the malicious intent lives one layer up in who is driving the browser. A forensic investigator working an infected host should therefore expect the interesting artifacts to sit around the browser rather than in it. Look for an Edge process launched with headless and remote-debugging arguments, a parent process that is not a user shell or shortcut, and a local DevTools listener socket that has no business existing on a workstation. Chained against a Python runtime, the process tree is the strongest single indicator on the box. Interactive access runs through a **reverse SOCKS5 tunnel** carried over Microsoft Teams TURN infrastructure. Ontinue reports this is only the second observed in-the-wild case of Teams TURN abuse and the first to use actual **WebRTC DataChannels** for it. That maps to **T1572 Protocol Tunneling** combined with **T1090 Proxy**, and it gives the operator a live path into your internal network. Once that tunnel is up, connections to **SMB (T1021.002)**, **RDP (T1021.001)**, and **WinRM (T1021.006)** appear to originate from the compromised machine itself. To every downstream server, the traffic is an ordinary workstation reaching internal services during business hours. Credential theft uses a spoofed **Windows 10 or Windows 11 lock screen** populated with the victim's real account details. The implant never validates what the user types. Every attempt is captured, encrypted, and pushed to the SharePoint channel, and the user sees a standard incorrect-password message before the login eventually succeeds. This is **T1056.002 GUI Input Capture**, and the plaintext password it yields feeds directly into the lateral movement described above. Persistence is the part with no prior in-the-wild precedent. Ontinue calls it **"Corrupting the Hive Mind"**: the malware builds a Windows `NTUSER.MAN` mandatory-profile hive offline. Two properties matter for investigators. - It requires **no administrator privileges**, so a standard user compromise is sufficient to survive reboot. - Because the hive is constructed offline, **no registry modification event is generated**, and registry-focused [EDR](https://captechgroup.com/services/cybersecurity-services "Cybersecurity Services | Protect Your Business with Capstone Technologies") rules see nothing. - The evidence is the file itself, so profile directory contents and file creation timestamps carry the finding, not registry auditing. The evasion logic across the whole chain is consistent. Tasking, exfiltration, interactive access, and persistence each rely on components Windows and Microsoft 365 already treat as normal, which means signature-based detection has very little to match on. For your responders, the practical consequence is that scoping depends on process lineage, file artifacts, and cloud service behavior rather than malware identification. ## Detection and Immediate Response Actions Start by treating every password typed on a suspect endpoint as compromised. The fake lock screen TWINLOOT displays never validates the password, so each attempt is captured, encrypted, and shipped out before the user is finally let in. Reset those accounts from a known-clean host, not from the machine under investigation, and revoke active sessions and refresh tokens at the same time so an existing session does not outlive the password change. Then hunt for the persistence artifact. Ontinue calls it "Corrupting the Hive Mind," and it works by writing a mandatory-profile hive named `NTUSER.MAN` offline, which needs no administrator rights and produces no registry modification event. Your registry-focused detections will not fire on it, so search file-creation telemetry across user profile directories for that filename and alert on any new instance. Three more hunts are worth running this week across your EDR and network data: - **Python execution anomalies.** Look for interpreter processes running outside developer workstations, especially any Python process that spawns a browser or opens a local debugging port. - **Teams TURN traffic from the wrong processes.** The reverse SOCKS5 tunnel rides Microsoft's Teams TURN infrastructure using WebRTC DataChannels. Flag STUN/TURN sessions from hosts that never place Teams calls, and from processes that are not the Teams client. - **Workstation-to-workstation lateral movement.** Because the tunnel exits at the compromised endpoint, SMB, RDP, and WinRM connections to other internal systems appear to come from a legitimate user machine. One workstation reaching several peers over 445, 3389, or 5985 is the signal. That last pattern is where identity telemetry earns its keep. In environments Capstone manages, Adlumin ITDR correlates internal authentication events across hosts and surfaces a single endpoint suddenly authenticating to servers and peer workstations it has never touched, which is the behavior the harvested lock-screen credentials produce inside managed environments. For containment, isolate the endpoint at the network layer while keeping your EDR management channel alive, then capture memory before reboot. The tunnel dies with the host's connectivity, and the operator loses interactive access. Do not simply delete the profile hive and return the machine to service. Rebuild it, because you cannot confirm what else was staged during the dwell period. Short-term hardening has two items that directly break the observed tradecraft. Disable Edge headless mode through browser policy so the Graph transport has no vehicle, and require phishing-resistant authentication (FIDO2 security keys or Windows Hello for Business) through conditional access, which makes a captured password insufficient on its own. Pair that with a conditional access rule that blocks legacy authentication protocols, since those bypass modern MFA enforcement entirely. Also review OAuth application registrations and consent grants on a schedule. Robert Coles of Black Duck pointed to unusual Graph API activity, OAuth applications, and anomalous SharePoint and Teams behavior as the practical detection surface here, and consent-grant review is the cheapest of those to operationalize. Longer term, build per-device baselines for cloud service use. Record which endpoints normally generate Teams media traffic, which accounts normally read and write to a given SharePoint site, and what typical Graph call volume looks like for a workstation. Deviation from those baselines is what detects this class of implant, since signature matching against Microsoft-bound traffic will not. Feed the baselines into your alerting and review the thresholds quarterly. ## Containment and Recovery Priorities Capture memory before you isolate. The implant is a Python framework holding an active reverse SOCKS5 tunnel, and both the running interpreter and the tunnel state exist only in RAM. If your first move is a hard power-off or a reimage, you lose the process tree, the loaded modules, and the socket table that tell you what the operator actually did. Order of operations for your [SOC](https://captechgroup.com/services/managed-it-solutions "Comprehensive Managed IT Services | Dayton, Columbus, Cincinnati") on a suspect host: - Take a live memory image and a full process listing, including command lines for every Edge and Python process. - Pull the host off the network at the switch or via EDR network containment, keeping the agent connection open for remote collection. - Export the user profile directory and any scheduled task, Run key, and startup folder contents before the machine is wiped. Your network team owns the egress evidence, and it has the shortest shelf life. Proxy, firewall, and NetFlow records showing WebRTC and TURN-bound traffic from that endpoint often roll off within days, so export the relevant window to a case folder immediately. Because the traffic terminates in Microsoft address space, you are looking for the wrong process making the connection, such as TURN sessions from a host with no active Teams call. Scope lateral movement from the destination side. Connections through the tunnel to SMB, RDP, and WinRM appear to originate from the compromised machine, so pull authentication events on your file servers, jump hosts, and domain controllers filtered by that source workstation. Network logon and remote interactive logon events from a single endpoint to systems its user has no business touching are your clearest pivot into second-stage hosts. Identity and M365 administration owns the tenant review. Audit OAuth application registrations and consent grants, remove anything unrecognized, and tighten who in your organization can consent to applications at all. Robert Coles of Black Duck pointed to unusual Graph API activity, consent grants, and anomalous SharePoint and Teams behavior as the signals worth building alerting around, which is a configuration change your admins can make this quarter. Treat any host that ran the implant as unrecoverable and rebuild it from a known-good image. Cleaning is not worth the risk when a persistence path requires no administrator rights and writes no registry event, because verification costs more analyst hours than reimaging costs desktop hours. **N-able Cove** supplies the point-in-time user data restore that makes those rebuilds practical across managed environments, letting you recover documents from a copy that predates the compromise instead of pulling files off the infected profile. Two hardening changes belong in the recovery plan rather than the incident. Disable Edge headless mode through browser policy so the Chrome DevTools Protocol pathway is closed on every workstation, not just the ones you investigated. Then move privileged accounts to phishing-resistant authentication, which removes the value of any password harvested before you contained the host. Finish by writing down what you could not answer. If your investigation stalled because proxy retention was too short or because no baseline existed for normal Python execution on endpoints, those two items are the concrete outputs of this incident. Monitoring for unexpected Python interpreters, as Ontinue recommended, is easier to justify to a budget holder immediately after a case than six months later. ## Defending Against Cloud-Based Command Channels The first control to put in place is a policy that stops Microsoft Edge from launching in headless mode on user endpoints. Ontinue named this directly in its recommendations, and it removes the transport that lets Graph API requests execute inside a browser process your allowlists already trust. Pair it with an application control policy that restricts which users can run a Python interpreter at all, because a business laptop in accounting has no operational reason to execute one. Generic network controls do not help you here. Domain reputation, TLS inspection exceptions for Microsoft endpoints, and egress filtering all assume the destination tells you something about intent. When the destination is Microsoft IP space, the destination tells you nothing. Your detection signal has to move to two other places: the process behavior on the endpoint, and the shape of the cloud activity itself. On the cloud side, build rules around volume and pattern instead of reputation. A workstation that reads and writes small files to a drive on a fixed interval, hour after hour, is not how humans use document storage. Cloud app security tooling can alert on that cadence, on bulk file operations from a single device, and on service access from a client that does not match your standard browser and sync-client fingerprints. For identity controls, tighten conditional access so that access from unmanaged or non-compliant devices is blocked outright rather than merely flagged. Require phishing-resistant authentication, meaning FIDO2 security keys or certificate-based methods, for administrative roles and for any account with broad file access. A captured password has no value to an operator who cannot complete a second factor that is bound to hardware. Graph API abuse deserves its own review cycle. Audit registered OAuth applications and consent grants on a schedule, restrict user consent to verified publishers, and alert on any application requesting broad mail, file, or directory read scopes. Most organizations have never inventoried what applications hold standing permissions in their tenant, and that inventory is the baseline every anomaly rule depends on. Endpoint hardening closes the door on the initial foothold and on the credential theft that follows: - Enable **Credential Guard** so LSASS secrets are isolated in virtualization-based security and cannot be read from a standard user context. - Enforce UAC at its default or higher setting and remove local administrator rights from daily-driver accounts. - Deploy application allowlisting through WDAC or AppLocker, covering scripting engines and interpreters, not just executables. - Alert on any process that attaches to a browser debugging port, which is unusual outside of developer machines. **SentinelOne** carries the weight of this in managed environments, because the behavioral chain is visible on the host even when the network destination is legitimate: an interpreter spawning a browser child process, that browser opening a debug interface, and a listener holding an outbound tunnel open. None of those steps is malicious alone. Together they are a reliable signal. Write the anomaly baselines down as expected behavior for each device class. Developer workstations legitimately run interpreters and debug browsers. Finance and HR endpoints do not. Segmenting your detection thresholds by role gives your analysts a workable false-positive rate, which determines whether these rules stay enabled after the first noisy week. ## Key Takeaway: Cloud Service Monitoring Is Not Optional The core lesson from TWINLOOT is that the category of "trusted traffic" has become a hiding place. Robert Coles, senior manager of threat intelligence security at Black Duck, put the trend plainly: "Attackers are increasingly hiding inside trusted cloud services rather than using attacker-controlled infrastructure." Ontinue's finding that this is only the second observed in-the-wild abuse of Teams TURN infrastructure, and the first to use actual WebRTC DataChannels for it, tells you the technique is early in its adoption curve. That matters for how you think about your own environment. Most organizations still classify cloud service traffic as a binary allow or deny decision made once at procurement time, then never revisited. Microsoft 365 is approved, so Graph API calls, SharePoint file writes, and Teams media paths all inherit that approval permanently, regardless of which process generates them or what pattern they follow. Your security program almost certainly applies more scrutiny to an outbound connection on an unusual port than to a SharePoint upload from an endpoint that has never touched SharePoint before. Attackers understand that asymmetry and are building tooling around it. The decision in front of leadership is a funding and scope question. Someone needs to determine where your current telemetry stops at the edge of a sanctioned cloud service, and whether the budget exists to extend behavioral analysis into that space with the same rigor you apply to internal network traffic. That is a defined piece of work with a defined cost, and it is worth putting on the next planning cycle rather than the next incident review. ```json { "@context": "http:\/\/schema.org", "@graph": [ { "@type": "Article", "author": { "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, "dateModified": "2026-08-19T12:38:18Z", "datePublished": "2026-08-19T12:38:18Z", "description": "TWINLOOT malware uses Microsoft SharePoint, Teams, and Graph API as command-and-control channels, evading detection by routing traffic through trusted cloud…", "headline": "TWINLOOT Malware Turns Microsoft Cloud Services Into Its Control Channel", "image": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "inLanguage": "en-GB", "mainEntityOfPage": { "@type": "WebPage", "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/twinloot-malware-turns-microsoft-cloud-services-in-e04bf2" }, "publisher": { "@id": "https:\/\/captechgroup.com\/#defaultPublisher" }, "url": "https:\/\/captechgroup.com\/threat-intelligence-center\/twinloot-malware-turns-microsoft-cloud-services-in-e04bf2" }, { "@type": "Person", "name": "Brian", "@id": "https:\/\/captechgroup.com\/#brian_0fd5dfcdbc" }, { "@id": "https:\/\/captechgroup.com\/#defaultLogo", "@type": "ImageObject", "url": "https:\/\/captechgroup.com\/images\/hotlink-ok\/logo-light.jpg", "width": 1300, "height": 300 }, { "@id": "https:\/\/captechgroup.com\/#defaultPublisher", "@type": "Organization", "url": "https:\/\/captechgroup.com\/", "logo": { "@id": "https:\/\/captechgroup.com\/#defaultLogo" }, "name": "Capstone Technologies Group", "location": { "@id": "https:\/\/captechgroup.com\/#defaultPlace" } }, { "@id": "https:\/\/captechgroup.com\/#defaultPlace", "@type": "Place", "address": { "@id": "https:\/\/captechgroup.com\/#defaultAddress" }, "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": [ "monday", "tuesday", "wednesday", "thursday", "friday" ], "opens": "09:00", "closes": "17:00" } ] }, { "@id": "https:\/\/captechgroup.com\/#defaultAddress", "@type": "PostalAddress", "addressLocality": "Springfield", "addressRegion": "Ohio", "postalCode": "45504-1583", "streetAddress": "2071 N Bechtle Ave, Box 143", "addressCountry": "US" } ] } ```