External Collaboration and Federation Abuse Guide: Locking Down Teams External Access

Cross-organisation chat lets anyone with a Microsoft 365 tenant, a trial tenant or a free consumer account message your staff, and attackers use that path to pose as the help desk. Microsoft has documented ransomware operators flooding inboxes with spam and then contacting the victim through Teams from tenants named "Help Desk" or "IT Support", talking them into a remote support session. This guide covers the controls that decide who can reach your users from outside: Teams external access (federation), unmanaged account access, trial tenant blocking, guest access, the logging that shows external contact, and the detection and response steps that follow. It is written for Microsoft 365 administrators, SOC analysts and identity teams. For the wider Teams configuration baseline, see the Microsoft Teams Security Guide; this page goes deeper on the external contact problem only.

Key takeaways

• External access is on by default. Out of the box, Teams allows chat and calls with all external Microsoft 365 domains, so any tenant an attacker registers can start a conversation with your users.
• Move from "allow all" to an allowlist where you can. The "Allow only specific external domains" setting turns open federation into a set of named partners, which removes most cold-contact phishing at the source.
• Trial tenants and unmanaged accounts are separate switches. Trial-only tenant contact is controlled by its own parameter and unmanaged (consumer) Teams accounts by two more; check all three rather than assuming the domain policy covers them.
• The real damage comes after the chat. The documented attack chains end in a remote support tool session and then ransomware, so remote tool control and phishing-resistant MFA matter as much as the chat settings.
• Log and hunt external chats. Chat creation with external users is recorded (the ChatCreated action), and messages in external threads can be hunted, so a first-contact help desk lure is detectable if you are looking.

How external chat abuse works

Federation in Teams is designed for convenience: users can find, chat with, call and meet people in other organisations by email or SIP address. Microsoft's own description is that external access is enabled by default and lets users communicate with people in other organisations who use Teams, while guests are invited into your directory as Microsoft Entra B2B accounts. Attackers use the first model because it needs no invitation and no account in your tenant.

Microsoft Threat Intelligence described the pattern in its May 2024 report on Storm-1811, a financially motivated group known to deploy Black Basta ransomware. The sequence it documented was:

1. Email bombing: the target's address is signed up to large numbers of subscription services, flooding the inbox and creating a believable reason for IT to get in touch.
2. Help desk impersonation: the actor contacts the user by phone, and from late May 2024 through Teams messages and calls from tenants with display names such as "Help Desk" and "IT Support".
3. Remote support session: the user enters a code into Quick Assist, allows screen sharing and then grants full control.
4. Payload and spread: scripts download tooling (Microsoft lists Qakbot, Cobalt Strike, ScreenConnect, NetSupport Manager and SystemBC), and PsExec is used to deploy Black Basta.

Microsoft's October 2025 report on threats targeting Teams shows the technique has spread well beyond one group. It names Midnight Blizzard impersonating security and support staff to get authentication codes read out, Storm-1674 and Sangria Tempest distributing DarkGate through Teams, Storm-2372 using device code phishing disguised as Teams meeting invitations, and Octo Tempest sending threatening Teams messages during extortion. The same report notes that attackers enumerate tenants, users and federation settings with open source tools and use trial or free tenants to make contact. For the user-facing side of this attack, see the Email Bombing and Help Desk Impersonation over Teams Guide and the Black Basta Threat Actor Profile.

External access, unmanaged accounts and guests compared

Three different mechanisms let outsiders talk to your users, and they are configured in different places. Treat each as its own attack surface.

Two details from Microsoft's documentation catch administrators out. First, a user can use external access only if both the organisation setting and their user policy allow it, so a permissive per-user policy cannot override a tenant block, but a tenant-wide allow plus a default user policy means everyone is reachable. Second, blocking a domain does not block its subdomains unless you also set -BlockAllSubdomains. Microsoft also notes that people from blocked domains can still join meetings anonymously if anonymous meeting join is allowed. Guest governance is covered in the Entra ID Cross-Tenant Access and B2B Guest Governance Guide.

Choosing a federation model

Microsoft documents four scenarios for trusted Microsoft 365 organisations: allow all external domains (the default), allow only specific external domains, block specific domains, and block all external domains. The right choice depends on how much legitimate cross-company chat you have and how well you can maintain a list.

Small organisations: an allowlist of a handful of suppliers, the managed service provider and key customers is often easy to keep. Large organisations: start with an allowlist built from the domains actually used (the audit data below shows which), run a request process with an owner and review date for each domain, and consider separate user policies so that high-risk groups such as finance, executives and help desk staff are more tightly restricted than project teams. Because the user policy and organisation setting must both allow external access, you can switch external access off for selected users with a policy while leaving it on for others.

Whatever the model, keep trial-only tenants blocked and decide deliberately on unmanaged accounts. If business need is limited, turn off -AllowTeamsConsumer; if you must allow it, at least turn off -AllowTeamsConsumerInbound so that consumer accounts cannot search for and message your users first. Microsoft notes that with inbound off, unmanaged users cannot find your users by email, and your users must start all contact.

Implementation: a phased rollout

1. Baseline the current state. Run Get-CsTenantFederationConfiguration and record AllowFederatedUsers, AllowedDomains, BlockedDomains, BlockAllSubdomains, AllowTeamsConsumer, AllowTeamsConsumerInbound and ExternalAccessWithTrialTenants. Export the user-level external access policies and who is assigned to each.
2. Measure real external use. Use the Microsoft 365 audit log (ChatCreated and MessageSent events for Microsoft Teams) for 30 to 90 days to list the external domains your users actually talk to, and how often. This becomes the candidate allowlist and tells you which business owners to consult.
3. Close the free paths first. Confirm trial-only tenants are blocked, restrict or disable unmanaged account contact, and set -BlockAllSubdomains $True if you rely on blocking. These changes rarely break legitimate work.
4. Pilot the allowlist. Apply a restrictive user policy to a pilot ring, such as IT and security, then high-risk groups. Publish how to request a new partner domain and who approves it.
5. Switch the organisation to an allowlist. Move from allow all to allow only specific external domains. Keep the previous configuration exported so you can roll back with a single Set-CsTenantFederationConfiguration call if a critical partner is cut off.
6. Harden the follow-on steps. Remove or block Quick Assist and other remote tools that are not your sanctioned support tool, require phishing-resistant authentication for administrators, and turn on Teams protection features in Defender for Office 365 if licensed.
7. Tell users and the help desk what "normal" looks like. State that internal IT never contacts staff from an external tenant, how the real help desk identifies itself, and how to report a suspicious chat.

Protecting the chat channel itself

Federation settings decide who can make contact. Content and reporting controls reduce what a malicious external message can do once it lands.

• Built-in protection (all Teams licences): Microsoft lists built-in virus protection for SharePoint, OneDrive and Teams, the Teams external domain anomalies report, and near real-time URL warnings in Teams messages, including for URLs found malicious up to 48 hours after delivery.
• Defender for Office 365 Plan 1: adds Safe Links for Microsoft Teams (time-of-click URL checks), Safe Attachments for SharePoint, OneDrive and Microsoft Teams, Tenant Allow/Block List entries for Teams, zero-hour auto purge (ZAP) for Teams, admin quarantine and user-reported Teams items. ZAP for Teams is set under Settings, Email & collaboration, Microsoft Teams protection, and in PowerShell with Set-TeamsProtectionPolicy -ZapEnabled $true. Microsoft documents that ZAP for Teams acts on messages in internal chats and channels, so do not rely on it alone for external first-contact chats.
• Defender for Office 365 Plan 2: adds removing users from Teams chats and advanced hunting on Teams messages in the MessageEvents, MessagePostDeliveryEvents and MessageURLInfo tables.
• User reporting: users can report Teams messages, calls, meetings and participants; reports go to a reporting mailbox, to Microsoft or both depending on the user reported settings. Make sure the SOC actually triages that queue.
• Blocked users list: Set-CsTeamsExternalAccessConfiguration supports blocking specific external users (up to 200), and blocked users are removed from existing chats.

Mail bombing is the usual prelude, so tune email protection as well. The Microsoft Defender for Office 365 Configuration Guide covers the email side.

Where identity fits

The external chat is only the opening. What the attacker wants is a session on the device or a credential: Microsoft documents actors asking targets to read out authentication codes and using device code phishing disguised as meeting invitations. Three identity controls blunt this. Require phishing-resistant authentication, which Microsoft recommends through Conditional Access authentication strength, so codes read out over chat do not complete a sign-in (see the Phishing-Resistant MFA Guide). Block the device code flow for users who do not need it through Conditional Access (see the Conditional Access Guide). And make the help desk verify callers and never initiate unsolicited contact over external chat, which is the subject of the Account Recovery and Help Desk Security Guide.

Detection and measurement

Microsoft's 2025 guidance points to these data sources:

Confirm auditing is enabled in Microsoft Purview before relying on any of this. Useful metrics:

• Federation exposure: whether the tenant is allow all, allowlist or block, and the number of allowed domains with a named owner and review date.
• External first contacts per week: ChatCreated events with a previously unseen external tenant, trending down after the allowlist.
• Report rate: the share of simulated or real external help desk lures that users report rather than engage with.
• Time to triage user-reported Teams items: median hours from report to SOC decision.
• Remote tool coverage: percentage of endpoints where unsanctioned remote support tools are blocked.

Common failure patterns

• Relying on blocklists: blocking the domain from the last incident does nothing against the next tenant, which costs the attacker minutes to register. Blocklists are containment, not a control.
• Forgetting the separate switches: teams lock down federated domains but leave unmanaged account inbound contact on, or re-enable trial tenants for a supplier and never turn it off.
• Trusting the display name: "IT Support" is a display name anyone can set on their own tenant. Users need to be told that the External label means the sender is outside the company, whatever the name says. Help desk social engineering by voice drove the MGM Resorts breach; external chat is the same trust problem on a different channel.
• Leaving remote tools open: if Quick Assist and similar tools are available to every user, one convincing chat converts straight into hands-on-keyboard access.
• No owner for reported messages: user reports land in a mailbox nobody watches, so the early warning is lost.
• Anonymous meeting join overlooked: external domains are blocked for chat but anyone can still join meetings anonymously, which keeps a social engineering path open.

Framework mapping

Practitioner checklist

• Export the current tenant federation configuration and user external access policies.
• Confirm ExternalAccessWithTrialTenants is Blocked.
• Disable unmanaged Teams account contact, or at minimum disable inbound contact.
• Build an allowlist of external domains from 30 to 90 days of audit data, with an owner and review date per domain.
• Move the organisation to "Allow only specific external domains" after a pilot ring, with a documented rollback.
• Check anonymous meeting join and decide whether it is needed.
• Block or remove unsanctioned remote support tools, including Quick Assist where not used.
• Require phishing-resistant MFA for administrators and block device code flow where not needed.
• Deploy hunting queries for external help desk lures and ChatCreated from new tenants, and assign an owner for user-reported Teams items.
• Brief staff and the help desk: internal IT never contacts users from an external tenant.

Standards and references

• Microsoft Learn: Manage external meetings and chat with people and organizations using Microsoft identities
• Microsoft Learn: Use guest access and external access to collaborate with people outside your organization
• Microsoft Learn: Microsoft Teams protection in Microsoft Defender for Office 365
• Microsoft Security Blog: Disrupting threats targeting Microsoft Teams
• Microsoft Security Blog: Threat actors misusing Quick Assist in social engineering attacks leading to ransomware
• MITRE ATT&CK: T1566.003 Spearphishing via Service
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Microsoft Teams Security Guide · Email Bombing and Help Desk Impersonation over Teams Guide · Help Desk Social Engineering Incident Playbook · Entra ID Cross-Tenant Access and B2B Guest Governance Guide