Microsoft has disrupted the EvilTokens service, an AI-powered criminal operation reportedly linked to 12,000 hacked email inboxes. The service allegedly abused access tokens to gain or maintain access to email accounts.
The action, reported on 23 September 2026, is particularly relevant to organisations using Microsoft 365. Although the disruption targets the service behind the activity, organisations may still need to identify compromised accounts, revoke exposed tokens and examine suspicious application permissions.
What happened to the EvilTokens service?
Microsoft took action against EvilTokens after the service was connected to approximately 12,000 compromised inboxes. EvilTokens was presented as an AI-powered criminal service, suggesting that automation or artificial intelligence supported some part of its malicious operations.
The available report does not specify exactly how AI was used. It may have helped operators process stolen information, automate account access or manage activity at scale, but those possibilities have not been confirmed in the published details.
The central feature of the operation was its alleged abuse of tokens. In cloud services, tokens are digital credentials issued after an identity or application has been authenticated and authorised. They allow a user or application to access defined services without sending a password with every request.
This makes a valid token valuable to an attacker. If obtained or generated through deceptive authorisation, it may provide access to an inbox even when the account owner has not directly disclosed a password. The permissions attached to the token determine what the holder can do.
The report describes the affected inboxes as hacked, but it does not provide a breakdown of organisations, industries or countries involved. It also does not establish whether all 12,000 inboxes were Microsoft 365 accounts, whether the figure represented confirmed victims, or how long individual accounts remained accessible.
How the EvilTokens service abused account access
The EvilTokens service reportedly relied on token abuse rather than being described simply as a password theft operation. That distinction matters because token-based access can behave differently from a conventional login using a username and password.
Microsoft 365 and other cloud platforms use access tokens to support normal activities such as opening email, synchronising data and allowing approved applications to work with organisational accounts. Tokens can carry specific permissions and normally have defined validity conditions.
An attacker who obtains a usable token may be able to make authorised requests within those permissions. Depending on the token and the account configuration, this could expose mailbox content or support continued access until the token expires, is revoked or becomes invalid for another reason.
The source material does not identify the original route through which EvilTokens acquired or created tokens. It does not say whether the operation used phishing, malicious applications, stolen browser sessions, compromised devices or another technique. Those details should therefore not be treated as confirmed aspects of this incident.
Why a password reset may not be sufficient
Token abuse can complicate incident response because changing a password does not necessarily invalidate every active session or every permission previously granted to an application. The precise outcome depends on the platform, token type and administrative action taken.
For that reason, an investigation into possible EvilTokens activity should not stop after resetting a user’s password. Administrators should also review sessions, refresh tokens, application consent and other methods through which the account may remain accessible.
Potentially relevant evidence could include unfamiliar application grants, mailbox access from unexpected locations, unusual sign-in records and activity inconsistent with the user’s normal role. These indicators are not proof of EvilTokens involvement on their own, but they can help determine whether an inbox was exposed.
Timeline and current EvilTokens exploitation status
The disruption was publicly reported on 23 September 2026. At that point, EvilTokens had reportedly been linked to 12,000 hacked inboxes and Microsoft had acted against the service.
The available reporting does not provide earlier milestone dates, such as when EvilTokens began operating, when Microsoft first detected it or when individual inboxes were compromised. It also does not describe the legal, technical or infrastructure measures used in the disruption.
Microsoft’s action indicates that the EvilTokens service itself was disrupted. However, disruption of a criminal service does not automatically remove access already established in every victim environment. Previously issued tokens, active sessions, malicious application permissions or copied mailbox data may require separate remediation.
The report does not confirm whether the service has been permanently dismantled, whether every component was disabled or whether its operators could reappear using different infrastructure. Organisations should consequently treat the disruption as an important intervention, not as evidence that every associated compromise has been resolved.
There is also no published product and version list in the supplied report. The event is relevant to Microsoft 365 environments because the recommended response centres on email accounts, tokens and application permissions, but no particular Microsoft 365 edition, build or software version has been identified as uniquely vulnerable.
Who may be affected by the EvilTokens service?
The directly affected population comprises the reported 12,000 hacked inboxes. No named victims or confirmed geographical distribution were included in the source material.
Organisations using Microsoft 365 should pay particular attention where users can authorise third-party applications, where privileged accounts have mailbox access, or where an unexplained session has remained active. The investigation should remain evidence-led because the report does not provide a public list of affected tenants or accounts.
Possible consequences depend on the permissions and data available through each account. Access to a business inbox could expose messages, attachments, contacts or operational information, while access to a privileged account could create wider risk. The report does not confirm that every affected inbox experienced the same level of access or data exposure.
Actions for Microsoft 365 organisations
Organisations should focus on identifying and invalidating access that may have survived the EvilTokens disruption. Priority actions include:
- Review recent sign-in, mailbox and application activity for accounts showing unusual behaviour.
- Inspect user and administrator consent grants, then remove applications that are unknown, unnecessary or unauthorised.
- Revoke active sessions and relevant tokens for accounts suspected of compromise, rather than relying only on password changes.
- Confirm that access controls and consent policies restrict unnecessary application permissions.
- Preserve relevant audit records and investigate whether email or attachments were accessed, copied or used for further activity.
Response teams should document which permissions were granted and what resources those permissions allowed the holder to reach. This provides a more accurate assessment than assuming every compromised token delivered complete mailbox access.
The EvilTokens service demonstrates why identity investigations must include tokens, sessions and application authorisations alongside passwords. Microsoft’s disruption reduces the service’s immediate capacity, but affected organisations remain responsible for checking their own environments and closing any access already established.
Originally reported by Hackread.
