Arctic Wolf reports 400+ Teams external chat incidents; its 15 minute clock starts at victim engagement, no breach count

More than 400 incidents, a 15 minute figure, and no count of breaches

Arctic Wolf Labs says it analysed "more than 400 incidents" in which attackers used Microsoft Teams external chat for social engineering and initial access, and that once a victim engages, the chains customers reported show attackers "reaching payload execution in under 15 minutes". Its report is dated 26 October 2026. Read as arithmetic, the report supports two numbers and a gap. The numbers are more than 400 and under 15 minutes. The gap is the denominator: the report prints no count of incidents in which a victim engaged, none in which a payload ran, and no start or end date for the 400. Its own ATT&CK table says execution was confirmed only in "the few events where the user engaged".

The headline on the trade press story, published on 27 October 2026, says attackers "Breach Organizations in Under 15 Minutes" (Infosecurity Magazine). That word is the headline's, not the report's. The report counts chats and alerts, measures a clock that starts when a person answers, and says the activity "does not exploit any known Teams vulnerability". Microsoft, in an April 2026 write up of the same pattern, says the chain "relies on users willfully ignoring or overlooking security notices".

This briefing reads Arctic Wolf's report in full, six Microsoft pages and the news story, from 14:13 UTC on 27 October 2026, with the key sources read again at 14:22 UTC. Nothing was filled in or submitted and no file was opened beyond pages and images. It sets out what the report counts, the chain it describes, Microsoft's controls with their exact setting names, two places where the report's advice and Microsoft's pages do not agree, what the record does not establish, and a ranked checklist.

What the report counts, and what the 15 minutes measures

Two derived figures show how the tenant mix reads. The report says 30 to 40 percent of the cases analysed used default onmicrosoft.com tenant domains. If that share applies to the whole set, it is at least 120 to 160 of the 400 incidents, and at least 240 to 280 used some other domain (derived). Among the paid domains it saw, about 50 percent were .top, about 40 percent were .com and just over five percent were multi level domains such as .com.pl, so about 95 percent are accounted for (derived). The report does not say how many tenants were free trials, only that attackers "commonly prefer" free or trial tenants.

One more reading is worth making. The report says Arctic Wolf's alerts fire at ChatCreated, before the user does anything, and that its detections draw on "thousands of customer environments". So the 400 is most naturally a count of detected first contacts across Arctic Wolf's own customers. That is an inference from the report's wording, not a statement in it. A count of first contacts is useful as a measure of how often staff are approached. It says nothing about how often staff are fooled.

The attack chain as the report prints it

Arctic Wolf says external access, also called federation, ships turned on by default, so any Teams user in another Microsoft 365 tenant can find, chat with and call an organisation's employees, provided both tenants allow external access. In its words, the activity abuses a legitimate collaboration capability that is on by default, rather than a flaw.

In words, the chain runs as follows. First, in "a significant number of cases", the target's inbox is flooded with hundreds of newsletter or subscription confirmations within minutes. Second, a Teams chat arrives from a newly created or acquired Microsoft 365 tenant. The tenant name is usually a support, IT, admin, network or helpdesk word, sometimes with 365 added, and the display name often ends "(Internal)" while Teams still labels the sender External. Third, the sender offers to fix the very problem the flood created, often by a call from inside Teams. Fourth, the victim is asked to open a remote support tool. Quick Assist is the most frequent, and the report notes it is built into Windows, signed by Microsoft and needs only a six digit code read back. Fifth, once the attacker has control, a PowerShell payload is fetched, and for persistence a commercial remote management tool such as AnyDesk or ScreenConnect may follow. One list in the report names eight remote tools. A signed, legitimate installer that quietly brings a second remote tool is the same pattern as in an earlier briefing on MSP360 and ScreenConnect.

Zoom

Zoom

Arctic Wolf also describes one case it calls "potentially novel". The attacker had the user run a PowerShell command and launch the downloaded file, with explorer.exe as parent process, "reminiscent of ClickFix" but not disguised as a CAPTCHA. The command pulled an MSI from Azure Blob Storage, which dropped a PowerShell script about 30 seconds after launch; the script decrypted a further payload that unpacked a Python implant, which then queried Active Directory for computer and user objects and sent the result to command servers chosen from a list. That is one case, not a share of the 400. Its file names are in the technical details.

Microsoft's April 2026 write up gives stage timings. It says the Quick Assist step "is often completed in under a minute" and that the attacker typically spends the first 30 to 120 seconds on reconnaissance. On those typical figures the first two steps take roughly three minutes (derived), which leaves most of a 15 minute window for staging a payload. That makes the report's figure plausible. It does not show how often it is reached, because neither source says how many cases it rests on.

Microsoft's controls, by their exact names

Microsoft's page on managing external meetings and chat says both the organisation settings and the user policies "are turned on by default", that all external domains are allowed by default, and that for a user to use external access, "both the organization setting and a user policy must allow it". The table lists the settings that bear on this chain, with the path or parameter Microsoft prints. Pages read 27 October 2026; the Defender pages are Defender for Office 365 support for Teams (updated 5 October 2026) and Tenant Allow/Block List for Teams (3 July 2026).

Zoom

Two recommendations that do not fit together, and one that is already the default

Arctic Wolf's countermeasures are sensible, and most are echoed in Microsoft's own guidance. Three details need checking against Microsoft's pages before an administrator follows them as written.

The allow list and the security team block list. The report tells administrators to choose Allow only specific external domains, and also to enable Allow my security team to manage blocked domains "so the security team can push blocks", naming the .top indicators it lists. Microsoft's Tenant Allow/Block List page says the external domains setting "must be Allow all external domains or Block only specific external domains" for security team block entries to work. Allow only specific external domains is not on that list. And with an allow list in place, Microsoft says every other domain is already blocked, so a block entry for a .top domain would add nothing. The two controls are two designs, not two layers. Choose one.

The trial tenant command. The report prints Set-CsTenantFederationConfiguration -ExternalAccessWithTrialTenants "Blocked". Microsoft's pages say Blocked is the default. For a tenant that has never changed it, the command is a no op, and checking the value matters more than setting it. The report does not say how many attacker tenants were trial only, or whether any of the targeted organisations had changed the default to Allowed. If attacker tenants were trial only and targets were at the default, those chats would not have been delivered at all. So either many attacker tenants were not trial only (the 60 to 70 percent on other domains, and paid domains, point that way, as an inference) or some targets had loosened the setting. The report does not say which.

Names and tabs. The report points to a Teams domains tab in the Defender Tenant Allow/Block List. Microsoft's July 2026 page names the tab Teams senders. Microsoft's two pages also differ on availability: one calls the feature Public Preview and tied to Defender for Office 365 Plan 1 or 2, and the later page says it is available to all organisations with Teams and cloud mailboxes. Check what your own portal shows before planning around either.

Zoom

Friendly names doing the work of a control

Much of this chain is a label doing the job of a check. The table sets each comforting name against what it is.

The label to challenge hardest is the first. A display name is typed by the sender. An administrator who trains staff to read the real sender domain, as both vendors suggest, is moving the check to the one place an impersonator cannot edit.

What the record does not establish

• How often it works. No count of victims who engaged, payloads that ran or intrusions. The headline word breach rests on a clock, not a count.
• What the 15 minutes means. The report does not say whether it is a median, a mean, a maximum or one case. It rests on chains "reported by customers".
• Whether defaults caused it. The report does not say which of the 400 organisations had allow lists, trial tenant blocks or the security team setting, so it does not test whether the controls it recommends work.
• Who is behind it. The report names no actor for these incidents. The Black Basta, Cactus, 3AM and Chaos references are earlier campaigns that used the same route.
• That AI was used. The report says emoji in display names "may be evidence" of AI use. That is the report's own hedged inference, with no further evidence given.
• A Teams flaw. Both Arctic Wolf and Microsoft say there is none: the route is a legitimate, default on feature.
• The novel case. The PowerShell and MSI chain is one case the report calls potentially novel, with no count.

Method and interest

Arctic Wolf sells managed detection and response, incident response and security awareness training, and its report ends by naming its own training product and its detections. Its count comes from its own customers' telemetry, so it describes the organisations Arctic Wolf monitors, not all Teams users. Microsoft sells Teams and the Defender products whose features it recommends, some of which need paid Defender for Office 365 plans. Infosecurity Magazine is a trade news outlet and was used as a pointer; it reports the report's figures consistently but adds the word breach in its headline.

What was not read: the Zscaler, Sophos, ReliaQuest, BleepingComputer and Google Cloud pieces the report cites, and Microsoft's 2024 Black Basta write up. Statements about earlier campaigns are the report's own and are attributed to it.

What to do, in the order worth doing it

Technical details

Arctic Wolf's report prints no hunting query or detection rule. It prints names, indicators and one command. Microsoft's April 2026 write up prints advanced hunting queries. Every block below is copied from the saved page and attributed. Nothing here is a working exploit or payload.

These are the two PowerShell lines Microsoft prints for trusted organization settings. A defender runs them in a Teams PowerShell session as an administrator. The first is also printed by Arctic Wolf. Microsoft's page says the first is the default.

Set-CsTenantFederationConfiguration -ExternalAccessWithTrialTenants "Blocked"
Set-CsTenantFederationConfiguration -BlockAllSubdomains $True

Microsoft's page states these prerequisites for the Defender portal to manage blocked Teams domains. A defender checks all three on the External access page before relying on security team blocks.

Teams and Skype for Business users in external organizations must be Allow all external domains or Block only specific external domains.
Allow my security team to manage blocked domains must be On.
Block specific users from communicating with people in my organization must be On.

The first query is Microsoft's own Teams to remote tool correlation. It lists external Teams message senders whose recipients launched Quick Assist, AnyDesk or TeamViewer on a device within 30 minutes. A defender runs it in Microsoft Defender advanced hunting, adds sender display name keywords where the commented lines show, and reviews the matches. It needs the Defender XDR Teams message tables, which Microsoft says come with Defender for Office 365 Plan 2.

let _timeFrame = 30m;
// Teams message signal 
let _teams =
    MessageEvents
    | where Timestamp > ago(14d)
    //| where SenderDisplayName contains "add keyword"
    //          or SenderDisplayName contains "add keyword"
    | extend Recipient = parse_json(RecipientDetails)
    | mv-expand Recipient
    | extend VictimAccountObjectId = tostring(Recipient.RecipientObjectId),
             VictimRecipientDisplayName = tostring(Recipient.RecipientDisplayName)
    | project
        TTime = Timestamp,
        SenderEmailAddress,
        SenderDisplayName,
        VictimRecipientDisplayName,
        VictimAccountObjectId;
// RMM launches on endpoint side
let _rmm =
    DeviceProcessEvents
    | where Timestamp > ago(14d)
    | where FileName in~ ("QuickAssist.exe", "AnyDesk.exe", "TeamViewer.exe")
    | extend VictimAccountObjectId = tostring(InitiatingProcessAccountObjectId)
    | project
        DeviceName,
        QTime = Timestamp,
        RmmTool = FileName,
        VictimAccountObjectId;
_teams
| where isnotempty(VictimAccountObjectId)
| join kind=inner _rmm on VictimAccountObjectId
| where isnotempty(DeviceName)
| where QTime between ((TTime) .. (TTime +(_timeFrame)))
| project DeviceName, SenderEmailAddress, SenderDisplayName, VictimRecipientDisplayName, VictimAccountObjectId, TTime, QTime, RmmTool
| order by QTime desc

This excerpt of Microsoft's longer correlation query shows how it finds the first contact event for a chat thread. Arctic Wolf says the ChatCreated event is the primary detection opportunity.

let _firstContact = materialize(
    CloudAppEvents
    | where Timestamp > ago(_huntingWindow)
    | where Application has "Teams"
    | where ActionType == "ChatCreated"
    | extend Raw = todynamic(RawEventData)
    | extend ChatThreadId = tostring(Raw.ChatThreadId)
    | where isnotempty(ChatThreadId)
    | join kind=innerunique (_ChatThreadId) on ChatThreadId
    | summarize FCTime = min(Timestamp) by ChatThreadId
);

Microsoft names these Defender alerts for the pattern. A defender checks whether they are enabled and routed to a person. They are listed as printed on Microsoft's page, in its coverage table.

Microsoft Teams chat initiated by a suspicious external user
IT Support Teams Voice phishing following mail bombing activity
Remote management event after suspected Microsoft Teams IT support phishing
Suspicious activity using Quick Assist
Uncommon remote access software

These are the file and process names Arctic Wolf gives for the one case it calls potentially novel. They are listed here one per line from the report's prose, arranged by this site. A defender searches endpoint telemetry for them. The report prints no hashes and no address for the Azure Blob Storage download.

Parent process for the PowerShell download and launch: explorer.exe
Download: an MSI from Azure Blob Storage (address not printed)
Bundled files: a PowerShell script and a ZIP archive named archive6.zip
Script: cleaner.ps1
Drop path: AppData\Local\PowershellCleaner\scripts
Loader step: IEX of a joined and decoded array of hexadecimal characters
Implant and interpreter: ss.py and pythonw.exe
Directory queries: System.DirectoryServices.DirectorySearcher via the adsisearcher shortcut

Arctic Wolf's appendix lists attacker infrastructure. Arctic Wolf says all of these are fake and not Microsoft domains. A defender can check DNS, proxy and Teams logs for them. They are shown exactly as Arctic Wolf prints them, already defanged. Arctic Wolf's appendix also lists four "notable payload" domains, including one under a government domain; this site has not reprinted those, because they look like ordinary organisations' domains that may be compromised sites and the report does not say. Display names the report lists include Help Desk, IT Support, HelpDesk Manager, HelpDesk Supervisor, IT Tech Support Internal, Maintenance Service and IT/Help Desk.

Attacker tenants (default onmicrosoft domains)
supportedge33[.]onmicrosoft[.]com / supportedge39[.]onmicrosoft[.]com
helpdeskteam365[.]onmicrosoft[.]com
itendpoint365[.]onmicrosoft[.]com
itcoreportal[.]onmicrosoft[.]com
networkadmin797[.]onmicrosoft[.]com / networkadmin916[.]onmicrosoft[.]com
itadmin922[.]onmicrosoft[.]com
supportagentonline[.]onmicrosoft[.]com
threatpro[.]onmicrosoft[.]com
ithelpplus42[.]onmicrosoft[.]com
corporateitservicellc[.]onmicrosoft[.]com
techsupport2337[.]onmicrosoft[.]com

IT or update themed .top payload and C2 domains
update-software[.]top
infoupdate-it[.]top
soft-program[.]top
getsysmonitor[.]top
programupdate-assis[.]top
expertassist[.]top
sec-check-it[.]top
upd-check-soft[.]top
assis-programupdate[.]top
get-info-check[.]top
updsysseq[.]top
techrelay[.]top
verifsec-update[.]top
sys-update-check[.]top
get-help[.]top
it-assistant[.]top
ms-system-check[.]top
scan-updseq[.]top
it-seccontrol[.]top
verifcontrol-update[.]top
get-upd-sys[.]top
get-sys-info[.]top
getsystembridge[.]top
data-sys-seq[.]top
soft-network[.]top

Help desk lookalike .com domains
helpdesk-support-us-ny[.]com
helpdesk-support-office-3[.]com
helpdesk-support-office-4[.]com
helpdesk-support-us3[.]com
helpdesk-call[.]com
helpdesk-s1x[.]com
itdeskassist[.]com

The question that exposes the gap

Can you say, from your own logs, how many external tenants your staff chatted with last month, how many were created this year, and whether any of those chats was followed within 30 minutes by someone launching a remote support tool? If you cannot, the 400 in Arctic Wolf's report and the 15 minutes both describe other people's environments, and you do not yet know your own numbers.

Key facts