EvilTokens exposes a gap between how organisations assess a mailbox compromise and how quickly attackers can turn its contents into a credible payment request.
—
The small incident that hides the larger campaign
Microsoft’s disruption of EvilTokens, announced on 22 September 2026, concerned more than 12,000 compromised inboxes across more than 10,000 organisations worldwide. The phishing-as-a-service platform fuelled business email compromise campaigns, turning access to legitimate correspondence into material for financial fraud. Microsoft’s Digital Crimes Unit led the action against the operation it tracks as Storm-2992.
The scale matters, but the distribution matters more. Those reported totals suggest roughly one or two compromised inboxes per organisation. They do not establish how accounts were distributed among victims. They do, however, expose a problem with judging an incident primarily by how many accounts were affected: a campaign can be extensive across organisations while appearing narrowly contained inside each one.
A local investigation might see an isolated mailbox, restore access and close the incident. The platform provider can see the pattern across tenants. Those are different views of the same threat, and they can produce very different assessments of urgency. An organisation does not need widespread account compromise to become useful to an attacker.
That is why this development matters beyond the affected organisations. A severity model that treats a single mailbox as a small IT incident may assume that attackers need time to read correspondence, understand relationships and find a route to money. Microsoft’s warning challenges that assumption directly: “For organizations, the lesson is: assume that once an inbox is compromised, criminals may understand its contents in minutes, not days.”
As Ars Technica reported, AI analysed compromised inboxes in batches of 5,000 emails, identifying employees authorised to disburse large sums, their managers and plausible scenarios for approaching them. Microsoft Graph was used to map organisational structures. Attackers searched for pending invoices, wire-transfer information and executive correspondence, then drafted messages impersonating trusted contacts.
The risk signal is therefore not simply that phishing has become more persuasive. It is that access to a small amount of organisational territory can yield a detailed understanding of financial authority. Account count remains useful for describing scope. It is a poor substitute for assessing what the exposed correspondence makes possible.
How legitimate authentication becomes a payment-fraud route
EvilTokens used device code phishing, abusing Microsoft’s legitimate OAuth 2.0 device-authorization flow. The flow exists for input-constrained devices such as smart TVs, printers and conferencing equipment. In the attack, the victim receives a code, visits Microsoft’s genuine device login portal and completes normal authentication, including MFA. That action authorises the attacker’s session, providing tokens without requiring the attacker to steal the password.
The distinction matters for management assurance. The victim can use the real login page and pass a genuine MFA prompt while still granting access to the wrong session. “We have MFA” answers whether an authentication control exists. It does not establish that the user understood what their successful authentication was authorising. It is the same pattern seen when the identity proof becomes part of the attack.
Consider an illustrative path from that authorisation to a payment-fraud attempt. An employee receives a document-signing or invoice lure, both among the themes used by EvilTokens. The employee follows the device-code instructions. Once the attacker’s session is authorised, the mailbox becomes available for analysis.
Suppose its correspondence contains a pending invoice, a discussion about when it will be paid and a manager’s approval. The employee need not personally control a bank account. Their inbox may reveal who requests payment, who approves it, which counterparties are familiar and what language makes a request sound routine. That information gives the attacker a route towards someone who does hold payment authority.
The next step is interpretation. Searching for wire-transfer details identifies the transaction context. Reading executive correspondence and mapping reporting relationships identifies whose apparent instructions might carry weight. Analysing the pending invoice provides a reason to make contact now. AI-assisted drafting can combine those details into a message that appears to continue an existing business exchange.
A request to change payment information can then arrive wrapped in accurate context: a real commercial relationship, an expected invoice and a recognisable approval chain. The requested change is fraudulent even if much of the surrounding message is true. Assessing only its polish, familiarity or apparent relevance misses the decision that matters: whether the payment instruction has been independently verified.
This walk-through does not establish that every compromised mailbox produced a loss. It explains why the absence of multiple affected accounts is weak reassurance. A mailbox can expose the route to a payment without belonging to the person who releases it. Closing the access incident therefore leaves a separate question: what financial decisions could the attacker now influence using what they learned?
Set severity by authority, then protect the decision
Senior management should ask for mailbox severity to reflect what an account can authorise or reveal. Relevant exposure includes payment instructions, pending invoices, executive exchanges and evidence of approval relationships. An incident involving such material deserves assessment as a finance-control event, even when its technical scope is confined to a single account.
That assessment requires the meaning of the correspondence, not just confirmation that access occurred. Security can establish the compromise; identity teams can explain the sign-in route; finance can identify which exposed relationships or transactions create an opportunity for fraud. Their combined assessment should determine whether restoring access is sufficient to close the incident or whether payment decisions also need attention.
This is relevant to payment approvers, executives and employees whose correspondence reveals commercial arrangements. The reported victims included wholesale distribution, construction, financial services, real estate and higher education. The common exposure is a business process in which email conveys authority, context or instructions about money.
Management should also ask whether device-code sign-in is actually needed. Its legitimate purpose does not make unrestricted availability necessary. Microsoft’s recommendation is to allow the flow only where required and block it where possible. The practical decision is to establish which uses are justified and remove an authorisation path that otherwise remains available for abuse.
Payment controls must hold even when the message looks genuine. Requests to change payment details, redirect funds or approve unusual transfers should require verification through a trusted second channel. That channel must be independent of the request being checked. A convincing explanation inside the same email exchange cannot supply independent confirmation of its own legitimacy.
High-authority users should also move towards phishing-resistant authentication, such as FIDO2 security keys or passkeys, alongside monitoring for suspicious sign-in activity. These measures belong with restrictions on unnecessary sign-in flows and independent payment verification. Management should seek assurance about each decision point, from granting a session access to accepting an instruction to move money.
Finally, disruption should not be mistaken for closure. Microsoft seized 50 websites and disabled more than 150 additional domains, but BleepingComputer reported that this was not a takedown and the threat remained active. Affiliates have already created clones such as APToken. The management decision should survive a change of service: assess a compromised inbox by the authority and knowledge it exposes, and require independent verification before that knowledge can be converted into a payment.