Microsoft 365 Business Email Compromise: What EvilTokens Teaches Us

A Microsoft sign-in page can be genuine and still be part of an attack.

That is the practical lesson from EvilTokens, a phishing-as-a-service toolkit linked to a large Microsoft 365 device code phishing campaign. Instead of sending every victim to an obvious copy of a login page, the attackers abused a legitimate authentication process. The employee could see a real Microsoft page, enter a real code, complete multifactor authentication, and unknowingly authorize the attacker’s session.

This was not a breach of Microsoft’s sign-in system. It was an abuse of a trusted process and the assumptions people make when a familiar brand and valid web address appear on screen.

What Happened in the EvilTokens Campaign?

Huntress reported that a device code phishing and token replay campaign affected 344 organizations across the United States, Canada, Australia, New Zealand, and Germany between March 2 and March 19, 2026. The affected organizations included businesses of different sizes and industries. Construction and trades companies appeared repeatedly among the observed targets.

Microsoft’s subsequent analysis connected the activity with EvilTokens and described automated infrastructure, dynamic device-code generation, and role-specific phishing messages. Lures were tailored around familiar business activity, including requests for proposals, invoices, document sharing, and manufacturing workflows.

The attackers did not need every recipient to believe a wildly unusual story. They used ordinary business tasks and recognizable services to make the requested action feel routine.

How Does Device Code Phishing Work?

Device code authentication was designed for devices that are difficult to sign into directly, such as a smart television, printer, or terminal. The device displays a short code, and the user completes authentication on another device.

1. The attacker starts a Microsoft device code authentication request and receives a code.
2. A phishing message or document request directs the employee to enter that code. The page used for authentication may be Microsoft’s legitimate device login page.
3. The employee signs in and completes any required MFA prompt, believing the action will open a document or complete a normal business task.
4. Microsoft issues tokens to the session associated with the code. Because the attacker initiated that session, the attacker receives the authorized access.
5. The attacker can use the access to review email, files, contacts, or other available information. The mailbox may then support invoice fraud, executive impersonation, data theft, or additional phishing.

The important distinction is that the attacker may not steal the employee’s password directly or defeat MFA cryptography. The victim completes a legitimate authentication process for the wrong session.

Why Is a Real Microsoft Page Not Enough?

Employees are often told to check the web address and look for a familiar sign-in page. Those habits still help with many phishing attempts, but they cannot answer the whole question here. The page may be genuine while the request that sent the employee there is fraudulent.

The employee should also ask:

• Did I initiate this sign-in or device setup?
• Why am I being asked to enter a device code to open a document, review a proposal, or hear a voicemail?
• Does this request match the normal process for the application or device I am using?
• Can I verify the request through a known contact or established support channel?

This attack also reinforces a broader point from our article Microsoft 365 Phishing: How Attackers Get Past Ordinary MFA: enabling MFA is essential, but the authentication method, access policies, monitoring, and response procedures determine how much protection it provides.

Why May a Password Reset Not End the Incident?

A password reset is an important containment step when credentials may be compromised. It should not be treated as the entire response to suspected token or session theft.

Microsoft’s emergency access guidance instructs administrators to block new sign-ins and revoke the affected user’s sessions and refresh tokens. Existing access may end at different times depending on the token, application, and whether the application supports faster revocation.

A complete investigation may also need to review:

• Recent sign-ins, locations, devices, and authentication methods
• Inbox rules, forwarding settings, deleted messages, and delegated mailbox access
• OAuth applications and permissions granted to third-party services
• Changes to MFA methods, recovery information, or registered devices
• Messages sent from the account and recent payment or vendor-change requests

What Should Businesses Change Now?

Review Whether Device Code Flow Is Needed

Microsoft recommends that organizations get as close as possible to a broad block on device code flow. Its Conditional Access guidance advises auditing current use, documenting legitimate exceptions, testing a policy in report-only mode, and then blocking the flow where it is unnecessary.

Do not enable or block the setting blindly. First identify devices, applications, service accounts, or legacy tools that legitimately depend on the flow. Any exception should have an owner and a review date.

Train Employees on the Request, Not Only the Page

Training should tell employees that entering a code on a genuine Microsoft page can authorize someone else’s session. An unexpected instruction to visit a device login page or enter a code should be verified before continuing, especially when it arrives through an RFP, invoice, voicemail, shared document, or urgent request.

Protect High-Impact Accounts

Prioritize owners, administrators, finance staff, executives, and employees who can change payment information or access sensitive records. Review phishing-resistant authentication, Conditional Access, device compliance, and administrative account separation based on licensing and operational needs.

Use PCC’s Microsoft 365 Security Checklist to organize the broader review of identities, administrator accounts, email, file sharing, devices, backup, monitoring, and employee training.

Monitor Identity and Mailbox Activity

The useful signals may appear in authentication and mailbox behavior rather than in a malicious file. Monitoring should look for unusual device code sign-ins, unfamiliar locations or applications, new inbox rules, unexpected forwarding, consent grants, and changes to authentication methods.

Verify Payment Changes Outside Email

If an attacker reaches a mailbox, normal conversations can reveal vendor relationships, payment timing, approval habits, and the language employees use. Require independent verification of new or changed payment instructions through a known phone number or another established channel. Do not use contact information supplied in the change request.

Construction firms can see a detailed payment example in Business Email Compromise in Construction: How the Scam Actually Works.

Prepare the Response Before an Incident

Write down who can disable an account, revoke sessions, review mailbox activity, contact the bank, preserve evidence, notify leadership, and engage cyber insurance or law enforcement when appropriate. The plan should cover incidents outside normal business hours.

What Should You Do After a Suspicious Device Code Sign-In?

Employees should stop and contact their IT support team immediately through a known phone number or established support channel. They should report whether they entered a code, provided a password, completed MFA, opened a file, or approved permissions.

The response team should evaluate the scope before declaring the account safe. Depending on the evidence and environment, the response may include:

• Blocking the affected account from signing in
• Revoking sessions and refresh tokens
• Resetting the password and reviewing registered authentication methods
• Reviewing sign-ins, mailbox rules, forwarding, sent items, deleted items, and application permissions
• Checking for payment changes, payroll changes, or messages sent to other employees and outside contacts
• Documenting findings and monitoring for follow-on activity

Do not continue investigating from the potentially compromised mailbox or reply inside a suspicious email thread.

Questions to Ask Your IT Provider

1. Is device code flow currently used in our Microsoft 365 environment?
2. Can it be blocked, or which documented users and applications require an exception?
3. Which accounts require phishing-resistant authentication today?
4. Who monitors Microsoft 365 identity and mailbox activity, including outside normal business hours?
5. Does our incident process explicitly include session and token revocation?
6. How do we independently verify payment, payroll, and vendor account changes?

Frequently Asked Questions

Can a Real Microsoft Login Page Be Used in Phishing?

Yes. Device code phishing can send an employee through Microsoft’s legitimate authentication process while the attacker controls the session being authorized. A genuine page does not prove that the request leading to it is legitimate.

Does MFA Stop Device Code Phishing?

Not necessarily. If the employee completes MFA while authorizing the attacker-initiated session, the attacker can receive a valid token. MFA remains necessary, but it must be paired with appropriate authentication methods, access policies, monitoring, and user guidance.

Is Changing the Password Enough After Suspected Token Theft?

No. The response should also consider blocking sign-in, revoking sessions and refresh tokens, reviewing authentication methods, and investigating mailbox and application changes. The exact steps depend on the evidence and the environment.

Should Every Business Block Device Code Flow?

Businesses that do not need the flow should generally block it. Organizations with a legitimate dependency should audit its use, restrict exceptions, and document why each exception exists. Test changes before enforcement to avoid unintended lockouts.

Are Small Businesses Realistic Targets?

Yes. The Huntress investigation included organizations of different sizes and industries, with construction and trades firms among the observed victims. Attackers can use ordinary invoices, document requests, and project communications as credible lures.