Notifications
Clear all
Topic starter
25/06/2026 3:10 pm
TL;DR: Threat actors are increasingly using Microsoft Teams direct messages and calls to impersonate IT support, push remote access tools, and deliver PowerShell payloads, according to Permiso Security. The pattern shows that collaboration platforms now create identity trust paths that security teams must govern alongside email and endpoint controls.
NHIMG editorial — based on content published by Permiso Security: Sliding into your DMs, abusing Microsoft Teams for malware delivery
Questions worth separating out
Q: How should security teams reduce Microsoft Teams social engineering risk?
A: Security teams should reduce Teams risk by limiting external messaging, verifying support contacts through a separate trusted channel, and monitoring for follow-on remote-access activity.
Q: Why do collaboration platforms create identity risk beyond email phishing?
A: Collaboration platforms create identity risk because users often trust internal chat, calls, and file-sharing more than email.
Q: What do security teams get wrong about remote support tools?
A: Teams often treat remote support tools as neutral utilities, but they become high-risk when an attacker uses user consent to gain interactive control of an endpoint.
Practitioner guidance
- Tighten external Teams reachability Disable or limit external chat and calls by default, then create explicit exceptions for known business partners and approved support workflows.
- Separate support identity from messaging display names Require a verified support process that does not rely on display names, emojis, or tenant naming conventions.
- Constrain remote-support tools Allow only approved remote-assistance tools, monitor their first use in the environment, and alert on remote sessions that begin after Teams contact.
What's in the full article
Permiso Security's full blog post covers the operational detail this post intentionally leaves for the source:
- IOC lists and detection IDs for Teams-based suspicious external-user activity
- The PowerShell payload structure, including cryptographic constants and command-and-control behaviour
- The exact persistence mechanisms used, including scheduled task and registry autorun paths
- A deeper walk-through of the sample strings that help defenders pivot across related malware tooling
👉 Read Permiso Security's analysis of Teams abuse for malware delivery →
Microsoft Teams social engineering: what IAM teams should change?
Explore further
25/06/2026 4:32 pm
Collaboration platforms have become trust infrastructure, not just communication tools. Teams abuse works because users treat internal chat as lower-risk than email, while many controls still focus on mailbox filtering and endpoint telemetry. That gap leaves an identity trust surface that is governed informally, if at all. The implication is that collaboration permissions now need the same policy scrutiny as other entry points into privileged workflows.
A few things that frame the scale:
- The number of individuals targeted in these campaigns varies widely, ranging from single users to dozens across different organizations, according to The 52 NHI breaches Report.
- In our 2026 Infrastructure Identity Survey, 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, a useful benchmark for how quickly trust outpaces governance.
A question worth separating out:
Q: Who is accountable when Teams impersonation leads to malware delivery?
A: Accountability usually sits across security operations, identity governance, and collaboration-platform owners because the failure spans platform trust, user validation, and endpoint response. Frameworks such as the NIST Cybersecurity Framework and NIST SP 800-63 help clarify control ownership, but organisations need an internal owner for support-identity verification as well.
👉 Read our full editorial: Microsoft Teams abuse shows how trust becomes an attack path
