EvilTokens: The Browser‑Based Phishing Nightmare That Makes Static Analysis Obsolete + Video

By /

Listen to this Post

Featured Image

Introduction:

The cybersecurity community has been rocked by a sophisticated new phishing kit known as EvilTokens, which exploits Microsoft Device Code authentication and conceals its entire attack flow within the browser. By delivering an AES‑GCM encrypted payload that only decrypts upon client‑side JavaScript execution, EvilTokens renders traditional static URL analysis virtually useless, exposing a critical blind spot in modern security operations centres (SOCs).

Learning Objectives:

  • Understand how EvilTokens leverages browser‑side encryption and DOM manipulation to evade static detection.
  • Learn to identify, analyse, and respond to device‑code phishing attacks using dynamic browser‑level visibility.
  • Master practical commands and techniques for extracting indicators of compromise (IOCs) from encrypted phishing pages.

You Should Know:

1. Understanding the EvilTokens Attack Chain

EvilTokens represents a paradigm shift in phishing methodology. Unlike traditional phishing pages that serve malicious content directly in the server response, EvilTokens delivers an initial HTML page that contains nothing more than an AES‑GCM encrypted blob and a JavaScript decryption routine. The actual phishing content—a fully functional Microsoft‑branded authentication page with device codes and user instructions—is only rendered after the browser executes the JavaScript and decrypts the payload into the Document Object Model (DOM).

For security analysts, this creates a profound visibility gap. Static URL analysis, which typically examines page source, network requests, and reputation data, will show little to no evidence of malicious activity. The real attack remains hidden until the page is executed in a live browser environment. This technique has already been linked to compromises across multiple organisations, demonstrating that it is not merely a theoretical concern but an active threat.

Step‑by‑step guide to detecting the encrypted payload:

  1. Capture the initial HTTP response using a proxy like Burp Suite or mitmproxy: 
    Using curl to fetch the initial page and save headers
curl -i -X GET "https://suspicious-domain.com/phishing" -o initial_response.txt
  2. Inspect the response body for telltale signs of encryption—look for long base64 strings, references to crypto.subtle, or AES‑GCM initialisation vectors (IVs): 
    Extract and decode base64 content (Linux/macOS)
cat initial_response.txt | grep -oE '[A-Za-z0-9+/=]{40,}' | base64 -d > decoded_payload.bin
  3. Analyse the JavaScript responsible for decryption. Common indicators include `crypto.subtle.decrypt` and TextEncoder: 
    Extract JavaScript from the HTML
grep -oP '(?<=<script>).?(?=</script>)' initial_response.txt > payload_script.js
  4. Simulate the decryption using Node.js to replicate the browser environment (ensure you have the correct key and IV extracted from the script): 
    const crypto = require('crypto');
const encrypted = Buffer.from('<base64_encrypted_data>', 'base64');
const iv = Buffer.from('<iv_hex>', 'hex');
const key = Buffer.from('<key_hex>', 'hex');
const decipher = crypto.createDecipheriv('aes-256-gcm', key, iv);
let decrypted = decipher.update(encrypted);
decrypted = Buffer.concat([decrypted, decipher.final()]);
console.log(decrypted.toString('utf8'));

2. Analysing Device‑Code Phishing Workflows

The core of EvilTokens’ malicious functionality lies in its abuse of Microsoft’s Device Code authentication flow. This OAuth 2.0 flow is designed for input‑constrained devices (like smart TVs or command‑line tools) but is hijacked by attackers to harvest authentication tokens. After the victim enters the displayed device code on a legitimate Microsoft login page, the attacker’s server polls the `/api/device/status` endpoint to obtain the session token, effectively compromising the account without ever capturing a password.

Step‑by‑step guide to tracing device‑code abuse:

  1. Monitor network requests for device‑code endpoints. Using browser developer tools (F12), filter XHR/Fetch requests:

– Look for `POST /api/device/start` – this initiates the device code flow.
– Look for `GET /api/device/status?code=` – this checks the authentication status.
2. Extract device codes from the DOM after decryption:

// Run in browser console after the page loads
const codeElement = document.querySelector('[data-testid="device-code"]');
if (codeElement) console.log('Device Code:', codeElement.innerText);

3. Correlate with Microsoft endpoints – legitimate device‑code flows use login.microsoftonline.com/common/oauth2/devicecode. EvilTokens often proxies these requests or uses custom domains that mimic Microsoft.

4. Create detection rules for suspicious API calls:

 Linux: Monitor for outbound connections to suspicious device-code endpoints
sudo tcpdump -i any -1 'host suspicious-domain.com and port 443' -v

 Windows PowerShell: Monitor for device-code related processes
Get-1etTCPConnection -State Established | Where-Object { $_.RemoteAddress -match 'suspicious-domain' }

3. Bridging the Visibility Gap with Browser‑Level Analysis

The EvilTokens case underscores a critical truth: static analysis is no longer sufficient. To effectively triage and respond to modern phishing attacks, security teams must adopt dynamic analysis tools that provide full browser‑level visibility. This includes monitoring DOM changes, capturing browser‑generated HTTP requests, and reviewing infrastructure details like SSL certificates and DNS records in a unified workflow.

Step‑by‑step guide to setting up a dynamic analysis environment:

  1. Deploy a sandbox solution like ANY.RUN, Cuckoo, or Joe Sandbox that supports interactive browser analysis. Configure it to capture full network traffic and DOM mutations.
  2. Use Selenium or Puppeteer for automated browser analysis: 
    // Puppeteer script to capture DOM changes
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch({ headless: false });
const page = await browser.newPage();
page.on('response', response => console.log(response.url()));
await page.goto('https://suspicious-domain.com/phishing');
// Wait for potential decryption
await page.waitForTimeout(5000);
const html = await page.content();
console.log(html);
await browser.close();
})();

3. Extract IOCs from the decrypted page:

 Using grep to find domains, IPs, and hashes
grep -Eo '(http|https)://[a-zA-Z0-9./?=_-]' decrypted_page.html | sort -u > iocs_domains.txt
grep -Eo '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' decrypted_page.html | sort -u > iocs_ips.txt

4. Monitor for DOM mutations using the MutationObserver API:

// Inject this script to log all DOM changes
const observer = new MutationObserver(mutations => {
mutations.forEach(m => console.log('DOM changed:', m));
});
observer.observe(document.body, { childList: true, subtree: true, attributes: true });

4. Hardening Defences Against Browser‑Based Phishing

Preventing EvilTokens‑style attacks requires a multi‑layered approach that combines user education, endpoint detection, and network‑level controls. Organisations must assume that some phishing emails will bypass traditional filters and prepare for rapid detection and response.

Step‑by‑step guide to hardening your environment:

  1. Implement Conditional Access Policies in Azure AD to restrict device‑code authentication to trusted devices only. Use the “Authentication flows” control to block device code flow for high‑risk users.
  2. Deploy browser extensions that can detect and block suspicious JavaScript execution, such as NoScript or uBlock Origin in advanced mode.
  3. Configure web filters to block known malicious domains and patterns: 
    Linux: Add suspicious domains to /etc/hosts
echo "0.0.0.0 suspicious-domain.com" >> /etc/hosts
echo "0.0.0.0 another-malicious.net" >> /etc/hosts

    Windows: Add to hosts file (C:\Windows\System32\drivers\etc\hosts)
Add-Content -Path "C:\Windows\System32\drivers\etc\hosts" -Value "0.0.0.0 suspicious-domain.com"
  4. Enable detailed logging for OAuth and authentication events in Azure AD/Okta. Monitor for unusual device‑code requests, especially those originating from unexpected geographic locations.
  5. Conduct regular phishing simulations that include device‑code attack scenarios to train employees to recognise and report suspicious authentication prompts.

5. Leveraging Threat Intelligence for Proactive Defence

Once a phishing flow is confirmed, the next step is to pivot into threat intelligence to understand whether the activity is part of a broader campaign. EvilTokens campaigns often share code patterns, infrastructure, and behavioural signatures that can be used to hunt for related threats.

Step‑by‑step guide to threat intelligence pivoting:

  1. Extract unique code signatures from the decrypted DOM—look for specific class names, data attributes, or JavaScript function names unique to EvilTokens.
  2. Use threat intelligence platforms (e.g., VirusTotal, AlienVault OTX, or ANY.RUN TI) to search for these signatures across their databases.
  3. Correlate infrastructure – review SSL certificates, DNS records, and IP ranges to identify shared hosting or registrar patterns: 
    Linux: Retrieve SSL certificate details
openssl s_client -connect suspicious-domain.com:443 -servername suspicious-domain.com </dev/null 2>/dev/null | openssl x509 -text -1oout

    Windows: Use Resolve-DnsName for DNS enumeration
Resolve-DnsName suspicious-domain.com -Type A
Resolve-DnsName suspicious-domain.com -Type NS
  4. Build detection rules based on IOCs. For example, a Suricata rule to detect device‑code phishing attempts: 
    alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Device-Code Phishing Detected"; flow:established,to_server; content:"/api/device/start"; http_uri; sid:1000001; rev:1;)

6. Incident Response and Remediation

When an EvilTokens attack is detected, speed is of the essence. Organisations using advanced sandbox solutions report mean time to detection (MTTD) as low as 15 seconds and a reduction in mean time to response (MTTR) of up to 21 minutes per case.

Step‑by‑step incident response checklist:

  1. Immediately revoke all active sessions for the affected user(s) via Azure AD/Okta admin console.
  2. Reset the user’s credentials and enforce multi‑factor authentication (MFA) re‑registration.
  3. Review audit logs for any unauthorised mailbox rules, forwarding settings, or application consent grants.
  4. Isolate the compromised device from the network if the phishing page was accessed from a corporate endpoint.
  5. Deploy endpoint detection and response (EDR) scans to check for additional malware or persistence mechanisms.
  6. Update your email filtering rules to block the specific sender domain and any related infrastructure.
  7. Document the incident and share IOCs with your threat intelligence sharing community (e.g., ISACs).

What Undercode Say:

  • Key Takeaway 1: EvilTokens demonstrates that static analysis is fundamentally broken for modern phishing kits. Security teams must invest in dynamic analysis capabilities that provide full browser‑level visibility to detect and respond to threats that only reveal themselves after client‑side execution.
  • Key Takeaway 2: The abuse of legitimate OAuth flows like Microsoft Device Code authentication represents a growing attack vector that bypasses traditional credential‑based defences. Organisations need to implement conditional access policies and monitor for anomalous authentication patterns.

Analysis: The EvilTokens campaign is a stark reminder that the cybersecurity landscape is evolving faster than many defensive strategies. By hiding the attack flow within the browser, attackers have effectively neutralised a generation of static analysis tools, forcing SOCs to adopt more sophisticated, execution‑based investigation techniques. The reliance on AES‑GCM encryption and dynamic DOM rendering also highlights the increasing professionalisation of phishing kits, which now incorporate advanced evasion tactics previously seen only in nation‑state malware. For defenders, this means a paradigm shift: the browser is no longer just an attack vector but also a critical vantage point for detection. Organisations that fail to embrace this shift will find themselves consistently outmanoeuvred, with delayed triage times and missed IOCs leading to prolonged breaches and greater business impact. The good news is that solutions like ANY.RUN are demonstrating that with the right tools, MTTD can be reduced to seconds, empowering SOC teams to move from detection to response with unprecedented speed.

Prediction:

  • +1 The growing awareness of browser‑based phishing will drive significant investment in dynamic analysis platforms, leading to a new generation of SOC tools that integrate real‑time browser telemetry with traditional SIEM and SOAR workflows.
  • +1 As detection improves, threat actors will respond by developing even more sophisticated evasion techniques, including multi‑stage decryption, polymorphic JavaScript, and abuse of legitimate CDNs to host encrypted payloads.
  • -1 Organisations that continue to rely solely on static analysis and legacy email filters will experience a surge in successful breaches, as EvilTokens‑style attacks become the new norm rather than the exception.
  • -1 The increased complexity of phishing investigations will exacerbate the cybersecurity skills gap, as junior analysts struggle to interpret dynamic browser behaviour without proper training and tooling.
  • +1 The EvilTokens case will likely accelerate the adoption of browser‑based security solutions, such as remote browser isolation (RBI) and browser extension‑based threat detection, as organisations seek to neutralise the threat at the endpoint level.

▶️ Related Video (88% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Kaaviya Balaji – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: