Microsoft Teams external access: when a trusted chat is the delivery channel

A message from outside your organization does not pass through your email gateway. That single fact is the whole attack. When Microsoft Teams external access is left open, any external tenant can start a chat with your users, and the attacker gets a trusted, real-time channel with none of the filtering, URL rewriting, or attachment sandboxing that email would have applied. The defenses you spent years tuning are all pointed at the wrong door.

The mental model to carry into Teams security is that external access is an unfiltered inbound channel your users trust more than email, and most tenants have it open to the entire world. Email earned decades of user suspicion and layers of gateway defense; Teams inherited neither. An attacker who moves their phishing from your inbox to your chat has stepped around your controls and stepped into a place your users do not expect to be attacked.

How does the attack actually work?

The attacker turns Microsoft’s own federation into a delivery channel. They stand up or compromise an external Microsoft 365 tenant, set a convincing display name - a vendor, a recruiter, an internal-sounding IT alias - and, because open external access permits it, message your employees directly. There is no gateway to clear, no lookalike domain to spot, no spoof to detect, because the message genuinely comes from a real Teams tenant over a sanctioned channel.

From first contact there are two moves. The direct one is phishing inside the chat: a link to a credential-harvesting or consent page, or a payload, delivered with the implicit trust of the Teams interface. The deeper one uses guest access - where an external identity has been invited into a team, the attacker browses and downloads whatever is shared in its channels, turning a chat foothold into data access. In ATT&CK terms this is trusted-relationship abuse, T1199, paired with phishing, T1566, and it is the pattern behind real nation-state activity: Midnight Blizzard (APT29) has used exactly this Teams-message approach against enterprise targets.

Why does it work so reliably?

Three conditions line up in most tenants, and each is a default that favors the attacker. External access is on for anyone. It exists for legitimate partner collaboration, and the path of least resistance is to leave it open to any domain rather than curate an allowlist, so the collaboration convenience becomes an open inbound channel. Users trust Teams. The whole product is built to feel like talking to colleagues, so a hostile message inside it lands with a credibility a suspicious email never gets - people who would hesitate over an emailed link click it in chat.

And guest access accumulates. In a busy tenant, guests get added to teams for a project and never removed, external identities pile up, and eventually nobody can answer the basic question of who can read which channel. Each of those is individually reasonable and collectively an attack surface: an open front door, a trusting audience, and a sprawl of standing access nobody is tracking.

Why is guest access the part that turns a chat into a breach?

Because external access gets the attacker talking to your people, but guest access gets them into your data - and the two are usually governed separately, if at all. A chat over open federation is a delivery channel: it lands a phishing link or a payload. Guest access is a foothold: an external identity invited into a team can browse and download whatever is shared in that team’s channels and files. The most damaging version of this attack chains the two - make first contact over external access, then use existing guest access, or social-engineer a guest invitation, to reach files.

The reason guest access is so exploitable is sprawl. Guests get added to teams for a specific project, a vendor engagement, a one-off review, and then they stay. Over months a busy tenant accumulates external identities nobody is tracking, scattered across teams that were never meant to be externally reachable, until no one can answer who can read which channel. Each individual invitation was reasonable; the aggregate is a large, quiet standing-access surface that an attacker with a foothold can inventory faster than you can.

That is why the fix is not only closing the federation door but pruning the guest access behind it. An allowlist stops arbitrary tenants from messaging your users; a guest-access review removes the standing reach into files that turns a successful chat into an exfiltration. Treating guest access as something to grant and forget is how a phishing message in Teams becomes a data breach rather than just a blocked link.

How do you detect it?

By watching for an external identity touching an internal-trust surface, which is the common shape of every step above. The high-value signals are changes to external-access and federation settings (an attacker or a careless admin widening the door), chats initiated from external domains you have never seen before, new guest accounts added to sensitive teams, and files downloaded by external identities. A first-ever chat from an unknown external tenant, or a guest account that suddenly starts pulling files from a channel, is exactly the kind of event that is invisible to email-centric monitoring and obvious once you are looking at the Teams and federation layer.

The reason this detection is often missing is that security programs instrument email heavily and Teams lightly, on the assumption that internal collaboration is trusted. Open external access breaks that assumption, so the monitoring has to follow the trust: treat external-initiated Teams activity with the same scrutiny you give inbound email, because it is inbound, it just does not look like it.

What is the fix that holds?

Close the open door and prune the standing access - restrict external access to an allowlist of known partner domains rather than open federation, and review guest access to sensitive teams, removing what is not needed. The allowlist is the structural fix: it preserves the legitimate partner collaboration external access exists for while removing the ability of an arbitrary attacker-controlled tenant to message your users at all. Open federation trades a large attack surface for a convenience that an allowlist delivers nearly as well.

For an active incident, the containment move this attack teaches is a scoping discipline: audit what external users messaged and accessed during the window, and treat every delivered link and every downloaded file as a lead to run down, not a closed item. A phishing link delivered in chat may have been clicked; a file pulled by a guest may be the start of exfiltration. The incident is not over when you close the door - it is over when you have chased what came through it while it was open. The through-line is simple: Teams external access is an inbound channel wearing a trusted interface, so govern it like your inbox, not like your intranet.