Unit 42 published a breakdown this week of how attackers are walking into Microsoft Teams chats as “IT support,” getting users to share their screens, and walking out with session tokens before anyone in the SOC has read the alert. The conversation looks normal. The sender’s display name says “IT Helpdesk.” The tenant on the other end belongs to someone the victim has never heard of. By default, Teams lets that conversation happen.
This is a cybersecurity problem that has nothing to do with a missing patch. It’s a configuration story, and it’s one most organizations haven’t told themselves yet. Email phishing has thirty years of muscle memory behind it: gateways, sandboxing, banner injection, user training that at least vaguely sticks. Teams has none of that. The DM from “IT” lands in a UI that the user has been trained to treat as internal and trusted, and the controls you’d expect on an email gateway just aren’t there.

Why “Hi, This Is IT” Works So Well
Three things have to be true for this attack to land, and on a default Teams tenant all three are usually true.
First, external federation is on. Anyone with a Microsoft 365 tenant, including one they spun up an hour ago for $6, can initiate a chat with your users unless you’ve explicitly scoped the allowlist. Second, your users have never seen a Teams message from outside the company before, so the warning banner Microsoft shows for external contacts reads as procedural noise rather than a real signal. Third, “IT” calling to walk you through a “security check” is a script your help desk has run for years. The attacker just borrowed it.
What follows is rarely exotic. The “IT engineer” asks the user to install a remote-support tool, accept a Quick Assist session, or paste a device code into a login page. Within ten minutes the attacker has a primary refresh token, an enrolled device, or both. Your firewall saw outbound HTTPS to login.microsoftonline.com. Your EDR saw Quick Assist, signed by Microsoft, doing exactly what Quick Assist does. Your threat detection stack is looking for the wrong shape entirely.
The Same Pattern Is Everywhere This Week
Teams is the loudest example, but the underlying move, abuse the trusted channel rather than the perimeter, shows up in three different stories on the same day. NFCShare Android malware is being distributed as fake banking app updates hosted on GitHub. Users were trained to trust GitHub as a developer source, and the malware authors leaned on that brand exactly the way Teams attackers lean on the blue checkmark next to a chat. Meta meanwhile is back in court accusing NSO Group of running new spear-phishing campaigns against WhatsApp users despite a standing injunction. The vector is the same: a trusted messaging surface the recipient does not associate with hostile traffic.
The connective tissue is that defenders have spent a decade building threat-protection around email, web, and endpoint, and almost nothing around collaboration tools, messaging apps, and developer-facing platforms. Attackers noticed. The 2026 initial access broker market reflects it.
Configuration And Detection You Can Ship This Quarter
This is not a problem you buy your way out of. The fixes are unglamorous, mostly free, and mostly already sitting in your tenant waiting to be turned on. Treat the next two weeks as a security hardening sprint focused on collaboration platforms specifically.
- In Teams admin center, switch external access from “allow all domains” to an explicit allowlist. If you have suppliers and counsel who genuinely need to chat with your staff, add them. Block the rest.
- Disable Skype consumer interop entirely. There is almost no legitimate 2026 reason for it to be on.
- Turn on the external sender warning, then layer a Teams message banner with your own clear language. The default banner is too quiet.
- Restrict who can initiate screen-sharing and file transfer in external chats. “Nobody” is a defensible answer for most companies.
- Block or alert on Quick Assist, AnyDesk, ScreenConnect, and TeamViewer launches on user endpoints when not preceded by a help desk ticket ID. Your existing EDR can do this with a custom rule.
- Make device code authentication conditional. If you cannot disable it, gate it behind a managed device and a compliant location.
- Force token lifetime down on user accounts that don’t need long sessions, and require reauthentication for sensitive admin scopes.
- Add brute-force controls and anomaly thresholds on the Entra sign-in stream, including device code flows, since that’s where these chats end up converting.
None of this stops a determined attacker. It’s the cyber security equivalent of locking your front door: it raises the cost enough that opportunistic operators move on, and it gives your threat detection tools a smaller, cleaner signal to work with.
On the detection side, the signal that matters is the sequence, not any single event. A first-time external Teams chat, followed within minutes by a remote support tool launch, followed by a new device registration in Entra, is a pattern. Build a correlation that fires on that sequence and routes it directly to incident response without waiting for an analyst to triage three separate alerts in three separate consoles. The defense in depth idea here is not stacking more products, it’s making sure the products you already own can talk to each other about a single user’s bad five minutes.
The Stack Assumption That Just Broke
For years the model was simple: the perimeter has a firewall, the endpoint has an agent, the inbox has a gateway, and anything inside those three walls is internal traffic. Collaboration platforms quietly punched a hole through all three. Teams traffic is internal by definition. WhatsApp on a corporate phone is “personal use.” GitHub releases are “developer tools.” Each of those categories has its own assumed trust, and each of those trust labels is now load-bearing on the attacker’s side of the equation.
The CrowdStrike/Zscaler “continuous identity” announcement this week is a polite acknowledgment of this from the vendor side. So is Cloudflare’s new WAF integration that lets customers turn threat indicators into real-time block rules. Both are essentially saying the same thing: trust decisions need to be reevaluated continuously, in milliseconds, because the channel the attacker is using was authorized when the session started and hostile by the time it ended.
You don’t need to buy either of those to apply the lesson. You need to walk through every channel your users treat as trusted, write down who is allowed to send them messages through it, and then make your tenant configuration match that list. Then rehearse the incident response playbook where a “trusted” message turns out not to be. The teams that do this in June will be the teams not writing breach notifications in October.
Sources
- When “Hi, This Is IT” Comes Through Microsoft Teams (Unit 42)
- NFCShare Android malware spreads via fake banking app updates on GitHub (BleepingComputer)
- Meta claims NSO Group still targets WhatsApp users despite court order (Help Net Security)
- Turning Cloudflare’s threat indicators into real-time WAF rules (Cloudflare)
- CrowdStrike and Zscaler Bring Continuous Identity to Zero Trust Access (CrowdStrike)
Take Control of Your Server Security
Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.
Secure. Automated. Lightweight.
Take Control of Your Server Security
Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.
Secure. Automated. Lightweight.
