Half of MSPs Saw Token Theft Last Year. Five Controls Break the Attack at Every Stage

We polled the 259 people who registered for a July 2025 webinar on token theft with one question: how many of you have had a token theft incident in the past year? 51% said yes.

That number is the reason this attack deserves a defense-in-depth treatment rather than a single fix. The good news: token theft via adversary-in-the-middle (AiTM) phishing is a chain of dependent steps, and every link in that chain can be audited, tracked, or blocked. This article, a summary of that webinar, walks the kill chain and then the five protections we would prioritize to break it.

How the attack actually works#

Token theft via AiTM starts with a phishing email that directs the user to a legitimate-looking Microsoft sign-in page. The user enters credentials, fulfills MFA, and is redirected to the real website, none the wiser. The attacker, sitting in the middle, harvests the session token, which can be replayed on a different device to take over the account. Think of a theme park visitor handing their identity to a fake ticket office: the attacker takes the ticket and rides everything in the park. These attacks are commonly simulated with the Evilginx framework.

The phishing lure takes many forms, but a common one replicates a legitimate-looking OneDrive or SharePoint sharing email with the man-in-the-middle link embedded:

What happens after the token is stolen#

Goals vary, but after compromise the attacker typically works toward some form of business email compromise leading to:

• Financial loss (tricking users into wiring money to a fraudulent bank)
• Data loss (downloading sensitive information or IP)
• Ransomware

To get there, the attacker usually needs intermediate moves:

• Hiding their presence
• Maintaining persistence (token session lifetimes are limited)
• Moving laterally, compromising other accounts
• Running more phishing campaigns from the newly compromised account
• Exfiltrating data

Every one of those actions can be audited, tracked, or blocked. That is the defense-in-depth opportunity.

Mapping the defenses before choosing them#

There are many protections that interrupt this attack, and availability varies by license. We have covered the reactive side in a separate post on incident response for token theft. This article stays on the prevention side: the posture that stops the attack before the response playbook is ever needed. Rather than walking every control on the map, here are the five we would put in place first.

The five controls, in order of the kill chain#

1. Tune Defender for Office 365 so the lure never lands#

Ideally the phishing email never reaches the inbox and there is no link to click. Review:

• Anti-spam policies
  • Ensure ZAP (zero-hour auto purge) protections are in place; they can remove malicious messages from inboxes after delivery.
    • Configure spam filter policies (opens in new tab)
    • Zero-hour auto purge in Defender for Office 365 (opens in new tab)
  • Configure message sending limits to stop phishing campaigns being sent from a compromised account post-breach.
    • Configure outbound spam policies (opens in new tab)
• Anti-phishing
  • Configure impersonation protections and targeted user protections.
  • Ensure safety tips are on and auto-forwarding is disabled.
    • Configure anti-phishing policies in EOP (opens in new tab)
• Safe Links
  • Configure Safe Links policies for proper sandboxing of URLs.
    • Set up Safe Links policies (opens in new tab)

2. Block the AiTM infrastructure with web filtering#

This control requires devices enrolled in Defender for Business or Defender for Endpoint. Block newly registered domains and parked domains, the categories attackers typically use when standing up Evilginx and other AiTM infrastructure.

Web content filtering in Defender for Endpoint (opens in new tab)

3. Make the token worthless: require a managed device#

In our view this is the most important and most powerful layer. We have published a full breakdown of recommended Conditional Access policies, but the most achievable for most organizations and MSPs is requiring a managed device. This policy prevents the token from being harvested through the AiTM page at all.

4. Cut off the persistence playbook#

If an attacker does harvest a token, they will usually try to stay in by:

• Registering a device or another MFA method (in the AiTM flow they captured the password too)
• Registering an application (a new identity with its own permissions to act through)
• Setting up inbox rules (hiding their presence during reconnaissance or while phishing other users)

To combat this:

• Require MFA to register security information or devices (opens in new tab)
  • Requires adopting Temporary Access Passes to support new user onboarding.
  • Prevents an attacker from adding or changing MFA, or registering a device to the network.
    • Require MFA for device registration (opens in new tab)
• Do not allow users to consent to or register applications (opens in new tab)
  • Prevents regular users from consenting to traitorware apps (eM Client, PerfectData, CloudSponge, and similar).
  • Prevents new app registrations that carry their own credentials and permissions.
• Set up alerts for inbox rules to flow to your PSA (opens in new tab)
  • You could block inbox rule creation tenant-wide, but that is unworkable for most organizations because the rules have legitimate business uses. Monitor them instead, as leading indicators of compromise.

5. Automate the response you would otherwise do at 2 a.m.#

The final layer is automation for the common incident response moves: suspending the account, rotating passwords, rotating sessions. This is where you hit what we would call the Microsoft Paywall Problem for SMB: automated response features are gated primarily behind Entra ID P2 and E5. On lower tiers, a user detected as high risk in Entra triggers no automated action at all, which is why many MSPs lean on tools like Huntress or Blackpoint to act on their behalf. To be clear, this layer is defense in depth; the Conditional Access policy in step 3 stops the token harvesting up front.

If the tenant has P2, E5, or the E5 Security add-on that bolts onto business plans, configure:

• Require a password reset at medium to high user risk (opens in new tab), and/or
• Block the account at high risk
  • The catch: a false positive can lock an executive out during an overseas business trip, so have a fast remediation path. We would rather be over-protective here, but at minimum enforce the password resets.
• Automated attack disruption (opens in new tab)
  • Nothing to configure. It ships with E5 and uses signals from across the M365 security stack to analyze potential attacks and take automated action.

Checking a tenant against this list, automatically#

At CloudCapsule, we built a Token Theft Playbook that automates a tenant assessment against these protections. The output can be branded and used as a client-facing document to scope an uplift project:

Half the MSPs we polled have already lived this attack. The five layers above decide whether the next attempt ends at a blocked email, a worthless token, or a wire transfer.