This is a scenario we run for clients. One engagement, one scoped population, against your real Microsoft 365 tenant, with no platform subscription around it.

Here is what we reproduce.

An employee's inbox starts filling with subscription confirmations. Hundreds of them, faster than they can be deleted. A few minutes later a message arrives in Microsoft Teams. The display name reads IT Service Desk. The message says they have noticed the mail flood, they are already working on it, and they need two minutes of screen sharing to apply a filter.

The employee is not being careless. They have a real problem, the offer of help is precisely timed, and the request is one they have complied with legitimately many times before.

In a live intrusion, ninety seconds later a remote session is open. In our engagement, that is where we stop, because the question was already answered.

This is not a scenario we invented. Microsoft published a full cross-tenant helpdesk impersonation playbook in April 2026, and the sequence below follows it.

What the Engagement Includes

Five phases. The first one is where most of the value shows up, and it happens before anything is sent.

Why We Built This Scenario

Email is a hard target now, and it took thirty years to get that way. Teams has not had thirty years, and most tenants are running close to the defaults.

The adversary is not defeating a stronger control. They are moving to a channel where the control was never built, and where the user's default assumption runs in their favor. Three tenant facts make it work.

• External access is frequently open to everyone. The Teams admin setting Teams and Skype for Business users in external organizations can allow all external domains, allow only specific domains, or block specific ones. Plenty of tenants have never narrowed it, which means any Microsoft 365 tenant on the internet can start a chat with your staff.
• The display name belongs to the sender. What your user sees in the chat list is a string the sender chose. There is no equivalent of a verified sender for a chat display name.
• Unmanaged and consumer accounts may also reach in. That is a second inbound path with its own setting, and it is easy to leave open while believing external access has been locked down.

The Reason This Scenario Is Worth Testing Separately

Most organizations already have a verification rule written down. On this channel it does not fire, and the reason is structural rather than a training gap.

Out-of-band verification means confirming a request through a channel the requester did not supply. On Teams, every channel the user instinctively reaches for is inside the requester's control.

• Replying on the Teams thread confirms only that the person who sent the message is still there to answer.
• Calling a number the chat provided confirms only that the caller answered their own phone.
• Messaging the profile that contacted you is the same channel with extra steps.
• Asking the requester to prove who they are hands the initiative to someone who prepared for that question.

There is a second reason this belongs in its own scenario. Microsoft's analysis of these intrusions describes adversaries persuading users to override multiple, clearly presented security warnings. The warning is not missing and it is not badly designed. It is seen and dismissed by someone who believes they are receiving help. A control that is present, visible, and defeated anyway is not one that more visibility will fix, which is precisely why the thing worth measuring is what people are required to do rather than what they managed to notice.

What the Report Answers

A count of who received the message is availability, not risk. The result resolves four ways, and only one of them is a training problem.

The second row is the one almost nobody can produce today, and it is the difference between a control that holds and a control with a hole in it. The target did everything they were taught, produced a record of doing it, and handed over the action anyway. We take that distinction apart in You Cannot Grade a Procedure on a Click Rate.

Alongside the four-way split, the report carries:

Where the evidence to resolve an outcome does not exist in your systems, we report it as unresolved. We do not infer that the control held from the absence of a completed action, because someone who disengaged for an unrelated reason is not a control holding.

What We Will Tell You to Fix

Worth saying plainly: almost nothing on this list is something we sell. Configure the tenant first, because it shrinks the surface for everyone without asking anyone to remember anything.

• Narrow external access to an allowlist of the partners you actually collaborate with. Organization-wide federation can also be managed with Set-CsTenantFederationConfiguration and its allowed and blocked domain parameters.
• Block unmanaged Teams accounts, which is a separate setting from domain federation.
• Turn on Safe Links and Zero-hour Auto Purge for Teams. Microsoft names both in its mitigation guidance for this intrusion pattern.
• Control remote support tooling. Decide deliberately whether Quick Assist should be reachable by an ordinary user.
• Enable attack surface reduction rules that block DLL side-loading, the technique the published playbook uses to get from a remote session to a payload, and restrict WinRM to authorized management workstations.
• Require multi-factor authentication for administrative roles through Conditional Access.

Then the procedure, because allowlisted partners get compromised too.

• One standing negative rule, no exceptions. The service desk will never open a Teams chat to request a remote session, and will never ask you to approve a prompt you did not personally start.
• Define out of band as leaving Teams. The written step has to name a channel the requester could not have supplied: the service desk number in the internal directory, or a ticket the user opens themselves in the portal.
• Ticket first for any remote session, which removes the judgment call from the critical path.
• A report path that costs less than compliance, inside Teams, one button.

The build guide for writing steps that survive contact with a real operator is Teach the Callback, Not the Tell.

Before You Book Anything

Three of these cost nothing but change control, and doing them first makes the engagement more useful rather than less.

1. Open the Teams admin center and read your external access setting out loud. Check the unmanaged accounts setting in the same sitting, because it is governed separately.
2. Publish the negative rule everywhere users look. The service desk does not open Teams chats asking for remote sessions. Put it in the service desk signature block and the Teams channel description, not only in a policy document.
3. Write the one-sentence verification step and name the channel. It has to send the user somewhere Teams did not supply. If you cannot write it in one sentence, we will find that anyway, and you would rather find it yourself first.

Then run the scenario, which is the only step that tells you whether the first three landed. The wider engagement model, including how this sits alongside voice and video scenarios, is on the simulation platform page, and the closely related voice version is in our remote support simulation breakdown.

The Message Was the Only Thing a Person Judged

Go back to the employee with the flooded inbox.

In a real intrusion, every technical step after the remote session opened would have been invisible to them. The only decision they made was whether a chat message from a name that looked right, offering help with a problem they could see happening, was worth acting on.

That is a perceptual judgment made under manufactured pressure, and we already know how those resolve. The warning was on the screen when they made it.

The engagement does not ask whether your users can tell. It measures what they are required to do, and on which channel.

Frequently Asked Questions