Notifications
Clear all
Topic starter
18/08/2026 2:15 pm
TL;DR: Microsoft Teams phishing is no longer an edge case: Team AXON says attackers are abusing default external collaboration features, vishing, screen sharing, and audit-log gaps to impersonate IT help desks and gain initial access. The pattern shows collaboration tools now need identity-aware detection and tighter external communication governance, not just email filtering, according to Hunters.
NHIMG editorial — based on content published by Hunters: Detecting Microsoft Teams phishing and the fake IT help desk threat
Questions worth separating out
Q: What breaks when Microsoft Teams is used for phishing instead of email?
A: Email security controls do not fully cover collaboration-native trust signals such as tenant identity, display names, meeting joins, and user acceptance.
Q: Why do Teams phishing attacks often succeed against identity-aware users?
A: They exploit context, not just content.
Q: How can teams tell whether phishing controls are actually working?
A: Look for fewer successful credential submissions on lookalike domains, lower password reuse, and faster reporting of suspicious messages.
Practitioner guidance
- Restrict external collaboration paths Limit who can initiate chats, calls, and meetings with external tenants, and review whether default external communication settings are broader than business need.
- Correlate Teams audit signals Build detections around ChatCreated, MessageSent, UserAccepted, MessageURLs, chat thread ID, sender UPN, and client IP so analysts can reconstruct suspicious conversations.
- Treat meetings as a phishing channel Extend hunt logic and user guidance to instant meetings, voice calls, mentions, and screen-sharing workflows, because the attacker can move into those paths after trust is established in chat.
What's in the full report
Hunters' full blog covers the operational detail this post intentionally leaves for the source:
- Microsoft 365 audit log field names and example values for ChatCreated, MessageSent, UserAccepted, and TeamsImpersonationDetected
- Detection-oriented hunting queries for suspicious one-on-one chats, foreign tenant users, and low-frequency sender domains
- Simulation notes on message delivery, voice chat behaviour, and file attachment paths inside Teams
- Practical guidance on how screen sharing, meeting workflows, and MessageURLs can be used to refine SOC triage
👉 Read Hunters' analysis of Microsoft Teams phishing and fake IT help desk abuse →
Microsoft Teams phishing: are your collaboration controls keeping up?
Explore further
18/08/2026 3:06 pm
Collaboration platforms now function as identity surfaces, not just communication tools. Once attackers can impersonate IT staff in a chat window, the security question shifts from message filtering to identity trust, tenant trust, and user acceptance control. That makes Teams governance part of IAM and phishing defense at the same time. Practitioners should treat collaboration controls as an identity boundary, not a productivity setting.
A question worth separating out:
Q: Who is accountable when collaboration platforms enable attacker impersonation?
A: Accountability usually spans identity governance, collaboration administration, and SOC detection ownership. If external communication is open by default, the collaboration team owns the configuration risk. If logging and correlation are incomplete, security operations own the detection gap. Strong governance requires both sides to treat collaboration abuse as a shared control failure.
👉 Read our full editorial: Microsoft Teams phishing exposes a collaboration trust gap
