Microsoft Teams abuse shows how trust becomes an attack path

At a glance

What this is: This is an analysis of how Microsoft Teams is being abused for social engineering, remote access, and malware delivery, with the key finding that trusted collaboration channels can be weaponised as initial access paths.

Why it matters: It matters because identity, messaging trust, and remote-support workflows now intersect, so IAM, NHI, and endpoint teams need to treat collaboration platforms as part of the access surface.

👉 Read Permiso Security's analysis of Teams abuse for malware delivery

Context

Microsoft Teams has become a trusted collaboration layer inside many enterprises, which makes it useful to attackers who want to blend into normal work patterns. In this campaign pattern, the identity problem is not just malware delivery, but the exploitation of platform trust, external chat permissions, and support-like personas to create a believable access path.

For IAM and NHI programmes, the key issue is that communication platforms can become part of the identity control plane even when they are not treated that way in policy. When users trust messages, calls, and remote-assistance prompts too readily, security teams lose the separation between collaboration, authentication, and privileged support workflows.

Key questions

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. The main goal is to prevent a chat interaction from becoming an execution path. Controls should cover tenant settings, user awareness, and endpoint detections together, not in isolation.

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. That trust can be exploited to initiate support impersonation, remote-access requests, and credential prompts. The result is that a messaging app becomes part of the access surface, which requires identity governance rather than just content filtering.

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. The mistake is focusing only on the tool’s legitimacy instead of the context in which it is invoked. Approval, verification, and logging matter as much as allow-listing.

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.

Technical breakdown

Teams impersonation as an access path

Attackers create or compromise Microsoft Teams identities and use display names such as IT support or help desk to appear legitimate. The goal is not sophisticated exploitation at first, but credibility: once a user accepts the conversation, the attacker can move the interaction into a channel that feels routine and internally approved. External communication permissions matter here because they determine whether the attacker can reach the target at all. The abuse is social, but the control failure is identity trust without sufficient verification of sender legitimacy.

Practical implication: restrict external Teams communication by default and validate any support contact through a separate trusted channel.

Remote access handoff and payload delivery

After trust is established, the attacker persuades the user to install QuickAssist or AnyDesk, then uses that remote-access channel to operate on the endpoint. This is a common human-to-machine escalation path: the user becomes the access broker, and the remote tool becomes the execution bridge. In the observed campaign, the payload was PowerShell-based, which means the attacker can run additional commands without relying on a traditional exploit chain. The security problem is that legitimate support tooling can be repurposed into attacker-controlled remote administration.

Practical implication: control which remote-support tools are allowed, and require stronger validation before any assisted session begins.

PowerShell payloads, persistence, and evasion

The delivered script uses layered techniques common to commodity and affiliate malware: hidden PowerShell execution, single-instance enforcement, a critical-process flag, credential prompting, and persistence through scheduled tasks or registry autoruns. It also encrypts communications with hardcoded key material, which helps conceal command-and-control traffic. These features show an operator focused on durable access, credential capture, and resilience if one delivery path fails. For defenders, the important point is that the initial Teams message is only the opening move; the real risk is endpoint compromise that outlives the conversation.

Practical implication: monitor for hidden PowerShell, suspicious autoruns, and remote-support execution sequences after Teams-based contact.

Threat narrative

Attacker objective: The attacker wants to convert a trusted collaboration interaction into remote endpoint control, credential capture, and persistent malware delivery.

1. Entry begins with a direct Microsoft Teams message or call from a newly created or compromised tenant impersonating support staff and abusing trust in the collaboration platform.
2. Escalation occurs when the victim is persuaded to install QuickAssist or AnyDesk, giving the attacker a remote control channel to execute PowerShell and deploy follow-on payloads.
3. Impact follows through credential theft, persistence via scheduled task or registry autoruns, and encrypted command-and-control that enables longer-term compromise.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

The failure mode is support persona trust without independent verification. When an attacker can convincingly present as IT support inside a sanctioned platform, the user is being asked to authenticate authority socially rather than technically. That is a governance failure, not merely a phishing problem. Security teams should recognise that the control gap is not message delivery, but the absence of a verified support identity workflow.

Remote-assistance tools turn human trust into machine execution. QuickAssist and AnyDesk are legitimate support mechanisms, but in this pattern they become attacker-controlled execution bridges once the user consents. That makes support tooling part of the identity attack chain, especially where approval and validation are weak. Practitioners need to treat remote-support access as a privileged action path, not a convenience layer.

Credential prompts inside familiar workflows create a silent escalation path. When malware uses native Windows prompts to harvest credentials, the user experience masks the boundary between normal administration and attacker activity. This is especially dangerous because it bypasses the expectation that malicious activity will look obviously malicious. The implication is that identity assurance must extend into endpoint interaction design, not stop at login.

Microsoft Teams abuse exposes a specific governance concept: collaboration-channel trust debt. Organisations accumulate trust in internal messaging faster than they create controls for validating who can initiate support-like interactions. That trust debt is what attackers spend first. The practitioner conclusion is simple: if collaboration channels can trigger access, they must be governed as part of the identity perimeter.

From our research:

• 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.
• For a broader identity-risk baseline, read Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and privilege issues that make these trust failures harder to contain.

What this signals

Collaboration-channel trust is becoming a durable attack surface. Security teams that still treat Teams as a communications problem will miss the governance issue, which is that users are being asked to validate authority inside a channel attackers can imitate. The practical shift is to fold collaboration tools into identity control design, not only into awareness training.

Support workflows need a defined identity verification step. A support request that begins in chat should not be allowed to progress to remote access or credential entry without an independent validation step. This is the point where message trust becomes privileged execution, and it is where policy should force friction.

Behavioural monitoring must follow the handoff from social engineering to endpoint action. A useful signal is not merely that a Teams message was suspicious, but that hidden PowerShell, autorun creation, or remote-assistance use followed shortly after. That correlation tells you the interaction crossed from persuasion into compromise.

For practitioners

• 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. Review tenant-to-tenant permissions and guest settings alongside message filtering because the initial access path is identity-based, not malware-based.
• Separate support identity from messaging display names Require a verified support process that does not rely on display names, emojis, or tenant naming conventions. Use a second channel for validation before any request to install remote-access software or share credentials is accepted.
• 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. Treat any QuickAssist or AnyDesk invocation following an external chat as a potential compromise sequence.
• Harden PowerShell and autorun monitoring Watch for hidden PowerShell execution, suspicious scheduled tasks, registry autoruns, and credential prompts that appear during support-like activity. Correlate these events with collaboration-platform logs to reconstruct the handoff from social engineering to endpoint compromise.

Key takeaways

• Microsoft Teams abuse shows that trusted collaboration tools can function as initial access paths when identity verification is weak.
• The campaign combines impersonation, remote access tooling, and PowerShell payload delivery, which makes the identity and endpoint layers part of the same attack chain.
• Organisations should govern external chat, support impersonation, and remote-assistance use together, because the failure begins in trust and ends in execution.

Key terms

• Collaboration-channel trust debt: The accumulated assumption that internal chat or meeting tools are safe because they feel familiar. In practice, this creates a blind spot where attackers can impersonate support, push remote access, or request credentials inside a trusted interface that users are less likely to question.
• Support persona impersonation: A social engineering technique where an attacker adopts the identity, tone, and naming patterns of help desk or IT staff to gain compliance. The purpose is to convert user trust into a pathway for remote access, credential collection, or malware execution without needing a traditional exploit.
• Remote-assistance escalation: The point at which a legitimate support tool becomes an attacker’s execution bridge because the victim approves the session. This matters in identity security because the human user is effectively delegating control, and that delegation can bypass ordinary perimeter or email-based controls.
• Persistence via autorun: A method of staying on a system by adding execution paths that run automatically at login or startup, such as scheduled tasks or registry entries. It is common in malware because it survives reboots and can re-establish access even after the initial lure is removed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Permiso Security: Sliding into your DMs, abusing Microsoft Teams for malware delivery. Read the original.