LearnMicrosoft Teams › 11 · Security

Phishing and vishing through Teams

Attackers moved to Teams because users trust the purple chat more than email. The kill-chain runs through external access defaults — and the controls are configuration, not products.

The attack anatomy (as actually practised)

  1. Contact: a throwaway or compromised M365 tenant externally messages your users (open federation default), display-named "IT Support" / "Help Desk" — or adds them to a meeting invite, which renders even more trustworthy.
  2. Pretext: MFA-fatigue follow-up calls ("approve the prompt I just sent"), fake incident response, payload links in chat (Teams chat historically got less link-scanning attention than mail — Safe Links coverage, next concept, is the counter).
  3. Action: user approves MFA / installs "support tool" (Quick Assist pattern) / clicks the credential harvest. From there it's a normal intrusion.

Why it works: external banners are subtle, display names are attacker-chosen, and voice/video adds false legitimacy (deepfaked "executives" have entered the chat — literally).

The control stack (in order of value-per-effort)

  1. Federation stance (TenantFederationConfiguration — scanned nightly): open -> allowlist is the single biggest cut; at minimum block consumer Teams chat and known-abuse patterns. Pair with the org's risk appetite per the three-doors concept.
  2. External identification hygiene: the client labels external people — train the label, not the logo; attacker display names can't remove the (External) tag.
  3. Defender for Office 365 coverage on Teams (Safe Links/Attachments in Teams — next concept) + user reporting of suspicious Teams messages enabled, so the SOC sees the campaign's first minutes.
  4. MFA that resists fatigue: number matching/context — the vishing call's 'just approve it' dies against a number-match prompt.
  5. Meeting hygiene: lobby + identity verification (meeting-security concept) against invite-borne entry.

What to watch (proofs)

  • The front door's state: your scanned federation config — the serv365 drift alert on AllowedDomains/consumer switches IS the control monitoring.
  • Campaign visibility: Defender/Purview alerting + user-reported Teams messages queue — first-report-to-SOC latency is the metric that decides blast radius.
  • External-chat telemetry: audit log external chat creation events by originating domain — a spike from one unknown tenant is the campaign signature; block and hunt.
  • The drill: a red-team external "IT support" chat exercise — report rate vs approve rate, tracked quarterly; the number the awareness budget answers to.

PowerShell for this concept

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.