EvilTokens<\/strong><\/a>\u00a0can keep serious account-takeover activity out of your SOC\u2019s view by relying on \u201cghost\u201d 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 \u2014 leaving teams with partial evidence, slower triage, and a longer window of exposure to a\u00a0possible Microsoft\u00a0365 compromise.\u00a0<\/p>\n Inspecting the page at the full browser level<\/a><\/strong> closes that gap.\u00a0By watching\u00a0how 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.\u00a0<\/p>\n ANY.RUN Threat Intelligence data shows that recent\u00a0EvilTokens\u00a0activity is clustered primarily across the United States and Europe. View recent\u00a0EvilTokens\u00a0activity in ANY.RUN Threat Intelligence\u00a0<\/strong><\/a><\/p>\n So far, the kit has been seen going after organizations in:\u00a0<\/p>\n The pattern points to\u00a0EvilTokens\u00a0focusing on environments where a single compromised Microsoft 365 account can open the door to sensitive data, internal conversations, and linked business services.\u00a0<\/p>\n EvilTokens\u00a0remains\u00a0one of the phishing kits ANY.RUN\u00a0observes\u00a0most often in its weekly threat reports.\u00a0<\/p>\n A recent analysis session\u00a0demonstrated\u00a0how the kit\u00a0leans on\u00a0Microsoft Device Code Phishing to take over accounts without lifting credentials outright. Rather than stealing a password, it persuades the victim to walk through Microsoft\u2019s legitimate device-login flow and, without realizing it, grant access to their own account. <\/p>\n Check analysis session with recent\u00a0EvilTokens\u00a0attack\u00a0<\/a><\/strong><\/p>\n 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\u00a0renders\u00a0it into the DOM.\u00a0<\/p>\n That means static URL checks and network-level detection may record the\u00a0initial\u00a0response while never revealing what the victim\u00a0actually sees\u00a0on screen. The result is an incomplete verdict, extra manual checks, avoidable escalations, and delayed containment.\u00a0<\/p>\n This visibility gap turns into a business problem. When a SOC\u00a0can\u2019t\u00a0observe\u00a0what a suspicious page does after it runs in the browser, the fallout reaches well past a slower investigation. It can mean:\u00a0<\/p>\n To confirm the threat quickly, teams need to see what unfolds once the page starts executing. In the walkthrough below, we use ANY.RUN\u2019s 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.\u00a0<\/p>\n Surface phishing activity hidden inside the browser. Give your SOC the evidence to confirm threats and respond sooner.<\/em> Contact ANY.RUN<\/strong>\u00a0<\/a><\/p>\n Using in-browser data inspection within ANY.RUN\u2019s Interactive Sandbox<\/a><\/strong>, investigators can study cases like this across several layers:\u00a0<\/p>\n The network traffic reveals that\u00a0EvilTokens\u00a0serves\u00a0the landing page inside an HTTP response encrypted with AES-GCM. The decrypted HTML DOM can then be reviewed in the Browser Data panel:\u00a0<\/p>\n 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:\u00a0<\/p>\n 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\u00a0previous\u00a0snapshot. Looking at the Render panel on the left, we can confirm that a user code has surfaced on the page \u2014 the attackers will use that code later to seize the victim\u2019s Microsoft 365 account.\u00a0<\/p>\n 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\u00a0Timeshift\u00a0values of the HTTP request and the DOM snapshot, we can determine that the user code came from a request to the\u00a0\/api\/device\/start\u00a0endpoint. Clicking the URL confirms it:\u00a0<\/p>\n 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.\u00a0<\/p>\n Searching that signature in ANY.RUN\u2019s Threat Intelligence<\/strong><\/a> turns up other phishing resources built on similar code patterns:\u00a0<\/p>\n TI Query:\u00a0<\/strong>ruleName:\u201d^Microsoft OAuth device-code phishing has been detected$\u201d\u00a0<\/strong><\/a><\/p>\n The results make\u00a0clear\u00a0this behavior\u00a0isn\u2019t\u00a0exclusive to\u00a0EvilTokens. Other kits use comparable code and techniques, letting teams move past a single isolated case and recognize a broader cluster of related threats.\u00a0<\/p>\n Grow one investigation into the wider threat picture. Sharpen detection and shut down related attacks before they spread.<\/em> Improve threat detection<\/strong>\u00a0<\/a><\/p>\n To narrow the search to\u00a0EvilTokens\u00a0specifically, use this query:\u00a0<\/p>\n TI Query:\u00a0threatName:\u201deviltokens\u201d<\/a>\u00a0<\/strong><\/p>\n Threat Intelligence data confirms that recent\u00a0EvilTokens\u00a0activity is concentrated\u00a0mainly across\u00a0the United States and Europe:\u00a0<\/p>\n Teams can also follow device-code phishing more broadly with the\u00a0oauth-ms-phish\u00a0threat tag:\u00a0<\/p>\n TI Query:\u00a0threatName:\u201doauth-ms-phish\u201d<\/a>\u00a0<\/strong><\/p>\n This wider search helps teams spot related campaigns even when they ride on a different phishing kit or infrastructure.\u00a0<\/p>\n Next, head back to Browser Data and open the\u00a0Indicators\u00a0tab. Not every artifact gathered during analysis belongs\u00a0in\u00a0your detection rules. The observed IP address, for instance, sits in the\u00a0CloudflareNet\u00a0autonomous system \u2014 blocking or\u00a0alerting on\u00a0that shared infrastructure could generate false positives and disrupt legitimate services.\u00a0<\/p>\n The session\u2019s more specific indicators \u2014 the domain, URI, and hash \u2014 make stronger candidates for further validation and detection:\u00a0<\/p>\n TI Query:\u00a0url:\u201d\/api\/device\/start\u201d or domainName:\u201demp01825.workers.dev$\u201d or md5:\u201dfcd1b654a0b3e8f85ca7cfdafe494d4b\u201d<\/a>\u00a0<\/strong><\/p>\n 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.\u00a0<\/p>\n The HTML DOM Changes view\u00a0isn\u2019t\u00a0only useful for triage \u2014 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.\u00a0<\/p>\n The first fragment shows the client issuing a gate-check request to:\u00a0<\/p>\n The backend responds with a\u00a0killed\u00a0flag that decides what comes next. If the phishing flow is still\u00a0live, the attack\u00a0proceeds. If not, the victim is\u00a0served\u00a0a decoy page styled to look like a Microsoft error or an expired-link notice.\u00a0This gives operators a way to switch off the phishing page or mask its real behavior when particular visitors or conditions show up.\u00a0<\/p>\n The next fragment fires a POST request to\u00a0_startUrl:\u00a0<\/p>\n The backend returns the\u00a0userCode,\u00a0sessionId, and verification URI. The script then saves the session, builds\u00a0_verificationUrl, and writes the user code into the DOM for the victim.\u00a0<\/p>\n 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.\u00a0<\/p>\n The frontend then tracks the device-code session\u2019s status through:\u00a0<\/p>\n It sends repeated GET requests carrying the current\u00a0sessionId\u00a0and receives the latest status back from the backend. Once the status flips to\u00a0completed, the script stops polling, shows a success screen, and\u00a0forwards\u00a0the victim to the genuine OneDrive site.\u00a0<\/p>\n That closing redirect makes the attack look successful and\u00a0above-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.\u00a0<\/p>\n The\u00a0EvilTokens\u00a0investigation highlights the real-world payoff of browser-level evidence. Rather than stopping at the encrypted HTTP response, teams can see the decrypted DOM,\u00a0identify\u00a0the request that produced the user code, follow the device-code session, and\u00a0pull out\u00a0artifacts for detection and threat hunting. This sharpens the investigation workflow in several ways:\u00a0<\/p>\n 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<\/a>.\u00a0<\/p>\n Turn hidden browser activity into clear response evidence. Cut investigation delays and help your SOC move faster.<\/em> Accelerate response now<\/strong>\u00a0<\/a><\/p>\n \n The post EvilTokens Phishing Breaches Finance Firms Using \u201cGhost\u201d Code Across U.S. and European Businesses<\/a> appeared first on Cyber Security News<\/a>.<\/p>\n<\/div>\n\nKey Takeaways<\/strong>\u00a0<\/h2>\n
\n
\nWho\u00a0EvilTokens\u00a0Targets: Regions and Industries Most Exposed<\/strong>\u00a0<\/h2>\n
\n
\nWhy\u00a0EvilTokens\u00a0Becomes a Blind Spot for SOC Teams<\/strong>\u00a0<\/h2>\n
\n
\n
\nTriage Walkthrough Using Browser Data<\/strong>\u00a0<\/h2>\n
![\"\"](\"https:\/\/i0.wp.com\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEjQhCWBzpo8mBqW-NEqFxAvkAJKFX7wFQKVuBUt6td3tWNJhFUBdyKC1J1lrChN5CncboHBmBv9fkyK4l5Vmw_ZoYtAJ3TU-vJgU3xVgdHnMTKQhmAbpSDh0LTSXF2xruGd1zus0Z4BzrnH0ggr-Y6j0dakC5bKrevUCWnKD820tNduMtCY_-WPYcOcpYs\/s16000\/1%2520%281%29.webp?ssl=1\")
\n
![\"\"](\"https:\/\/i0.wp.com\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEjdrBXc5noqDQ9yaN3r5T_ebLDuIHXmsWqLr9jlqJ2dIjyVuzls1uHfcWl9d86q7vcwmJi_V2a31IrZh5MEbHQ5YwdGVPgUrA9xbe6V2xxnj7Pv4oy6hQ3glT4HNSSXrGJ2JIw-Zq8GmKpIEEN8XOe3cYuTfT4iqgLBwjQUDfsYAXTXE2-9NUWPSROVBbY\/s16000\/2%2520%281%29.webp?ssl=1\")
\nPivoting from a Single\u00a0EvilTokens\u00a0Session to the Wider Threat<\/strong>\u00a0<\/h2>\n
![\"\"](\"https:\/\/i0.wp.com\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEiDc5090qcqa78L8o845-uZXpoSYTAArwGCw6QGpO2wVDUbG-86xdcJkGUq-Zx7gEhGYj5Moa3kGQc8IlyEK_jmuPdwvIamj1KuAmlAqpckL9T5ACR3dSyF9x2a7cdJL_5KFtTm0ra2Esutae5GjjUMZ933lqaxHWbq-f9fGdo4Wpu8hrG6iXT0pye-ioU\/s16000\/3%2520%283%29.webp?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEgu9FHW0aC8zlH02hNOe0wAuJs4kyQOXTWfskjQaM8mb-O_Zm8nnKrq31dl66JWTBqPz4gveBlfUkoftFv-pd-sWCwp36Wz9WsORzGa4FtdMl9cXQsT5CvO0ePH-byo57BYvteEl1GGW1MnXiGO9rBtUa9RSSQbc5S12wIJZ3OYYi2AbJRL-IGD4dSinYo\/s16000\/4%2520%281%29.webp?ssl=1\")
![\"\"](\"https:\/\/i0.wp.com\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEhvZl9aCAmkGVZ5RFPxnmgveCpZlNSrDZn3dSxw0ikFw8NaGFAtMMBp7PjdxGBi9CC5_WVNQNsgW6pvciU8FmEqG0ma854IHL5oF3nuUgI5pC1aoPr3gUCf5l1qN5dFGo1sLZUsAwS-8r9IfMHLMnZ-LNoWQlUAcVLUyGWN57rCvXsruTeb1Kc48DAZfNo\/s16000\/5%2520%281%29.webp?ssl=1\")
\nBreaking Down the\u00a0EvilTokens\u00a0Attack Logic<\/strong>\u00a0<\/h2>\n
\nGate Check and Decoy Delivery<\/strong>\u00a0<\/h3>\n
\/api\/device\/gate\/<PAGE_ID>\u00a0<\/code><\/pre>\n\nRequesting and Displaying the User Code<\/strong>\u00a0<\/h3>\n
\/api\/device\/start\u00a0<\/code><\/pre>\n![\"\"](\"https:\/\/i0.wp.com\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEgwUJXoM5dwQAe2dIXAiyXtaxzytgrM1giX8hfPghSnzEMpbOwzypkAYqPPoY564BDMJ_LoOTXzlwsTvCKo2cKzLv4r25oAwPdFmf43VRGeu6A3KhbyT3VJEDIlZOzuPNdokmj31h6UazcGH-ZQNmHc3tHDocpeTC4twPM2F5v4ORHTMkj_MT3P_0qpk7Y\/s16000\/6%2520%281%29.webp?ssl=1\")
\nMonitoring the Device-Code Session<\/strong>\u00a0<\/h3>\n
\/api\/device\/status\/{sessionId}\u00a0<\/code><\/pre>\n![\"\"](\"https:\/\/i0.wp.com\/blogger.googleusercontent.com\/img\/b\/R29vZ2xl\/AVvXsEjROTrd9vuvjGRNH8J1XOFNAzgeFhkyWU6T-NlSEj-sff5uuYO8I2YE_GmMyy3T9z8vSI6ltwmKIwQxYDqkaX_jEJ3NyDWPAZQbYic5jm-T2NhIXmr5sw7Bk2MNAJnTI3bNCdqmRaggfHP1bRutzAIbFnF3gQGIhKt7s8DyK0R4HlVB-byTtazhs08upzk\/s16000\/7%2520%281%29.webp?ssl=1\")
\nTurning Hidden Browser Activity into Faster SOC Decisions<\/strong>\u00a0<\/h2>\n
\n