external teams message phishing bypassed the email gateway and delivered credential links

TL;DR

Close or fence the chat channel the gateway never sees: review external access settings in Teams, limit which external domains can message your users or require users to accept external chats deliberately, turn on available safe links and attachment protections for Teams, and teach users that an external Teams message asking for sign-in is the new email phish. The email gateway cannot scan a message that never travels as email, so the control has to live in Teams itself.

external teams message phishing bypassed the email gateway and delivered credential links

Use this when

• Users received credential links or file lures in Teams chats from external or guest accounts.
• No corresponding message exists in email logs or quarantine.
• External collaboration is enabled broadly in the tenant.

Not for this skill when

• The lure arrived by email and was also pasted into Teams by a user. Start with the email incident, then brief on the paste.
• Internal Teams accounts are compromised and messaging peers. That is an account incident first.

Steps

1. Collect a sample report and identify the external account, its domain, and whether it came through external access or a guest invitation. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the entry route into Teams is classified from the sample
2. Review Teams external access and guest settings and list which domains can currently initiate chats with your users. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the current external reach is documented before any change
3. Restrict external chat to the domains you actually collaborate with, or disable external access initiation where the business can bear it, keeping a request path for exceptions. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the saved settings show the restricted domain list or the disabled state
4. Confirm Safe Links and Safe Attachments policies cover Teams content in your Defender licensing, and test a known test link in a chat. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: a test link in Teams is scanned or rewritten as the policy intends
5. Publish short user guidance with a screenshot description of the external label on chats and the rule to never sign in from a chat link. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: guidance is published where staff will actually see it

Why it happens

Attackers follow users to the channel with the least scanning. Email gateways, for all their faults, inspect links and files; a Teams message from an external tenant historically received far less scrutiny while carrying the same credential lures, often with a file share or a voice note as the hook. Tenants enable external collaboration for one partner and unknowingly open chat initiation from the whole internet, which is the gap these campaigns walk through.

Variants and edge cases

external teams message phishing bypassed email gateway credential links

The channel bypass wording from the incident.

teams external access phishing chat block external domains settings

The settings variant for Teams admins.

microsoft teams phish from external account safe links protection

The protection feature variant.

Compatibility: Microsoft Teams external access and guest access controls, Defender for Office 365 protections for Teams.

Edge cases to check:

• A common lure is a Teams message about a shared file or a voicemail; include those stories in the user guidance examples.
• Guest accounts created for a finished project linger; audit guests as part of the same fix.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_n9Qli3PdG2yMqxtNkrJngQ