EvilTokens can keep serious account-takeover activity out of your SOC’s view by relying on “ghost” code that only surfaces after the browser decrypts it. Because of this, analysis that looks only at the static URL can overlook the part of the attack that matters most — leaving teams with partial evidence, slower triage, and a longer window of exposure to a possible Microsoft 365 compromise.
Inspecting the page at the full browser level closes that gap. By watching how the page actually behaves once it executes in a dynamic environment, teams get the proof they need to confirm the threat and act on it sooner.
Key Takeaways
EvilTokens conceals critical stages of its phishing flow behind browser-side decryption, leaving a blind spot for static URL analysis.
The kit takes advantage of Microsoft’s genuine device-login process to obtain account access without ever directly capturing the victim’s password.
Evidence gathered at the browser level lets SOC teams cut down on manual review, skip needless escalations, and reach containment decisions faster.
Threat Intelligence pivots tie a single EvilTokens session to related kits, infrastructure, indicators, and the broader landscape of device-code phishing.
The decrypted code and its behavioral patterns can also feed stronger phishing signatures, threat-hunting efforts, and custom detection logic.
Who EvilTokens Targets: Regions and Industries Most Exposed
ANY.RUN Threat Intelligence data shows that recent EvilTokens activity is clustered primarily across the United States and Europe. View recent EvilTokens activity in ANY.RUN Threat Intelligence
So far, the kit has been seen going after organizations in:
Managed security services
Technology
Manufacturing
Education
Banking
Consulting and financial services
The pattern points to EvilTokens focusing on environments where a single compromised Microsoft 365 account can open the door to sensitive data, internal conversations, and linked business services.
Why EvilTokens Becomes a Blind Spot for SOC Teams
EvilTokens remains one of the phishing kits ANY.RUN observes most often in its weekly threat reports.
A recent analysis session demonstrated how the kit leans on Microsoft Device Code Phishing to take over accounts without lifting credentials outright. Rather than stealing a password, it persuades the victim to walk through Microsoft’s legitimate device-login flow and, without realizing it, grant access to their own account.
Check analysis session with recent EvilTokens attack
The reason the attack is hard to investigate comes down to how it hides its phishing content. The landing-page HTML is encrypted with AES-GCM and only becomes readable once the browser decrypts it and renders it into the DOM.
That means static URL checks and network-level detection may record the initial response while never revealing what the victim actually sees on screen. The result is an incomplete verdict, extra manual checks, avoidable escalations, and delayed containment.
This visibility gap turns into a business problem. When a SOC can’t observe what a suspicious page does after it runs in the browser, the fallout reaches well past a slower investigation. It can mean:
A longer window of exposure to a possible Microsoft 365 account takeover
Slower containment and response decisions
More alerts pushed up to senior security staff
A heavier investigation load and higher operational cost
Incomplete evidence for blocking the surrounding infrastructure
Greater odds of unauthorized access to corporate data and services
To confirm the threat quickly, teams need to see what unfolds once the page starts executing. In the walkthrough below, we use ANY.RUN’s in-browser data inspection to surface the decrypted page, follow the requests driving the device-code flow, and gather evidence for both response and future detection.
Surface phishing activity hidden inside the browser. Give your SOC the evidence to confirm threats and respond sooner. Contact ANY.RUN
Using in-browser data inspection within ANY.RUN’s Interactive Sandbox, investigators can study cases like this across several layers:
HTML DOM Changes: Records how the DOM shifts over time and lets investigators compare snapshots of the same page. It flags byte-level differences from the previous DOM state, making it simple to pinpoint the exact moment the decrypted phishing page appears.
HTTP Requests: Opens up visibility into browser-level network traffic — requests covering HTML, JavaScript, Fetch/XHR, scripts, static assets, binaries, archives, and other request types.
URL Details: Shows the final URL and domain, SSL certificate data, DNS A records, request statistics, and any detection signatures that fired.
Indicators: Pulls together indicators of compromise tied to the page, such as top-level domains, subdomains, URL endpoints, file hashes, IP addresses, and ASN details.
Triage Walkthrough Using Browser Data
The network traffic reveals that EvilTokens serves the landing page inside an HTTP response encrypted with AES-GCM. The decrypted HTML DOM can then be reviewed in the Browser Data panel:
In-browser data investigation panel inside the interactive sandbox
From here, you can step through snapshots of the DOM structure once the AES-GCM-encrypted code has been decrypted. The HTML DOM Changes fields hold the following details:
Timeshift: How much time has passed since the analysis began when the DOM snapshot was taken.
Score: The risk rating assigned to that state of the page. In the screenshot it reads 100, matching the signatures triggered by that DOM state.
Size diff: How the DOM size changed relative to the previous snapshot.
Size: The size of the current DOM snapshot.
Page: The domain linked to the snapshot.
The figure worth focusing on is the green +48-byte size diff. Selecting the fourth snapshot shows which line was removed and which was added versus the previous snapshot. Looking at the Render panel on the left, we can confirm that a user code has surfaced on the page — the attackers will use that code later to seize the victim’s Microsoft 365 account.
This indicates the landing page pulled the user code from the backend dynamically through a Fetch/XHR request, which can be inspected in the HTTP Requests tab. Lining up the Timeshift values of the HTTP request and the DOM snapshot, we can determine that the user code came from a request to the /api/device/start endpoint. Clicking the URL confirms it:
HTTP response from EvilTokens
Pivoting from a Single EvilTokens Session to the Wider Threat
What you learn from one analysis session can be used to surface related phishing infrastructure and activity. Begin with URL Details, where the code exposed in the DOM set off the Microsoft OAuth device-code phishing signature.
URL details displayed inside ANY.RUN sandbox
Searching that signature in ANY.RUN’s Threat Intelligence turns up other phishing resources built on similar code patterns:
TI Query: ruleName:”^Microsoft OAuth device-code phishing has been detected$”
Search for analysis sessions that triggered the “Microsoft OAuth device-code phishing has been detected” signature
The results make clear this behavior isn’t exclusive to EvilTokens. Other kits use comparable code and techniques, letting teams move past a single isolated case and recognize a broader cluster of related threats.
Grow one investigation into the wider threat picture. Sharpen detection and shut down related attacks before they spread. Improve threat detection
To narrow the search to EvilTokens specifically, use this query:
TI Query: threatName:”eviltokens”
Threat Intelligence data confirms that recent EvilTokens activity is concentrated mainly across the United States and Europe:
Threat activity targeting specific regions
Teams can also follow device-code phishing more broadly with the oauth-ms-phish threat tag:
TI Query: threatName:”oauth-ms-phish”
This wider search helps teams spot related campaigns even when they ride on a different phishing kit or infrastructure.
Next, head back to Browser Data and open the Indicators tab. Not every artifact gathered during analysis belongs in your detection rules. The observed IP address, for instance, sits in the CloudflareNet autonomous system — blocking or alerting on that shared infrastructure could generate false positives and disrupt legitimate services.
The session’s more specific indicators — the domain, URI, and hash — make stronger candidates for further validation and detection:
TI Query: url:”/api/device/start” or domainName:”emp01825.workers.dev$” or md5:”fcd1b654a0b3e8f85ca7cfdafe494d4b”
By pivoting across signatures, threat names, tags, and carefully chosen IOCs, teams can link an individual alert to wider phishing activity, broaden detection coverage, and get ahead of related attacks.
Breaking Down the EvilTokens Attack Logic
The HTML DOM Changes view isn’t only useful for triage — it also supports deeper code analysis. By studying the decrypted page logic, teams can spot recurring patterns that may feed low-level phishing detection rules.
Gate Check and Decoy Delivery
The first fragment shows the client issuing a gate-check request to:
/api/device/gate/<PAGE_ID>
The backend responds with a killed flag that decides what comes next. If the phishing flow is still live, the attack proceeds. If not, the victim is served a decoy page styled to look like a Microsoft error or an expired-link notice. This gives operators a way to switch off the phishing page or mask its real behavior when particular visitors or conditions show up.
Requesting and Displaying the User Code
The next fragment fires a POST request to _startUrl:
/api/device/start
The backend returns the userCode, sessionId, and verification URI. The script then saves the session, builds _verificationUrl, and writes the user code into the DOM for the victim.
Code used to request the user code
This is the very activity seen earlier in the HTTP Requests view, tying the browser-side code directly to the network request and to the user code shown on the page.
Monitoring the Device-Code Session
The frontend then tracks the device-code session’s status through:
/api/device/status/{sessionId}
It sends repeated GET requests carrying the current sessionId and receives the latest status back from the backend. Once the status flips to completed, the script stops polling, shows a success screen, and forwards the victim to the genuine OneDrive site.
Authorization status polling
That closing redirect makes the attack look successful and above-board, while the attackers hold onto the access granted through the finished Microsoft device-login flow. By joining the decrypted DOM code with browser requests and the visible page changes, teams can rebuild the full phishing logic and surface the code patterns, endpoints, and behaviors that may harden future detection.
Turning Hidden Browser Activity into Faster SOC Decisions
The EvilTokens investigation highlights the real-world payoff of browser-level evidence. Rather than stopping at the encrypted HTTP response, teams can see the decrypted DOM, identify the request that produced the user code, follow the device-code session, and pull out artifacts for detection and threat hunting. This sharpens the investigation workflow in several ways:
Faster triage and fewer needless escalations: Tier 1 analysts can verify suspicious URLs using direct browser-level evidence instead of leaning on partial indicators. That cuts uncertainty, speeds up verdicts, and keeps more benign cases from landing on senior teams.
Smoother handoff and quicker response: When escalation is warranted, Tier 2 inherits the full attack context — DOM changes, HTTP requests, triggered signatures, rendered content, and relevant indicators. That reduces duplicated effort and supports faster containment.
Stronger detection engineering: Decrypted page code, browser requests, endpoints, and behavioral patterns offer solid raw material for custom phishing signatures, hunting hypotheses, and detection rules grounded in observed attacker behavior.
More focused threat hunting: Teams can pivot from one EvilTokens session to related domains, code patterns, kits, and device-code attacks inside ANY.RUN’s Threat Intelligence, pushing the investigation past a single URL.
Clearer reporting: Structured findings convert tangled browser activity into evidence that’s easier to apply during triage, escalation, incident response, and stakeholder updates.
For SOC and MSSP teams, that adds up to less time spent manually piecing browser activity back together, smarter use of senior staff, and a quicker route from a suspicious URL to a confident response.
Turn hidden browser activity into clear response evidence. Cut investigation delays and help your SOC move faster. Accelerate response now
The post EvilTokens Phishing Breaches Finance Firms Using “Ghost” Code Across U.S. and European Businesses appeared first on Cyber Security News.
