A Compromised Mailbox Can Now Map Your Payment Chain

A mailbox compromise used to suggest a familiar containment task: reset the password, review forwarding rules, notify contacts. Microsoft’s September 22 disruption of EvilTokens makes the business consequence more concrete. Once criminals control a mailbox, they can use AI-assisted analysis to build a working map of trusted relationships, payment authority and plausible impersonation targets. The mailbox is not only stolen correspondence. It is reconnaissance material for payment fraud.

That changes a control assumption that many organizations still make implicitly: an email sent from a known account is not sufficient evidence for a changed bank account, an unusual transfer or an urgent payment instruction. It may be genuine. It may also be a request shaped by an attacker who has read enough of the correspondence to know who approves payments, which suppliers are trusted and what language a relationship normally uses.

What Microsoft disrupted

Microsoft described EvilTokens as its Digital Crimes Unit’s first action against an end-to-end AI-enabled cybercrime service. The company said its court-authorized action disrupted infrastructure connected to the service, alongside civil legal action pursued with Health-ISAC. Microsoft reported seizing 50 websites and disabling more than 150 additional domains; Coinbase, which contributed evidence to the civil case, described 50 websites and more than 175 domains. The precise counts differ between the accounts, but both describe a completed infrastructure disruption rather than a warning about a hypothetical threat.

Microsoft linked EvilTokens to more than 12,000 compromised inboxes across more than 10,000 organizations in sectors including healthcare, financial services, construction, real estate and higher education. These are Microsoft-observed figures, not independently audited global totals. Coinbase separately reported tracing approximately $1.1 million in platform revenue across four Tron addresses between October 2025 and June 2026, including more than 1,000 deposits from over 700 addresses.

The service did not expose a cryptographic weakness in Microsoft authentication or defeat multifactor authentication. It weaponized a legitimate device-code sign-in flow. Victims were persuaded to enter a code at Microsoft’s real authentication site, thereby authorizing an attacker session. EvilTokens then combined that access with mailbox tooling and an AI-powered analyst that examined the inbox for useful relationships, payment patterns and fraud opportunities.

Coinbase’s description captures the operational shift. Work that once required hours of manual inbox reconnaissance could be compressed into near-instant automated targeting. AI did not cause every reported compromise, and it was not the only component of the operation. But it reduced the time and skill needed to turn access into a credible, targeted fraud attempt.

What did not change

The disruption does not eliminate business-email compromise or AI-enabled fraud. Microsoft and Coinbase both frame the EvilTokens model as one likely to recur. The attackers still needed victims to authorize a legitimate sign-in flow, and successful fraud still depends on a target organization accepting a false instruction. A takedown can remove infrastructure and interrupt an operator. It cannot retire a technique that combines social engineering, compromised identity and knowledge extracted from routine business communications.

Nor does this mean that every payment request must be treated as fraudulent or that email should be abandoned as a business channel. The practical conclusion is narrower: email can initiate a payment-change process, but it should not complete the evidence needed to alter payment details or approve an unusual transfer. The sender’s mailbox is part of the claim, not independent proof of it.

Move payment verification outside the mailbox

For finance, procurement and accounts-payable leaders, the immediate decision is procedural. A request to change payment instructions, redirect funds or make an exceptional transfer should be confirmed through a known second channel. “Known” matters. Staff should use a telephone number, contact record or secure workflow already held by the organization—not contact details supplied in the request under review.

The control should be designed around the consequence, not the apparent polish of the message. A request can arrive from a real account, refer to a real invoice and imitate a real executive’s style. None of that establishes that the current instruction is authentic. For material changes, an independently initiated callback or another established verification route should be a required step, with a record of who confirmed what and when.

This is not simply a security-team control. It is a finance operating control supported by security. Accounts-payable teams need an unambiguous rule that permits them to slow a seemingly urgent request. Executives and suppliers need to know that a callback is normal procedure, not a sign of mistrust. The best design removes discretion at the point where social pressure is strongest: no independent confirmation, no payment-detail change.

Contain the session, not only the password

The device-code component also changes incident response. Microsoft and Coinbase warn that an attacker’s access can survive a password reset if active sessions and tokens are not revoked. A password reset remains necessary after suspected compromise, but it is not a complete recovery action on its own.

Response playbooks should therefore explicitly include revoking active sessions and tokens, checking for unauthorized device registrations, and inspecting inbox rules and other hidden mailbox changes. Organizations should also evaluate whether device-code authentication needs to be restricted for users or contexts where it is not required. The right configuration depends on how the organization uses device-code flow; a blanket change without understanding operational dependencies can create its own disruption.

This sequence matters because each step addresses a different persistence path. A new password addresses one credential. Token and session revocation terminates already authorized access. Device and mailbox-rule review looks for mechanisms that can restore visibility or maintain access after the obvious credential has changed. Treating these as one generic “account reset” task leaves too much room for a partial cleanup.

The security boundary is now a business process

EvilTokens is notable not because it makes every attacker autonomous, but because it made post-compromise interpretation faster. An inbox contains organizational context: names, reporting lines, supplier conversations, approval habits, deadlines and exceptions. An AI analyst can convert that context into a shortlist of fraud opportunities faster than a human operator scanning messages one by one.

The appropriate answer is not to ask employees to spot every polished impersonation. It is to ensure that consequential business processes do not rely on the channel most useful to the impersonator. Payment controls should require independent confirmation; incident response should revoke the access that a password change does not reach; and teams should rehearse those actions before the next urgent request arrives.

Microsoft’s action has disrupted one service and its associated infrastructure. That is meaningful. The durable lesson is more demanding: a mailbox proves that a message came through a mailbox. It does not prove that the person who normally controls it approved the instruction inside.