EvilTokens: How AI Helped Hijack Over 12,000 Mailboxes

Status: October 10, 2026

Microsoft published an analysis of EvilTokens, a cybercriminal operation that leveraged AI to refine phishing lures and scan hijacked email accounts for high-value targets. The report was published on September 22, 2026. The primary threat here is not merely a convincingly written email. Once attackers obtain access to correspondence, they gain the exact context needed to select their next target and tailor fraudulent requests to ongoing business matters. This case from our series of AI case studies demonstrates why mailbox protection cannot be separated from the verification of decisions triggered by mailbox contents.

Timeline

1. February: The underlying service was already known to threat researchers. Microsoft, September 22, 2026.
2. Microsoft disclosure: The report covered campaigns and mitigation efforts over a six-month observation window, including a coordinated disruption of attacker infrastructure. September 22, 2026.
3. October: CERT-EU shared intelligence regarding infrastructure takedowns and arrests. October 2026.

What the data shows

How it worked: session approval, then intelligence gathering

In Microsoft’s technical breakdown, gaining mailbox access and exploiting its content are two distinct operational phases. Tricked user approvals granted attackers active session tokens; AI then assisted both in crafting lures and in sifting through stolen messages. September 22, 2026. This distinction provides vital clarity: the tool assisting the fraudsters was not an autonomous actor, and unauthorized account access does not automatically guarantee that every subsequent fraudulent request succeeds.

Analysis: context matters more than perfect grammar

Polished writing helps attackers make a convincing first impression. However, the true value of compromised inbox data lies in real business context: it provides the thread history, ongoing projects, and relationship dynamics needed to make a fraudulent request look like a natural continuation of legitimate business. Polishing a message only touches its tone and grammar; information extraction dictates the topic, the target, and the justification. That context represents a significant hazard, though it still does not guarantee that every fraud attempt succeeds.

This shifts the defensive perimeter. The question should no longer be whether an email sounds suspicious, but whether the sender possesses the authority to request that specific action. A familiar topic, flawless phrasing, and consistency with prior threads do not constitute authorization to grant system access or alter banking details. Narrative credibility and operational legitimacy must be evaluated separately.

AI should be assessed by the specific tasks it performs, not treated as a monolithic threat label. Lure drafting and inbox harvesting require completely different countermeasures. In the first phase, defenses must stop unauthorized session approvals. In the second, organizations must prevent trust in an email account from turning into blind trust in every request sent from it. Simply banning employees from using AI tools addresses neither vulnerability.

There is also no reason to treat AI-generated text as an autonomous threat actor. Human operators select the targets and exploit the access. Keeping these roles distinct makes it easier to assign accountability and design security procedures: an effective verification process halts unauthorized transactions regardless of how the email was written. It does not need to detect AI authorship to work.

Who gained, who lost, and the remaining risks

The documented outcome for the attackers was unauthorized mailbox access. Reducing the manual labor needed to sift through email threads is distinct from securing actual financial profit. While structured intelligence makes subsequent fraud easier, it does not dictate the outcome. Without downstream data, we cannot directly measure the campaign’s final financial yield based solely on the involvement of AI.

Victims lost control over their email access. The potential fallout extends to the business relationships documented in those threads: clients, contractors, and partners. This is why remediation cannot stop at resetting account credentials. At the same time, this does not mean every compromised organization suffered identical damage or that every contact list was weaponized successfully.

Disrupting threat infrastructure is a major win for defenders. For an affected company, however, internal benchmarks matter just as much: did you revoke the unauthorized tokens, identify the blast radius, and audit affected business workflows? Coordinated law enforcement takedowns and internal incident closure are two very different metrics, and both require separate evaluation.

Key takeaways for organizations and users

The most effective controls govern the exact moment an incoming message attempts to trigger a business action. These rules should be simple, established before an incident occurs, and actionable without guessing the sender’s underlying intent.

• Session approvals: Users must clearly understand which resource they are approving access to and verify that the prompt originates from an action they initiated themselves. Any unexpected prompt should be declined immediately and reported via verified internal support channels.
• Banking detail changes: Organizations must enforce out-of-band verification. Contact details listed inside the payment update request itself must never serve as the sole validation source.
• Incident response readiness: Your playbook must clearly designate who is responsible for revoking sessions, scoping compromised data, preserving forensic logs, and notifying affected stakeholders.
• Empowering staff to halt workflows: Employees must know exactly where to escalate suspicious requests and who has the authority to prioritize security verification over tight project deadlines.

For individual users, the core principle is decoupling incoming requests from the verification method. Reach out to your administrator or service provider independently rather than following instructions provided inside an unexpected email. If you suspect an account compromise, follow your organization’s formal recovery procedures instead of interacting with the suspicious message.

Hypothetical scenario: an urgent bank account change

Consider a situation where your finance department receives a request to update vendor banking details in the middle of an ongoing contract billing cycle. The email references current invoice numbers, aligns with past correspondence, and highlights an approaching deadline. This scenario illustrates how to apply these defensive lessons; it is not a direct transcript from the EvilTokens investigation. The dilemma lies between executing a familiar-looking instruction quickly and freezing payment until confirmation arrives.

The employee does not need to determine whether the message was drafted by an AI. Instead, they must verify the change through a pre-established, independent communication channel. If verification cannot be obtained, the request escalates to an authorized manager who evaluates the risk. Urgency should never bypass established validation controls; it should trigger standard escalation pathways.

If account takeover is suspected at the same time, responsibilities must remain distinct. IT security handles credential revocation and token invalidation, while the finance lead reviews the pending payment. Securing the mailbox does not prove that a pending invoice is legitimate. The practical strength of a procedure lies in assigning clear ownership and definitive sign-off criteria to every decision.

What we still do not know

Public reports do not detail total financial losses, the precise number of unique individuals affected, the total volume of recovered mailboxes, or the exact success rate attributable to AI-assisted targeting. Nonetheless, the practical conclusion is clear: organizations must secure both mailbox access tokens and the business decisions triggered by email communications.

Testing workflows without phishing simulations

You can test your internal verification workflows using a hypothetical payment change scenario, without sending simulated phishing emails or exposing live correspondence. The purpose of this exercise is to confirm who can pause a transaction, where verified vendor contacts are securely stored, and who makes authorization decisions when key personnel are out of the office. This validates internal operational resilience rather than testing individual employee vigilance.

Google · Your sourcesQuantslant higher in your Google - one clickAdd to preferred sources →

Sources

• Microsoft: Unmasking EvilTokens - September 22, 2026.
• CERT-EU: Threat Intelligence Bulletin - October 2026; publication day not specified in public release.