Teams Impersonation Now Targets One in Three Organizations

Here’s the attack, assembled from how these actually run — not a single reported incident, but the pattern you should assume is aimed at you. A finance clerk gets a Teams chat on a Friday afternoon from someone showing as the CFO: right name, right-ish photo, the little presence dot glowing green. Urgent vendor payment, do it before the weekend close, I’m in back-to-backs so just handle it. In the version that works, she handles it — and the money is gone before anyone notices the account was an external guest on a lookalike domain, invited in weeks earlier and sitting quiet.

Nobody got phished in the way we trained people to expect. No dodgy link, no attachment, no email gateway to flag it. Just a chat window that looked exactly like every other chat window, because it was every other chat window.

Redmond Magazine is reporting research that puts this class of attack at 30% of organizations. Read that carefully before you panic: targeted, not breached. The attack surface is wide; the success rate depends entirely on controls you may or may not have bothered with. That gap — between “they tried” and “it worked” — is the whole story.

Three doors, all unlocked by default

Teams impersonation comes in through one of three doors. The first is the guest invite: anyone in your tenant with default permissions can invite an external user, and by default that includes regular members, not just admins. The attacker registers a lookalike domain, gets invited (or self-invites through a shared channel), sets a display name that matches a real executive, and waits.

The second is external federation — Teams’ ability to chat with users in other tenants. If yours is set to allow communication with any external domain, an attacker spins up a free tenant, names a user after your CEO, and messages your staff directly. No invite required. The recipient sees an “External” tag, which research and lived experience both confirm most users ignore completely.

The third door is the ugly one: a genuinely compromised internal account. No external tag, no lookalike domain, nothing to notice. This is why Teams gets treated as the undefended perimeter — we spent a decade hardening email with DMARC, Safe Links, and anti-phishing rules, and left the chat app wide open on the assumption that “inside the tenant” meant “safe.”

Find your exposure before someone else does

Start with what external access actually allows and who’s already inside. Read-only, nothing state-changing — look before you touch.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Connect-MgGraph -Scopes "User.Read.All","Policy.Read.All" -NoWelcome
​
# Who can invite guests? B2B collaboration policy
Get-MgPolicyAuthorizationPolicy |
    Select-Object -ExpandProperty DefaultUserRolePermissions |
    Select-Object AllowInvitesFrom
​
# Enumerate guest accounts with pagination + error handling
try {
    $guests = Get-MgUser -Filter "userType eq 'Guest'" -All `
        -Property Id,DisplayName,Mail,CreatedDateTime,SignInActivity `
        -ErrorAction Stop
    $guests |
        Select-Object DisplayName, Mail, CreatedDateTime,
            @{n='LastSignIn';e={$_.SignInActivity.LastSignInDateTime}} |
        Sort-Object CreatedDateTime -Descending |
        Export-Csv .\guest-review.csv -NoTypeInformation
    Write-Host "Exported $($guests.Count) guests for review."
}
catch {
    Write-Error "Guest enumeration failed: $($_.Exception.Message)"
}

Review that CSV like a human. Any guest on a near-miss of your own domain, or a display name matching an executive, gets investigated — not auto-deleted. For external federation, check Teams admin center → Users → External access and move from “allow all domains” to an allow-list. For guest chat, External access → “People in my organization can communicate with external Teams users” should be scoped, not wide open.

Don’t assume Defender for Office 365 has this covered the way it covers mail. Its Teams coverage has grown, so check exactly what your plan protects inside chat rather than taking it on faith — and keep your anti-phishing impersonation protection tuned, with VIPs on the protected-users list, since that’s where it’s strongest. Conditional Access should require MFA and compliant devices for guest sign-ins, because a compromised guest is a compromised insider.

What this keeps teaching us

1. “Inside the tenant” is not a security boundary. A green presence dot authenticates nothing. Train users that urgency plus payment plus Teams equals a phone call to verify — on a known number, not one in the message.
2. Default guest-invite permissions are too generous. Restrict invitations to admins or a delegated role. Most staff never need to invite anyone.
3. Open federation is a liability, not a feature. Allow-list the external domains you actually partner with. Everyone else can email you like it’s 2015.
4. Audit guests on a schedule. The lookalike account in that scenario sat dormant for weeks. A monthly review of recently created guests would have caught it cold.

The attackers didn’t find a vulnerability. They found a habit. That’s a much harder thing to patch.