Attackers have moved their phishing operations into Microsoft Teams, contacting employees directly through the platform by operating from Microsoft 365 tenants they control, making their messages appear to come from a legitimate corporate IT function. According to Unit 42, Palo Alto Networks’ threat intelligence division, the technique is spreading across enterprise targets in Europe and North America.
The method is straightforward to execute and difficult for employees to spot. Attackers register Microsoft 365 tenants using domain names designed to resemble real companies, then initiate Teams chats with staff at the target organization. Because the message arrives inside Teams rather than via email, many recipients drop their guard. The chat looks like an internal IT request. Sometimes it is framed as a helpdesk follow-up. Sometimes it asks the employee to install a remote access tool. Either way, once the employee complies, the attacker has a foothold.
Rapid7 documented the same technique in its own incident response cases, noting that attackers used Teams messages to push victims toward running remote assistance software, at which point the attacker takes over the session interactively. No email filters, no attachment scanning, no link analysis. The attack bypasses most of the controls organizations built for email-based phishing.
Why Teams Is a Useful Attack Surface
Microsoft 365 tenants are cheap to create and carry inherent legitimacy. A message arriving from a tenant named contoso-it-support.onmicrosoft.com looks more credible than a suspicious email domain because it is, technically, a real Microsoft-hosted account. External access in Teams is enabled by default in many organizations, meaning employees can receive messages from outside their own tenant without any explicit configuration change on their part.
Typosquatting sharpens the deception. Attackers register tenant names close enough to a target company’s real domain that a glancing read produces no alarm. An employee who receives a message from what appears to be their own IT department, asking them to confirm their credentials or accept a remote session, is operating on trust the platform has lent the attacker for free.
This is the same social engineering logic that let Scattered Spider walk into M&S’s systems through a helpdesk phone call in April 2025. The medium changes. The manipulation does not.
Standard MFA Does Not Solve This
Unit 42 is explicit on this point, standard multi-factor authentication is not sufficient against adversary-in-the-middle techniques and modern MFA bypass methods. When an attacker conducts a live session over Teams, convincing an employee to approve an MFA prompt is part of the script. The employee believes they are authenticating a legitimate IT request. They are handing the attacker a confirmed session token.
Phishing-resistant MFA, specifically FIDO2 hardware keys or passkeys, removes that vector. Unlike TOTP codes or push notifications, FIDO2 credentials are cryptographically bound to the legitimate domain and cannot be relayed to an attacker-controlled session. A user cannot be tricked into approving access to a site or service they are not actually connecting to.
Unit 42’s advisory stops short of providing the technical depth needed to assess exactly which credential flows are being targeted in these Teams campaigns. Palo Alto Networks has commercial reasons to amplify the urgency here. That does not make the underlying technique less real, but organizations should verify their specific exposure before treating the advisory as a complete picture.
Three Configuration Changes That Reduce Exposure
The first is external access in Teams. Review who can initiate contact with your employees from outside your tenant. Microsoft’s Teams admin center allows organizations to restrict external communications to specific trusted domains or disable unsolicited external contact entirely. Most organizations have never revisited this setting since deployment.
The second is remote assistance tooling. Rapid7’s incident response guidance recommends restricting or closely monitoring tools such as Quick Assist, AnyDesk and TeamViewer. These are the tools attackers ask employees to run once initial contact is established. If your helpdesk does not use Quick Assist, there is no reason for it to be available to end users at all. Windows Remote Management should be limited to controlled, named systems.
The third is user awareness, and it needs to be specific. Telling employees to watch for phishing is not enough. They need to know that IT will never initiate contact through an unexpected Teams message asking them to install software or approve an authentication request. Set that expectation explicitly, in writing, from IT leadership. Then test it.
