Teams Helpdesk Impersonation Detections

A detection release for the help desk impersonation campaign that Microsoft Threat Intelligence reported on September 2, 2026, published October 23, 2026. The attacker poses as IT support or a colleague in a Teams chat, calls seconds later, and walks the user into a remote-support session or an installer. Two new high-confidence behavior rules cover the first two steps. O365_Teams_OnMicrosoft_Tenant_Chat alerts on the chat, when it comes from a throwaway *.onmicrosoft.com tenant. O365_Endpoint_Download_From_Azure_CloudApp alerts when a browser downloads an installer from the kind of throwaway Azure host these crews use to deliver it.

No action is needed: the rules sync to every instance automatically.

Rollout and requirements

• Rollout. Both rules are published to the default rule set and reach each instance through resource sync within about two hours. No configuration is needed.
• Data sources. Both rules read the Microsoft 365 unified audit log, collected by Office365 Audit API or Office 365 Audit.
  • O365_Teams_OnMicrosoft_Tenant_Chat needs its Teams records (the Audit.General content type).
  • O365_Endpoint_Download_From_Azure_CloudApp needs browser-download records, which Windows devices write to the same log once they are onboarded to Microsoft Purview. Devices already onboarded to Defender for Endpoint are in Purview's device list. Turn on device onboarding in the Purview portal under Settings → Device onboarding.
• Timing. Microsoft typically delivers Teams audit records 60 to 90 minutes after the event, so the chat alert often arrives after the call has ended. Call records arrive hours later still. That is why the rule alerts on the chat, not the call. Use the alert to contain the attack and to reach everyone the attacker contacted.
• Expected volume. Outside tenants on onmicrosoft.com rarely open chats with staff. Expect an occasional chat alert when a small vendor or contractor whose tenant has no custom domain starts a chat. Close those as expected. Software vendors do not ship installers from *.cloudapp.azure.com, so the download rule should rarely fire on legitimate activity.

The attack

The operator works from a Microsoft 365 tenant of their own. Setting one up takes minutes, and a new tenant's domain is on Microsoft's onmicrosoft.com by default. Some attacks open with mail bombing: the user's mailbox is flooded with subscription-confirmation emails, so a help desk offer to fix it is welcome. Posing as IT, the help desk or a colleague, the attacker opens a one-to-one Teams chat and calls within seconds. The name shown on the call can differ from the name on the account.

During the call, the attacker talks the user through one of these:

• approving a remote-control request, reading back a Quick Assist code, or sharing their screen;
• opening a link to a fake IT page hosted on cloud storage;
• downloading and running an installer. It may come from a *.cloudapp.azure.com host, the default address of an Azure virtual machine, which anyone can create in minutes.

In the intrusion Microsoft reported, the operator then runs PowerShell, installs an MSI silently from attacker-controlled cloud storage, and stages a portable Node.js runtime with an encrypted JavaScript implant. The implant persists under an EdgeUpdate Run key or Startup shortcut, and its first tasks check the machine's antivirus and display adapter to spot a sandbox. The operator then enumerates the domain and moves over WinRM to file, database and application servers, domain controllers and certificate authorities. Microsoft describes this as activity that can precede ransomware or data theft. The installers are rebuilt often, so published file hashes go out of date quickly. Storm-1811, a Black Basta ransomware actor, has used the same help desk lure over Teams since 2024.

New detections

ID	Rule	Severity	Fires when
102180	O365_Teams_OnMicrosoft_Tenant_Chat	High confidence	A user of a *.onmicrosoft.com tenant outside your organization creates a Teams chat with one or more of your users. Lookalike tenants, such as a copy of your own company name on onmicrosoft.com, are matched. The sender's display name does not matter.
102181	O365_Endpoint_Download_From_Azure_CloudApp	High confidence	A browser on a managed Windows device downloads an installer, executable, script, shortcut, archive or disk image — for example .msi, .exe, .ps1, .js, .lnk, .zip or .iso — from a *.cloudapp.azure.com host.

O365_Teams_OnMicrosoft_Tenant_Chat does not fire for:

• guests of your own organization (#EXT# accounts);
• partners who sign in with their own custom domain;
• personal (consumer) Teams accounts;
• chats that your own users start with an outside tenant;
• messages, replies or members added in a chat that already exists.

It is keyed on the external account. If one attacker account messages several employees, the alerts land on one entity and Fluency's risk scoring groups them into one case. An attacker who rotates tenants produces one case per account. Each alert lists the external account and tenant ID, the users in the chat, the participating domains, the chat thread ID and the chat type.

O365_Endpoint_Download_From_Azure_CloudApp does not fire for:

• documents and other file types, such as PDFs;
• other Azure hosting, such as Azure Blob Storage (*.blob.core.windows.net), which delivered the MSI in the intrusion Microsoft reported;
• files fetched by PowerShell or any other program that is not a browser;
• devices that are not onboarded to Microsoft Purview.

It is keyed on the employee who downloaded the file. Each alert lists the file, its SHA-256 hash, the host it came from, the device, the browser and the client IP.

Coverage for the rest of the attack

After the call, the attack moves to the endpoint. If you collect Microsoft Defender XDR, CrowdStrike Falcon or SentinelOne alerts, each alert becomes a Fluency behavior on the user and device it names, with the process command line where the vendor provides it. Microsoft lists Defender XDR detections for the implant, the Node.js loader, rundll32 launches, Active Directory enumeration and WinRM lateral movement in this campaign. Defender's mail-bombing and Teams-impersonation alerts arrive the same way, and get triaged with everything else instead of waiting in the Defender queue.

No log shows what was said on a call or what was on a shared screen. Your EDR's process telemetry is what shows which programs ran afterwards.

Triage guidance

Start from the users in the alert, and work through them in this order. A user who called back or accepted the chat request most likely believed the caller. Teams CallParticipantDetail records in the audit log show which calls were answered, once they arrive.

Priority	Users	Why
1	Shared their screen or granted remote control, downloaded or ran anything (including an O365_Endpoint_Download_From_Azure_CloudApp alert), or answered and then called back or accepted the chat	The attacker may have had hands on the computer, or will be back.
2	Answered a call	The attacker may have asked for a password, an MFA approval or a remote session.
3	Chat only, no call	Warn them.

A clean sign-in history does not clear a user. The attacker works through the employee's own computer during the call, so the sign-ins in the record are the employee's own.

1. Contain any priority 1 computer now. Isolate it, then review it from the start of the call onward. Look for remote-access tools, an MSI installed from a user-writable path, node.exe running from %LocalAppData%, an EdgeUpdate Run key or Startup shortcut, new services and scheduled tasks, credential dumping, and WinRM or other connections to other hosts.
2. Secure the account. Revoke the user's sessions, reset the password, review MFA methods and registered devices, and check sign-ins from the day of the call onward. Rotate the credentials the computer could reach.
3. Block what was downloaded. For an O365_Endpoint_Download_From_Azure_CloudApp alert, check in your EDR whether the file ran, and add its SHA-256 hash and the download host to your EDR's block indicators.
4. Interview priority 1 and 2 users. Ask what the caller wanted, and whether they opened Quick Assist or another remote tool, opened a link, shared their screen, downloaded or ran anything, typed a password or approved an MFA prompt.
5. Review priority 1 and 2 computers in your EDR, from each call's start to two hours after. With Defender XDR, the CallActivityEvents table in Advanced Hunting shows which attacker calls included screen sharing.
6. Close the door. In the Teams admin center, under Users → External access, choose Allow only specific external domains and list the partners you work with. Blocking attacker domains one at a time does not keep up, because a new tenant takes minutes to create. Also turn off People in my organization can communicate with unmanaged Teams accounts: personal accounts are the next place an attacker can come from, and O365_Teams_OnMicrosoft_Tenant_Chat does not match them. If you do not use Quick Assist for IT support, remove or block it.
7. Tell people. If the attacker used a real employee's name, tell that employee. Warn staff that IT will not contact them from an outside Teams account or ask for an unscheduled screen share or installer, and that a sudden flood of spam is a common setup for a fake help desk call.

To find these alerts, search behavior events by rule name. Each rule is also listed by name on the Behavior Rules page.

References

• Microsoft Threat Intelligence, Impersonating IT support: how threat actors turn a remote session into enterprise-wide access, September 2, 2026.
• Microsoft Threat Intelligence, Threat actors misusing Quick Assist in social engineering attacks leading to ransomware (Storm-1811), May 15, 2024, updated June 2024.
• Microsoft Learn, Manage external meetings and chat with people and organizations using Microsoft identities (Teams external access settings).