Secretus logo
newseviltokensmicrosoft-365device-code-phishing

EvilTokens Disrupted: Recover Secrets Outside the Compromised Mailbox

Microsoft disrupted EvilTokens after linking it to over 12,000 inboxes. A device-code sign-in can leave tokens active after a password reset; here is a safer recovery sequence.

·6 min read·Secretus Editorial

The dangerous part of a stolen mailbox is what people send to it next. On September 22, Microsoft said it had disrupted EvilTokens, a service that helped attackers take over Microsoft 365 inboxes through device-code phishing. Microsoft links the service to more than 12,000 compromised inboxes at more than 10,000 organizations. Those figures are Microsoft's assessment, not a published inventory of every affected organization. The practical question for a team responding today is smaller: if an inbox was accessed, where will you send the replacement credentials and recovery instructions?

What is confirmed, and what is not

Microsoft says it and its partners seized 50 websites used by EvilTokens and disabled supporting infrastructure. CyberScoop independently reported the coordinated disruption and spoke with Microsoft about the operation. The disruption is real; it is not proof that every affiliate, stolen token, or similar phishing kit has disappeared.

Microsoft's research describes an attacker starting a device-code sign-in and presenting the code to a target. The target enters it on a genuine Microsoft sign-in page. Completing authentication, including any MFA prompt, authorizes the session the attacker started. The password need never be disclosed. Microsoft observed attackers reading mail, looking for financial relationships, and in some cases creating inbox rules or registering devices to keep access.

Public reporting does not establish which messages or secrets were read in any particular organization, how much fraud followed, or whether a given user's other accounts were reached. Treat those as questions for the local investigation. Do not assume that a password change answered them: Microsoft warns that token-backed access can persist unless sessions are revoked, and that existing access tokens may remain usable briefly even after standard revocation.

The recovery trap

Imagine a help desk replying to the affected employee's usual address with a new API key, a backup code, or a link to restore access. If the attacker can still read that mailbox, the response hands over the replacement. A forwarded message, hidden inbox rule, or device registered during the intrusion can make the handoff even less visible. The same risk applies to a request that appears to come from that mailbox: a familiar name and a real thread are no longer enough to authenticate the sender.

This is why the first recovery decision is about the channel, not the new secret. Decide who can authorize the reset and how you will reach them using a phone number, in-person contact, or another trusted route recorded before the incident. An attacker controlling the inbox should not be able to choose the destination for a recovery code or approve a payment change.

A sequence for the first hour

  1. Contain the identity session. Have an Entra administrator review the sign-in and follow Microsoft's compromised-account procedure: revoke sign-in sessions and investigate whether temporary account disablement is needed while active tokens expire. Preserve the relevant logs before cleanup.
  2. Check what access survived. Review device-code sign-ins, new device registrations, suspicious inbox rules, delegated access, and Microsoft Graph activity. A password reset alone does not remove an inbox rule or tell you what mail was read.
  3. Make a small exposure inventory. Identify credentials, recovery links, financial instructions, and sensitive files in the mailbox or connected storage that the attacker could have reached. Prioritize actual access evidence and the privileges each item grants; avoid declaring every stored value stolen without evidence.
  4. Verify people through a separate route. Confirm any urgent request for a replacement key, bank-detail change, or recovery code using a previously known contact. Do not use an address or phone number supplied in the suspicious thread as your proof.
  5. Rotate exposed credentials at their issuer. Revoke the old key or code, then issue the replacement. Deliver a temporary value only to the verified recipient through a short-lived channel. If the recipient's device is itself suspect, establish a clean endpoint first.
  6. Reduce the next attempt. Microsoft recommends blocking device-code flow where the organization does not need it and narrowing exceptions with Conditional Access where it does. Teach staff that a real sign-in page can still be part of an attacker-initiated request.

Where Secretus helps

Once you have verified the recipient and contained the account, Secretus can carry a temporary replacement key or recovery value without leaving that value in the same compromised email thread or a long-lived ticket. It does not revoke Microsoft sessions, inspect mailbox rules, determine what was read, or make an untrusted device safe. The important control is the full handoff: independently verify the person, revoke the old credential, use a limited-life transfer, and confirm that the intended recipient received it. Keep the incident record without copying the replacement value into it.

Sources