EvilTokens: encrypted phishing that is activated in the browser DOM and breaks the defenses

A new phishing vector is exploiting an operational weakness that many security teams assume cover: the attack remains encrypted and "ghost" until the employee's browser disfigures and renounces it. The EvilTokens campaign that is detecting activity in the United States and Europe uses exactly that technique: the malicious page comes as an encrypted load (AES-GCM) and only becomes visible after it is decipher in the browser's DOM, where it activates a legitimate flow of Microsoft Device Code to convince the victim to authorize access to your account without revealing the password.

The immediate consequence is that conventional controls - static review of URLs, blockages on mail walkways or network-level filtering - can give a false negative. The cold-inspected link shows harmless content or an encrypted blob, while the user, when opening it in his browser, sees a page that starts the authentication flow and delivers a device code that ends up being used to get tokens and access to Microsoft 365. Microsoft documents how the Device Code Flow works and why it does not require input of credentials in the original context of the attacker https: / / learn.microsoft.com / en-us / azure / active-directory / develop / v2-oauth2-device-code.

This creates a critical "blind point" in SOC operations: evidence that reaches the Tier 1 analysis tail can be incomplete, containment decisions are delayed and attackers gain window to consolidate access, move side and extract data. The sectors most affected, according to sandbox telemetry such as ANY.RUN, include consulting, financial services, manufacturing and technology, where the reported phishing exposure is more than 65% in many vertical; a compromised login in Microsoft 365 can mean corporate mail, files and compromised workflows, as well as fraud and BEC risks.

The most practical way to close that blind spot is to bring the inspection to the browser. Interactive sandboxing tools that capture the DOM, XHR / Fetch and the traffic behind the scene allow you to see the exact moment when the encrypted load is broken down, which backend requests launch the device code and which endpoints are used (for example, by tracking calls to / api / device / start and similar). ANY.RUN is an example of this interactive approach, where sessions reproduce the user experience and generate actionable evidence for the response https: / / any.run /.

For security leaders this means rebalancing controls: it is not enough to block suspicious URLs, it is necessary to complement with browser inspection and strong identity controls. Microsoft already recommends consent policies and controls on OAuth applications; review and limit which applications can obtain permissions, block consent from default third party applications and audit permissions is basic to reduce possible damage if a token is issued to a malicious actor https: / / learn.microsoft.com / en-us / azure / active-directory / manage-apps / sequre-your-app-consent.

In operational terms, there are concrete and urgent measures that should be part of the response to this type of incident: to isolate the session committed and to revoke tokens and sessions federated from Azure AD, to eliminate consensus of unrecognized applications, to analyse Sign-In and Audit records to identify when and how tokens were issued, and to implement conditional access and MFA policies that make it difficult to reuse stolen credentials or tokens. It is also essential to keep evidence of the DOM and XHR requests to obtain commitment indicators (domains, endpoints, hashes) that allow to block related infrastructure and feed detection rules.

Beyond the technical response, it is necessary to adjust processes: to give tier 1 more visibility (browser catches, automated summaries and IOCs) reduces pressure on senior analysts and accelerates containment; to automate report generation with session context avoids waste of time on manual reconstructions and reduces operational cost. Review playbooks to include specific steps against OAuth / device code authorisation flows should be a priority.

Not all encrypted attacks are identical, but the pattern is repeated: content that escapes traditional filters reappears within the browser and triggers a legitimate flow that gives access. Effective protection combines identity and consent restrictions, browser-based detection, and sandboxes that record the DOM and XHR calls to track the entire chain of attack. Understanding and capturing the phase in which HTML moves from encryption to execution is the difference between a contained incident and one that scale to fraud, data loss and expensive response.

For equipment that manage risks in Microsoft 365 environments, the immediate priority is to implement identity controls and consensus, add browser inspection to the detection chain and set playbooks that include tokens revocation and consensus audit. At the same time, it is appropriate to review the encryption used by the attackers - for example, AES-GCM is the technique that hides the payload in these campaigns - to understand why solutions based only on URL or static content fail https: / / en.wikipedia.org / wiki / Galois / Counter _ Mode.

In short, EvilTokens and similar variants do not introduce a new vulnerability in Microsoft, but an operating vector that exploits the lack of visibility in the browser and confidence in legitimate clearance flows. The defense moves the inspection to the site where the attack occurs: the DOM and the browser communications, leverage interactive sandboxes to obtain complete evidence and harden cloud consent and access policies. This combination reduces the exposure window and prevents a single access to Microsoft 365 from becoming a major incident.