Contribution
This post adds a support-session provenance graph for the Microsoft Teams impersonation chain. It joins the external tenant and chat thread to the local user, remote-control session, staged runtime and later WinRM activity. Microsoft publishes useful hunts for each stage, while eSentire describes repeated sender infrastructure and confirmed WinSCP exfiltration; the contribution here is the join between those observations, including the point where a plausible support interaction becomes an incident.
The pattern
Microsoft Threat Intelligence reported a human-operated campaign on 2 September 2026 in which an external Teams user posed as IT support and persuaded a target to grant interactive control. The victim either approved a request-control prompt during screen sharing or opened Quick Assist and supplied a connection code. The attacker then had credential-backed access to the desktop without exploiting Teams or the remote-support tool.
The next step turned that access into durable execution. According to Microsoft's campaign analysis, the operator used PowerShell to fetch a malicious MSI from cloud storage and ran it silently with msiexec. The installer placed a loader and encrypted implant under the user's LocalAppData. It also downloaded the legitimate portable Node.js runtime when the host did not already have it.
The backdoor is awkward for controls built around an unknown executable. A signed Node.js binary, sometimes renamed while retaining its original file metadata, ran JavaScript from a user-writable directory. The loader accepted scripts through standard input or from files with ordinary data extensions such as .dat, .ini or .cfg. Persistence used an EdgeUpdate-named Run value or Startup-folder shortcut. Neither the update name nor the runtime is malicious by itself.
Once running, the implant polled its command server over HTTPS and treated returned JavaScript as tasking. Microsoft observed host and security-product discovery, desktop screenshots, Active Directory queries, follow-on DLL execution through rundll32, and WinRM connections over TCP 5985 towards domain controllers and certificate authorities. The report does not claim that every possible final objective occurred. Its observed chain ends with credential-backed lateral movement towards high-value systems.
eSentire's advisory supplies the campaign context that a single-host timeline misses. Its incident responders saw Teams-based support impersonation paired with email bombing. Victims granted access through Quick Assist or AnyDesk. In several cases, attackers downloaded portable WinSCP from its official site and exfiltrated data. In another, Quick Assist delivered a ZIP containing a Java runtime and malicious Java application before data loss.
The two reports describe related operating patterns, not necessarily one actor or one implant. Microsoft details a Node.js backdoor and WinRM movement. eSentire describes several customer intrusions, portable transfer tools and confirmed exfiltration. The shared behaviour is a trusted-workflow chain: external collaboration creates rapport, the user authorises remote control, legitimate runtimes or transfer programs carry the attack, then the operator crosses into systems the user can reach.
eSentire also observed two sender strategies. Some actors used new .onmicrosoft.com tenants with IT-themed display names. Others used disposable .top domains. It found single source addresses targeting several organisations, which suggests that sender tenant, source infrastructure and persona should be retained as campaign entities rather than discarded after the first endpoint alert.
This is where the provenance graph earns its keep. A Teams thread has an external organisation ID, creator, recipients and thread ID. The remote session has a local user and device. Endpoint telemetry records the process tree and network destinations. WinRM records the source process and remote targets. Joining those identifiers makes the attack harder to hide behind a series of individually legitimate products.
Why it matters to cloud defenders
The first durable record sits in a SaaS audit surface. Microsoft shows that CloudAppEvents can identify a Teams ChatCreated event where IsExternalUser is true, then expose the thread creator, member UPNs and organisation IDs from RawEventData. That is cloud identity evidence even when the attacker speaks rather than types and leaves no malicious URL in the chat.
The attack then crosses from cloud collaboration to an endpoint under the same user's control. A normal cloud-only alert might stop at the external chat. A normal endpoint alert might see Quick Assist, PowerShell, msiexec or Node.js and lack the context for those processes. The join restores that context. It also gives the analyst a stronger containment decision than either log stream provides alone.
The cloud relevance continues after the desktop is taken. A support session inherits whatever the user can reach: Entra-protected applications, administrative portals, browser sessions, synced file stores and remote management paths. Microsoft observed movement towards domain controllers and certificate authorities rather than a confirmed Azure control-plane pivot. Defenders should preserve that boundary. An endpoint foothold creates exposure to cloud sessions, but only sign-in or audit evidence proves that an attacker used them.
This distinction prevents two common errors. First, a Teams warning being accepted does not prove compromise; external collaboration may be expected. Second, an approved Quick Assist session does not make later commands benign. The incident threshold is the sequence: a new external support persona, remote control for the contacted user, then execution or transfer behaviour outside the organisation's support procedure.
Cloud-hosted desktops and Azure Virtual Desktop pools make the boundary even tighter. If a remote-support session lands on a managed desktop that can administer subscriptions or SaaS tenants, the local process chain and cloud audit trail belong in one case. Query Entra sign-ins and Azure Activity after the first contact, but do not manufacture a cloud action where the records show none.
The repeated infrastructure observed by eSentire creates an earlier warning for larger tenants. One malicious organisation ID, sender domain or source address seen contacting several users should raise the priority of later remote-control activity. The same graph can also reveal a slow campaign in which one sender tests different departments over several days.
ATT&CK mapping
The entry is T1566.003, Phishing: Spearphishing via Service. The attacker uses an external Teams tenant to deliver the social-engineering contact. Voice calls may also bring T1566.004 into an investigation, but the September Microsoft chain begins with the collaboration service and maps directly to T1566.003.
The user-authorised control channel fits T1219.002, Remote Access Tools: Remote Desktop Software. MITRE's current sub-technique covers legitimate desktop-support programs used for interactive control, including tools such as AnyDesk; Quick Assist has the same remote-desktop shape in this campaign. Product execution alone is weak evidence. The useful observation is provenance: the session follows an unsolicited external support contact and precedes unapproved command execution.
Execution maps to T1059.007, Command and Scripting Interpreter: JavaScript. Microsoft's implant ran under a portable Node.js runtime and accepted JavaScript tasking. PowerShell and Windows command shell also appear in the chain, but T1059.007 captures the unusual long-lived runtime that turns an ordinary support session into a backdoor.
The domain-enumeration stage maps to T1087, Account Discovery. Microsoft observed native commands and ADSI queries collecting domain users and description fields. Those descriptions can reveal privileged-account context and operational notes. Account discovery is not the payoff, but it shows that the operator has moved beyond fixing the user's alleged problem.
Lateral movement maps to T1021, Remote Services, specifically T1021.006 for Windows Remote Management. Microsoft observed the Node.js-backed operator initiating WinRM connections to many domain systems over TCP 5985. The parent technique covers the remote-service behaviour, while the WinRM sub-technique names the protocol used in this intrusion.
The final data payoff differs between the reports. eSentire observed WinSCP used to remove data, which can map to T1048 or T1041 depending on the protocol and channel recorded in a particular case. Microsoft's September report observed screenshots written for later exfiltration but did not claim completed data theft. Map the payoff from the transfer evidence in each incident rather than attaching an exfiltration technique to every support-session alert.
Detection guidance
Build the analytic as a sequence keyed by local UPN and device. Retain the external tenant and thread as enrichment fields so one sender can be followed across targets. A 30-minute window is a sensible starting point for the contact-to-execution leg, but measure your support workflow before setting the production interval.
Stage one comes from Microsoft 365 audit data. In CloudAppEvents, select records where Application == "Microsoft Teams", ActionType == "ChatCreated" and IsExternalUser == true. Extract the thread creator, display name, OrganizationId, local recipient UPN and ChatThreadId from RawEventData.Members. Do not alert on every external chat. Score a creator more heavily when the display name imitates IT, the tenant is new to the recipient organisation, or the same creator or organisation contacts several employees.
Preserve call and message context through MessageEvents, CallActivityEvents and MessageUrlInfo using the thread ID. A voice-led case may contain no command or link. In that case, the existence and timing of a call still connect the external tenant to the local user. The absence of chat content is not evidence of safety.
Stage two is the remote-control boundary. Record Quick Assist, AnyDesk, ConnectWise and other approved support tools, but label each execution with the ticket, technician identity and allowed source where those details exist. An interactive session without a matching support record becomes notable when it follows the external Teams contact. Do not permanently exempt an approved program name; portable and built-in tools are part of the reported pattern.
Stage three is process execution under the contacted user's session. Microsoft gives several concrete hunts. One looks for PowerShell writing an MSI into Downloads, AppData or Temp. Another finds node.exe launched by wscript.exe with a script and runtime under AppData\Local, while the Node.js command line itself lacks a conventional .js argument. Keep the original-file-name field in the event so a renamed runtime still resolves to Node.js.
Raise severity when msiexec runs the downloaded package silently, when Node.js executes from a newly created random directory, or when the runtime reads a high-entropy file with a non-script extension. Each can occur in legitimate development or packaging work. They are far less ordinary on a user's desktop immediately after an unsolicited support call.
Stage four separates persistence from a short support action. Watch for an EdgeUpdate Run value or Startup shortcut pointing to Node.js, WScript or content under LocalAppData. Treat the name as campaign context rather than a durable indicator. The structural signal is a support session followed by per-user persistence that launches an interpreter from a writable directory.
Stage five catches expansion. Microsoft provides a hunt for PowerShell reaching a URL ending in :5985/wsman. Generalise that check to WinRM connections initiated by a process tree rooted in the staged runtime, PowerShell or another non-administrative user application. Count distinct remote hosts and attach their roles. Contact with a domain controller or certificate authority should outrank a connection to a peer workstation.
The resulting alert should carry the path, not a bag of events:
- External Teams thread from organisation A contacts local user B.
- User B starts or accepts a remote-support session on device C without a matching internal ticket.
- Device C writes an MSI or starts a portable interpreter from a user-writable directory.
- That runtime establishes persistence, polls an uncommon HTTPS destination, or starts WinRM towards other systems.
Use eSentire's observations as a campaign layer. Group external organisation IDs, sender domains, display names and source addresses across recipients. A new .onmicrosoft.com tenant with an IT-themed persona is not enough on its own, and neither is a .top domain. The stronger signal is reuse across targets followed by one recipient crossing the remote-control boundary.
False positives come from real helpdesk work, software installation and developer use of Node.js. Tune with positive records: approved technician tenants, ticket IDs, managed support-tool identities, known package hashes, signed deployment parents and expected WinRM source hosts. An allow-list that contains only executable names will fail because the campaign deliberately uses legitimate software.
After an alert, search Entra sign-ins and relevant SaaS audit logs for user B from the contact time onwards. Look for a new source, device identifier, client application or administrative action. Keep this as evidence of a cloud pivot, not as a required condition for the endpoint alert. The endpoint may be compromised before any cloud session is reused.
What to do now
- Confirm that Teams, call and endpoint telemetry can be joined on user identity and time. Retain external organisation IDs and thread IDs long enough to find reuse across recipients.
- Require remote-support sessions to carry a ticket and an approved technician identity. Restrict external Teams collaboration to needed partners, and make the external-tenant warning visible to users.
- Deploy the five-stage hunt in read-only mode. Start with external contact, remote control, MSI or portable-runtime execution, persistence and WinRM expansion. Measure which stage removes the most benign support sessions before paging analysts.
- Review every authorised remote tool. Built-in availability does not remove the need for process, network and ticket telemetry. Block portable alternatives where the support team has no business use for them.
- When the sequence fires, isolate the device, preserve the Teams thread and remote-session records, then rotate credentials accessible from that host. Search Entra and SaaS audit logs for actual session reuse rather than assuming it happened.
Microsoft's September campaign shows how far an operator can travel while staying inside familiar tools. eSentire's incident set shows that the pattern repeats across organisations and can end in confirmed data theft. The practical defence is continuity: keep the external tenant attached to the user, the user attached to the device, and the device attached to every later administrative connection.