Microsoft Teams Phishing

Expanded Definition

Microsoft Teams phishing is a social engineering pattern that uses Teams messages, external guest access, or impersonation of a colleague, support contact, or partner to lower a victim’s trust. The core issue is not Teams as a product alone, but the way enterprise chat inherits organisational trust and can be abused to create a credible first contact inside the tenant.

This technique sits alongside email phishing and other collaboration-platform abuse, but it is distinct because it often bypasses user scepticism that is triggered by outside email. It may involve short, urgent prompts, file-share lures, or requests to move the conversation to a phone call or remote support session. Where an organisation allows external access or has weak identity governance, the attack path becomes easier to sustain.

Guidance versus consensus: there is broad agreement that collaboration tools are attractive phishing channels, but practitioners differ on whether the main control emphasis should be user reporting, tenant restrictions, or conditional access. In practice, it is usually a layered problem.

Examples and Use Cases

Microsoft Teams phishing shows up in routine enterprise workflows because Teams is often treated as a trusted internal channel. The same trust that makes collaboration efficient also gives attackers room to imitate legitimate business activity.

• A fake “IT support” account messages an employee about a supposed security issue and asks them to approve a remote access request.
• An attacker joins as an external guest and uses a partner-like display name to request documents, credentials, or payment action.
• A malicious chat sends the victim to a lookalike login page after claiming that their Teams session or account needs verification.
• A fake internal colleague asks the target to move quickly on a file, invoice, or account reset, then escalates the conversation into voice or screen-sharing.
• Security teams use this term when reporting on abuse of collaboration features rather than traditional email delivery, because the control gaps and user cues are different.

One practical tradeoff is that tighter external collaboration settings can reduce exposure but may also make legitimate partner work harder, so organisations often need a clearer policy for guest access and naming conventions. Official guidance from the OWASP Non-Human Identity Top 10 is relevant when Teams abuse leads to automated follow-on access paths, although the phishing technique itself remains broader than NHI governance.

Security Implications

Misunderstanding Microsoft Teams phishing as “just another phishing email” can leave organisations blind to the different trust signals that collaboration platforms create. The attacker’s advantage is conversational legitimacy: a short thread in a familiar workspace can feel more credible than an external message, especially when the sender appears to be inside the tenant or linked to a known contact.

That trust abuse can lead to credential capture, malware delivery, remote access compromise, payment fraud, or the loss of sensitive internal information. It can also weaken incident response if users assume messages from Teams are inherently safe and do not report suspicious chats promptly.

Failure mechanism: the platform’s implicit trust, guest access, weak identity verification, and poor sender context combine to make social engineering appear routine. Attackers exploit the fact that users often focus on the message content rather than verifying the account provenance or the external collaboration boundary.

Impact: a single successful chat-based lure can expand into account takeover, lateral movement through collaboration channels, and wider exposure of documents, conversations, and internal workflows.

Domain and Governance Relevance

From a cybersecurity governance perspective, this term matters because it sits at the boundary between user trust, identity assurance, and collaboration platform policy. The question is not only whether Teams is secure, but whether the organisation can reliably tell who is allowed to reach whom, under what conditions, and with what trust level.

For identity governance, the material issue is that chat-based contact can become a front door into privileged workflows even when the initial message looks low risk. If external access, guest naming, and session verification are not tightly governed, the collaboration layer becomes a control bypass rather than a productivity tool.

This is where NHI-adjacent concerns can emerge in a material way: attackers may use a compromised service account, a rogue automation, or a delegated workflow to make the abuse look legitimate. Those are not the centre of the term, but they matter when the phishing path transitions from human deception into machine-mediated access or automated follow-on actions.

For NHI Management Group, the practical lesson is that collaboration-channel phishing should be governed as an access-trust problem, not just a user-awareness problem. The organisation needs clarity on external identity handling, alerting, and escalation paths when chat-based contact is the first sign of compromise.

Related resources from NHI Mgmt Group

• How should security teams handle device code phishing when users complete real Microsoft MFA?
• How should security teams detect phishing that comes from legitimate Microsoft identity workflows?
• How should security teams reduce device code phishing risk in Microsoft 365 environments?
• What breaks when Microsoft Teams is used for phishing instead of email?