EvilTokens Phishing Kit Targets Microsoft 365 Accounts With Hidden Browser Code

EvilTokens is drawing fresh attention from security teams because it hides key phishing steps until a page runs inside the victim’s browser. The technique can make static URL checks miss the most important part of the attack.

The phishing kit targets Microsoft 365 accounts by abusing Microsoft’s legitimate device code sign-in flow. According to ANY.RUN’s EvilTokens analysis, recent activity has focused mainly on organizations in the United States and Europe.

The campaign has been seen targeting managed security services, technology, manufacturing, education, banking, consulting, and financial services. These sectors matter because one compromised Microsoft 365 account can expose email, files, Teams chats, and connected business systems.

How EvilTokens hides the phishing page

EvilTokens does not rely only on a fake login form. The kit can deliver an encrypted landing page that becomes readable only after the browser decrypts it and writes the content into the Document Object Model, or DOM.

That behavior creates a blind spot for tools that inspect only the URL or the first network response. The ANY.RUN report says the phishing content is encrypted with AES-GCM and becomes visible only after client-side execution.

This means an analyst may see a suspicious link, but not the final phishing content shown to the victim. Browser-level analysis can reveal the rendered page, the device code, the backend requests, and the indicators needed for faster containment.

Why device code phishing is dangerous

Device code sign-in exists for devices that are hard to type on, such as TVs, printers, conference room systems, and shared devices. Microsoft says device code flow can become a high-risk authentication method when attackers use it for phishing.

In an EvilTokens attack, the attacker starts a real Microsoft authentication session and gets a device code. The victim is then tricked into entering that code on Microsoft’s real login page.

Because the victim completes the real sign-in process, the attacker can receive valid OAuth access and refresh tokens. A Microsoft security blog warned that this style of attack can compromise organizational accounts without directly stealing passwords.

What happens during an EvilTokens attack

Stage	What the attacker does	Why it matters
Initial lure	Sends a message that pushes the victim toward a verification page.	The message may appear to relate to a file, account check, invoice, or business request.
Hidden page load	Serves encrypted phishing content that appears after browser-side decryption.	Static URL analysis may not show the final phishing page.
Device code request	Generates a Microsoft device code for the victim to enter.	The victim uses Microsoft’s real sign-in page, which lowers suspicion.
Token collection	Polls for the session status and collects tokens after approval.	The attacker can access Microsoft 365 services without knowing the password.
Post-compromise activity	Uses mailbox and file access for reconnaissance, fraud, or data theft.	Financial workflows, invoices, and internal communications become high-value targets.

Sekoia said it uncovered EvilTokens in phishing-focused cybercrime communities in March 2026 and described it as a phishing-as-a-service platform built around Microsoft device code phishing. The Sekoia research said the kit had been circulating since mid-February 2026.

The same research found that EvilTokens gives operators tools for business email compromise, reconnaissance, mailbox access, and token weaponization. That turns one successful sign-in into a broader identity and fraud risk.

Abnormal Security also described EvilTokens as a platform that exploits Microsoft’s device code OAuth flow and then uses stolen tokens to automate business email compromise. The Abnormal analysis said the attack can proceed after the victim completes MFA on Microsoft’s real infrastructure.

Why finance and business teams face higher risk

Finance departments are attractive targets because email inboxes often contain invoices, bank details, approval chains, and payment conversations. A compromised Microsoft 365 account can also help attackers send convincing messages from a trusted identity.

Microsoft’s device-code phishing research said attackers have searched compromised mailboxes for wire transfer details, pending invoices, and executive correspondence. That makes Microsoft’s guidance especially relevant for organizations that handle payments through email.

Security teams should treat device code phishing as an identity attack, not just an email attack. The first suspicious link may matter, but the more important evidence often appears in sign-in logs, token behavior, mailbox rules, OAuth activity, and post-login actions.

What SOC teams should look for

EvilTokens can leave useful traces when investigators analyze the page in a live browser environment. The decrypted DOM can show when a device code appears, while HTTP requests can reveal backend endpoints used to start and monitor the session.

• Unexpected device code authentication events in Microsoft Entra ID logs.
• Sign-ins that follow a suspicious email or message from an unusual sender.
• New inbox rules, forwarding behavior, or mail access from unusual locations.
• OAuth token activity that does not match the user’s normal behavior.
• Browser requests to phishing-kit endpoints used to start or poll device-code sessions.

Huntress said EvilTokens activity grew sharply in early 2026, with device code phishing attacks rising 1,380% between July to December 2025 and January to April 2026. The Huntress report also said no two lures were identical across 344 victim organizations in one wave.

How organizations can reduce the risk

The strongest control is to restrict device code flow where the organization does not need it. Microsoft says Conditional Access can target authentication flows, and its Conditional Access documentation recommends allowing device code flow only where necessary.

Security teams should also educate users not to enter device codes unless they personally started the login process. A message that asks someone to copy a code into a Microsoft sign-in page should trigger extra caution, even if the destination page looks legitimate.

If a device code phishing incident is suspected, defenders should revoke sessions, review refresh token activity, inspect mailbox rules, check OAuth application activity, and temporarily disable compromised accounts when immediate containment requires it.

Why browser-level evidence matters

Traditional phishing triage often starts with URL reputation, headers, and static page content. EvilTokens shows why that approach can miss important details when a page hides its real behavior until browser execution.

Browser inspection lets analysts see the page after decryption, match DOM changes to network requests, and confirm whether a device code appeared on screen. This gives Tier 1 analysts stronger evidence and helps reduce unnecessary escalations.

The Sekoia EvilTokens report, the Huntress research, and the Abnormal Security write-up all point to the same broader shift: attackers are moving from simple credential theft toward token-based account takeover using legitimate identity flows.

For businesses in the United States, Europe, and other regions using Microsoft 365 at scale, the lesson is clear. Blocking risky authentication flows, monitoring identity events, and analyzing pages as they execute can shorten the gap between suspicious link and confirmed response.

FAQ