Someone labeled “IT Support (Internal)” pings you on Microsoft Teams from outside the company, and minutes later Quick Assist is live on your desktop. That is not a hypothetical. According to Arctic Wolf Labs, threat actors abused Microsoft Teams external chat in more than 400 incidents to impersonate IT support, persuade employees to install or approve legitimate remote monitoring and management tools, and seize hands-on-keyboard access. Mail bombing often created the urgency first. Chat and Teams voice calls finished the sell. No Teams product bug was required. Default-on federation and a convincing helpdesk persona were enough.
How throwaway tenants turned external chat into fake IT
Microsoft Teams external access and federation are on by default in many environments. Attackers treated that as an open front door for social engineering, not as a software flaw. Arctic Wolf Labs stated the activity does not exploit any known Teams vulnerability. It abuses a legitimate, default-on collaboration capability.
Operators worked from newly created or acquired Microsoft 365 tenants. Between 30 and 40 percent of the cases Arctic Wolf analyzed used default *.onmicrosoft.com tenant domains. Helpdesk-themed display names and friendly first names did the rest of the work. Labels such as “IT Support (Internal)” diluted the external-user warning employees might otherwise notice. When paid domains appeared, .top domains accounted for roughly half of those observed cases, a shift Arctic Wolf flagged as operators moved beyond the most obvious free-tenant fingerprints.
The early telemetry signal that mattered most was ChatCreated: the moment an external party opened the conversation, before the victim engaged. That is the window where security teams still have a chance to interrupt the script. Once the employee is talking to “IT,” the conversation looks like support, not malware delivery.
Mail bombing, vishing, and the RMM approval moment
Many runs started with mailbox flooding. A flooded inbox makes a sudden Teams message from IT feel urgent and plausible. Actors then moved into external Teams chat, Teams voice (vishing), or both. The ask was simple and familiar: install or approve a remote-support tool so IT can fix the problem.
The tools were legitimate RMM products, not custom trojans at the first step. Arctic Wolf saw Quick Assist most often. The same playbook also used AnyDesk, ScreenConnect, TeamViewer, Atera, Zoho Assist, NetSupport, and LogMeIn. In some cases a second layer followed, including Level or other persistence tooling after the first remote session was live.
Speed mattered. Arctic Wolf described hands-on-keyboard access and payload execution sometimes landing in under 15 minutes from the social-engineering open. That timeline leaves almost no room for a slow ticket queue or a second human check once the employee has already clicked through a familiar Microsoft or vendor installer flow.
Public reporting on this wave does not name a specific MFA method defeated at a login form, a Temporary Access Pass read out by a helpdesk, or an adversary-in-the-middle page capturing passwords and session cookies as the way initial access was won. The employee was already in a working session. The operators talked that person into granting interactive remote control with software the organization often already trusts for real support.
What operators did once remote control was live
With an approved RMM session, the rest looks like ordinary operator work under the user’s or an elevated context. Arctic Wolf’s example chains included PowerShell-delivered MSI payloads pulled from Azure Blob storage, a Python implant, Active Directory LDAP enumeration, and command-and-control follow-through. From there the path ran to broader discovery, data theft, and in some incidents deployment of Chaos ransomware.
Victim organization names and exact record counts were not published in the primary write-up. Formal threat-actor branding beyond the Chaos ransomware appearance in some cases also was not locked down in that source. The collaboration-channel pattern does line up with earlier Sophos reporting on STAC4749 and Chaos-linked Teams vishing: external IT personas, voice coaching, and remote-access tooling as the bridge into the estate. Treat that as shared tradecraft context, not as a court-grade attribution of every one of the 400-plus Arctic Wolf cases to a single named crew.
SSO and cloud identity still sit in the blast radius after the foothold. An interactive desktop session can reach browser profiles, synced enterprise apps, and admin consoles the user can already open. That is post-approval operator activity, not a fresh workforce login the sources describe as the break-in method. Shortening token lifetimes or arguing about push fatigue does not reverse a Quick Assist window the employee already authorized.
Federation and external-chat policy are the controls that sit upstream of this script. So are helpdesk verification rituals that never ask an employee to install remote control because a stranger on Teams said so. Login cryptography does not veto a trusted RMM binary the user just approved.
If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: federation, external-chat, and process controls for Teams IT-impersonation RMM grants.
FAQ
Did the Arctic Wolf Teams cases exploit a Microsoft Teams vulnerability?
No. According to Arctic Wolf Labs, the Microsoft Teams IT support impersonation activity across more than 400 incidents did not exploit any known Teams vulnerability. Attackers abused legitimate, default-on external chat and federation, plus social engineering, to reach employees and push RMM installs.
How did attackers make fake IT look internal on Teams?
Attackers used newly created or acquired Microsoft 365 tenants and helpdesk-themed display names such as “IT Support (Internal),” often with friendly first names. Arctic Wolf Labs reported that 30 to 40 percent of analyzed cases used default *.onmicrosoft.com domains, which reduced the friction of standing up disposable “support” identities against external chat.
Which remote tools showed up after the fake IT contact?
Employees were persuaded to install or approve legitimate RMM tools. Arctic Wolf saw Quick Assist most frequently, along with AnyDesk, ScreenConnect, TeamViewer, Atera, Zoho Assist, NetSupport, and LogMeIn. Some incidents then added Level or other follow-on remote-access persistence after the first session was live.
Would MFA at login have blocked these 400-plus Teams RMM footholds?
MFA at login would not have blocked the initial access path Arctic Wolf described. Public detail points to social engineering of already-reachable employees into approving legitimate remote-support tools over external Teams chat and vishing, not to a named password-plus-OTP capture, push-bombing completion, or helpdesk TAP issuance as the break-in step. Once Quick Assist or similar is approved, operators are working inside an interactive session the user granted.
What early signal should defenders watch for on this pattern?
Arctic Wolf identified ChatCreated as the primary early detection point, before the victim engages the external party. Pair that with tight external-access policy, scrutiny of helpdesk-themed inbound tenants, and a hard rule that real IT never cold-starts RMM over unsolicited external Teams chat after a mail bomb.
