Arctic Wolf published the research on October 26, 2026. It matters to anyone running Microsoft 365, and especially to admins who have never opened the Teams external access settings since setup day.
What Arctic Wolf found
The pattern repeats from incident to incident. Arctic Wolf reports the use of the same throwaway tenants, the same "IT Support (Internal)" display names, the same remote-access tools, and increasingly, the same payload domains.
The main findings:
- The way in is a feature, not a flaw. Teams external access, also called federation, ships switched on. TechNadu notes that any Teams user in another Microsoft 365 tenant can find, chat with, and call an organization's employees if both tenants allow external access.
- Email bombing often comes first. In a significant number of cases, email bombing came before or alongside the Teams contact. The attack floods a victim's inbox with hundreds of newsletter or subscription confirmations within minutes. A Teams "IT support" message then offers to resolve the problem. The attacker causes the mess and then offers to clean it up.
- It moves fast. Arctic Wolf says the attack chains its customers reported reached payload execution in under 15 minutes once a victim engaged. The company also saw several cases recorded concurrent credential-access detections (Kerberoasting, GoldenPAC-related) firing alongside the initial Teams alert. In other words, some endpoints were already compromised by the time anyone looked at the chat alert.
- Many targets at once. According to Cyberpress, attackers sometimes targeted several employees within approximately five minutes, suggesting automation.
The 15-minute figure needs context. It describes customer-reported chains measured from the point a victim engaged. It does not mean every external chat ends in a breach in 15 minutes. Likewise, 400+ is the number of incidents Arctic Wolf analysed in its own telemetry. It is not a count of confirmed compromises across all Teams customers.
Section summary: This is a social engineering campaign that runs on Teams' default settings. The weak point is trust, not code.
How the fake help desk looks real
The display name does most of the work. Per GBHackers, attackers frequently append "(Internal)" to names such as "IT Support," attempting to counteract Teams' external-user warning. Teams still labels the sender as External. The attacker is betting the victim reads the name and ignores the label.
Other tricks Arctic Wolf documented:
- Friendly first names, such as "IT Service Desk (Matthew)", so the sender looks like a real colleague.
- Local-language versions, such as "Supporte TI", for non-English-speaking targets.
- Roughly 100+ emoji markers (shields, tools, check marks) across attacker display names. Arctic Wolf suggests this could point to AI-assisted automation, but presents it as a possibility, not a finding.
- More recently, the target organization's own name or domain added to the attacker's display name. Arctic Wolf also observed identities incorporating the target organization's name or domain to make unsolicited contact appear credible.
Arctic Wolf argues the channel itself is part of the trick. Staff have been trained for years to distrust email, but a message that appears inside Teams doesn't trigger the same caution.
Infrastructure: from onmicrosoft.com to .top
Throwaway tenants are still common. Arctic Wolf found that default onmicrosoft[.]com tenant domains appeared in 30 to 40 percent of analyzed cases. These default domains need no verification and can be set up in minutes. Tenant names usually include words like support, helpdesk, admin or network, sometimes with "365", "online", "portal" or a random number added.
Paid domains are a growing share. Of the paid domains Arctic Wolf identified in recent months, about half used .top, around 40% used .com, and just over 5% used multi-level domains such as .com.pl, .com.vn and .com.br. Those percentages apply to paid domains only, not to all 400+ incidents. Arctic Wolf says this matches Sophos' reporting on the STAC4749/Chaos ransomware campaign, which also saw a move to cheap IT-themed .top domains. In some cases the attackers set DNS so their custom domains redirected visitors to real Microsoft or victim-company websites.
From chat to remote control
The chat is only the first step. Arctic Wolf says the attacker's real aim is usually hands-on-keyboard access through a legitimate remote monitoring and management (RMM) tool, often arranged during a Teams voice call (vishing). Tools observed include Quick Assist, AnyDesk, ScreenConnect, TeamViewer, Atera, Zoho Assist, NetSupport and LogMeIn.
Quick Assist was the most common. Arctic Wolf suggests that's because it is built into Windows, signed by Microsoft, needs no installation, and only asks the victim to read out a six-digit code. For persistence, attackers then switch to a commercial RMM tool, installed via msiexec in some cases. That gives them a separate control channel that survives cleanup of the original implant.
Arctic Wolf also described what it called a potentially novel chain:
- A fake helpdesk employee tells the user to run a PowerShell command and open the downloaded file. Both actions ran under the victim's account, with explorer.exe recorded as the parent process. Arctic Wolf described the interaction as resembling ClickFix, without a fake CAPTCHA.
- The command downloaded an MSI installer from Azure Blob Storage. The package contained a PowerShell script and archive6.zip.
- A script dropped under AppData decrypts and runs an obfuscated PowerShell stage. That stage unpacks a pythonw interpreter and a Python implant.
- The implant sends LDAP queries to Active Directory for all computer and user objects, then sends the results to command-and-control endpoints.
One detail matters for defenders. Arctic Wolf says attackers generally avoid pasting URLs into Teams, where Safe Links and ZAP would scan them. Instead they open the payload themselves during the remote session. Message scanning alone won't catch that, so endpoint and identity telemetry matter just as much.
Same technique, more groups
This isn't new. Microsoft first documented the chain in mid-2024 in the Black Basta (Storm-1811) campaign: email bombing, then a fake external Teams "help desk", then Quick Assist, then malware such as QakBot, DarkGate or Cobalt Strike, then ransomware. Arctic Wolf says the technique later appeared in the Cactus, 3AM and Chaos campaigns. Zscaler reported Teams vishing and Quick Assist being used to deploy the GoGRPC backdoor. TechNadu also points to Google Threat Intelligence Group's April analysis of UNC6692 impersonating IT help desks on Teams, and to a June Symantec report on DragonForce hiding command-and-control traffic in Teams TURN relay servers. The common thread is that attackers keep finding ways to use Microsoft's trusted collaboration infrastructure against its customers.
What admins can do now
Arctic Wolf's main recommendation is to stop allowing chat from every tenant. Microsoft's own documentation supports this, and gives more detail than the headline advice.
1. Switch external access to an allowlist
- In the Teams admin center, go to Users > External access.
- Next to Teams and Skype for Business users in external organizations, choose Allow only specific external domains.
- Add the partner domains you actually work with, then select Done and save.
Microsoft says that once you have an allowed-domains list, all other domains are blocked. Partners still have to allow your domain on their side. If different departments need different partners, external access policies can set allow or block lists per user or group, limited to 100 domains per list. Microsoft also warns that people from blocked domains can still join meetings anonymously if anonymous access is turned on, so check that setting too.
2. Check trial-tenant federation
Microsoft documents a PowerShell setting, Set-CsTenantFederationConfiguration -ExternalAccessWithTrialTenants "Blocked", and says Blocked is the default. It requires Teams PowerShell module version 6.4.0 or later. Run the command or check your current value anyway, in case someone changed it to Allowed. When it's blocked, users in trial-only tenants can't search for or contact your users, and they're removed from existing chats.
3. Lock down unmanaged accounts
Arctic Wolf recommends blocking chat with unmanaged (consumer) Teams accounts. Under Users > External access, you can turn off communication with unmanaged Teams accounts altogether. Alternatively, clear the option that lets those users start conversations with your users.
4. Let the SOC block domains
The Allow my security team to manage blocked domains toggle lets security admins block domains, such as the .top indicators in Arctic Wolf's report, from the Tenant Allow/Block List's Teams domains tab in Microsoft Defender. Microsoft lists it as public preview. It requires Defender for Office 365 Plan 1 or 2, and external access must be set to Allow all or Block only specific domains. So it complements a blocklist approach rather than an allowlist.
5. Restrict the remote-access route
Limit Quick Assist to authorized IT roles, or remove it where nobody uses it. Block unsanctioned RMM tools with Defender for Endpoint or application control.
6. Verify through a separate channel
Require a callback to a registered number, or approval in a separate trusted app, before granting any remote-access request. An attacker who controls the Teams chat can't pass a check that happens outside it.
What users should watch for
Be suspicious of any unexpected chat from "IT" that carries the External tag, especially right after your inbox fills with junk. Be very suspicious if it asks you to read out a code, install remote-access software, or paste a PowerShell command. Real help desks have known phone numbers, so hang up and call them. On detection, Arctic Wolf highlights the Teams ChatCreated event as the earliest warning sign, often before the user has done anything. Teams now also has built-in reporting, so employees can flag a suspicious message or external user in a couple of clicks.
The bottom line
Some balance is fair here. Arctic Wolf sells managed detection, and its report naturally promotes its own ChatCreated alerting. Its numbers come from its own customer base, not all of Microsoft 365. But the core finding is backed by Microsoft's own Storm-1811 research and by independent work from Sophos and Zscaler. Default-open federation combined with a convincing "IT Support (Internal)" name is a well-established initial-access route.
The fix needs no vendor contract and no zero-day patch. It's a dropdown in the Teams admin center that most organizations have never changed, plus a firm help-desk rule that nobody gets remote access without verification through a separate channel.