A journal of trust,
identity & influence.

INSIDESocial engineering
← All stories
News analysisNews analysis

EvilTokens puts the relationship inside the inbox at the center of the story

Microsoft's September 22 report describes more than polished phishing messages. Our analysis asks what changes when compromised correspondence reveals how an organization makes decisions.

Ink-and-paper collage of an open envelope connected to an abstract network of relationships.
Original editorial illustration. Not a photograph or evidence of an individual incident.

The most important information in a work inbox is not always a password or a confidential attachment. It can be the relationship between people: who normally approves a change, which supplier is expected to write back, or why a request arriving this afternoon would seem unsurprising.

That is the lens through which to read Microsoft’s September 22, 2026 report on EvilTokens. The company says it disrupted a cybercrime service that used AI to analyze compromised inboxes and identify relationships and financial responsibilities useful for fraud. Microsoft also describes account access that could survive a password change when associated sessions were not revoked.

Primary recordMicrosoft Digital Crimes Unit, September 22, 2026.
Reported developmentDisruption of a service combining compromised access with AI-assisted analysis.
Our focusThe difference between a plausible conversation and an authorized change.

The claim and its limits

This is a first-party account from an organization involved in the disruption. It is evidence of what Microsoft reports observing and doing, not an independent investigation by this publication. The report does not establish that every inbox compromise uses AI or that every fraudulent message can be attributed to this service.

Our analysis below concerns defensive workflow design. It does not reproduce the service’s interface or operational instructions, and it does not assume that a particular reader’s mailbox has been affected.

Context can make the wrong request feel ordinary

An illustrative supplier conversation shows the distinction. A real project exists. A payment is expected. The names and amounts in the correspondence are familiar. A new message asks for one changed detail. The familiarity answers “Does this belong to a conversation I recognize?” It does not answer “Has this change been independently authorized?”

That distinction remains useful whether the context was understood manually or with automated assistance. The control should attach to the consequential change, not simply to the apparent fluency of the message. A polished reply is not an approval record.

Three boundaries worth examining

Boundary Question for the organization Why it is different from spotting a fake
Payment changes Where is a new destination independently confirmed? A familiar thread can still contain an unapproved change
Account recovery Who can confirm that access was contained? Changing one secret is not a complete investigation
Reporting Can someone flag uncertainty without delaying urgent work? The employee may recognize an anomaly without identifying its cause

These are editorial review questions, not evidence that any particular control would have prevented every incident in Microsoft’s report. Implementations differ, and an organization’s response should follow its provider’s current guidance and its own incident process.

Do not turn this into another grammar lesson

Training that focuses exclusively on spelling mistakes has a narrow view of deception. A person may face a message that is grammatically excellent, contextually appropriate and still asks for something that has not been authorized. The useful question is what independent record or process supports the requested action.

The NCSC’s phishing guidance describes defense as layered rather than dependent on perfect recognition by users. An application of that idea is to make a risky change require a clear approval path even when the message looks entirely ordinary.

What to ask after a mailbox incident

The person responsible for the account needs to know which access, sessions and settings were reviewed, which contacts may need a warning and which pending decisions could have been influenced. These are questions for the provider or responsible security team; the answers depend on the service and the evidence.

Avoid announcing that everything is resolved simply because a password was changed. Equally, avoid assuming every prior message was altered. Good response work distinguishes confirmed access, possible exposure and observed changes rather than replacing uncertainty with a sweeping statement.

The editorial takeaway

The inbox is not only a container of documents. It is also a record of how work becomes credible. That makes the boundary between recognizable context and authorized action worth protecting in its own right.

Read pretexting and the trust chain for the human mechanism, MFA’s scope and limits for the identity layer, and reporting without blame for a way to make early uncertainty visible.

Found a factual error or a source that has changed?

Send a correction →