Mitigating Cache-Busting Exploits in Phishing Attacks

Web applications, especially single‑page applications (SPAs) rely heavily on client‑side JavaScript caching for performance and ensuring updates are seamless. Most JavaScript bundlers (vite, webpack, etc.) compile, optimize, and bundle source JavaScript into static assets that are served to the browser. These build pipelines append a hash to the filename of the bundled JS file for cache‑busting purposes. The hash is a unique identifier for the bundled JS file that is generated by the build pipeline.

Photo by Lautaro Andreani on Unsplash

<!-- old -->
<script src="/static/js/app.8fa9d6.js"></script>
<!-- new -->
<script src="/static/js/app.3c91ab.js"></script>

When the browser sees app.3c91ab.js, it treats it as a fresh resource, discarding the old cached version. Standard practice.

However, recent threat intelligence reveals that phishing-as-a-service platforms have weaponized this technique. Attackers are now "cache-busting" their own malware to evade detection by security scanners.

Legacy security tools and many proxies rely heavily on static indicators to block threats, such as known file hashes, URLs, and previously observed payload signatures. E.g., a scanner may block malware.js if its hash matches a known bad value.

Modern phishing kits (like the recently reported BlackForce or GhostFrame) now include their own build pipelines. Every time a victim visits the phishing site, the server dynamically generates a new JavaScript payload and assigns it a randomized, cache-busted filename (e.g., index-d1ff4b.js). Because both the filename and the file hash change for every victim, reputation and signature-based systems never see the same artifact twice.

The scanner sees a fresh application it has never seen before. If a corporate proxy attempts to cache the malicious script for analysis, the next victim's browser simply requests a different filename, bypassing the cache entirely. The phishing site effectively looks like a legitimate, frequently updated SPA. This does not make detection impossible, but it significantly raises the bar for systems optimized around static signatures, cached artifacts, and historical reputation.

Mitigation

FIDO2 (1, 2) / WebAuthn (1, 2): Phishing kits work by proxying credentials (AiTM). FIDO2 protocols cryptographically bind the authentication to the origin (domain). Even if the phishing site is pixel-perfect and uses advanced cache-busting, the browser will refuse to send the passkey to evil-site.com.
Behavioral detection: Things like flagging sites created < 24 hours ago, looking for patterns in the code, etc.

Client-Side integrity checks (RASP): Embed integrity checks within your main application bundle that verify the execution context. If the attacker simply clones your JS bundle to their site, this logic will trigger. Of course, sophisticated attackers can strip this, but it raises the cost of attack and is more of a friction mechanism.


(function() {
  const allowedDomains = ['app.corp.com', 'cdn.corp.com'];
  if (!allowedDomains.includes(window.location.hostname)) {
    // Silent alert to SOC or disable sensitive inputs
    navigator.sendBeacon('https://security.corp.com/alert', JSON.stringify({
      violation: 'domain_mismatch',
      origin: window.location.hostname
    }));
    document.body.innerHTML = '<h1>Access Denied</h1>';
  }
})();

Subresource Integrity (SRI) on CDNs: SRI won't stop phishing sites, but can protect legitimate users from Supply Chain attacks where attackers might try to update your actual cached files.
```
<script src="https://cdn.example.com/app.8fa9d6.js"
        integrity="sha384-..."
        crossorigin="anonymous"></script>
```
Strict Content Security Policy (CSP): Implement a strict frame-ancestors directive. This prevents legitimate applications from being embedded in an <iframe> on a phishing site (specifically prevents Clickjacking attacks).
```
Content-Security-Policy: frame-ancestors 'none';
```

Well-known practices like cache-busting have created new openings for attackers, as demonstrated above. If anything, we need to stick to the basics and ensure defense-in-depth is in place. Mitigation strategies like FIDO2/WebAuthn add complexity and cost, but are increasingly required to manage this risk (until attackers find a way to bypass them).