Of Blobs and Base64: How attackers use JavaScript techniques to bypass corporate security
Hi everyone!
Recently, while analyzing a phishing incident at work, I came across a JavaScript script that seemed like a technical gem of Threat Intelligence. Attackers no longer just create fake web pages; they now use native browser APIs and advanced frontend logic to deceive both users and the strictest security systems.
Today I want to take apart this attack (completely anonymized and sanitized) to see how it works and what we can learn from it.
The Code Under the Lens
At first glance, the victim receives an email with a link pointing to a legitimate hosting platform; upon entering, the browser executes a script containing this main logic:
// --- Shortened payload for demonstration ---
var encoded = "CjxodG1sIGx...[FRAGMENT TRUNCATED FOR SECURITY]";
// 1. Extracts the victim's email from the URL
var emailHash = window.location.hash || '';
function launchBlob() {
// 2. Decodes the hidden HTML (in this case, a fake Google login)
var decoded = atob(encoded);
// 3. Creates a "ghost" HTML file in the browser's memory
var blob = new Blob([decoded], { type: 'text/html' });
var blobUrl = URL.createObjectURL(blob);
// 4. Redirects without generating conventional network alerts
window.location.replace(blobUrl + emailHash);
}
This is combined with frontend logic that requires the user to interact with a "Hold to verify" button for 2 seconds for the launchBlob() function to finally fire.
Why do attackers go to so much trouble instead of a simple redirect? Let's break it down into three cybersecurity concepts.
The Anatomy of the Attack: Evasion Techniques
1. The button trick (Anti-Sandbox / Anti-analysis)
The initial page forces the user to hold down a button to proceed. This is not a design or UX decision. Email security tools (like security gateways or automated sandboxes) open email links, wait a few seconds for them to load, inspect the static DOM, and if they see nothing unusual, classify the URL as safe.
By requiring a continuous and complex human action (a mousedown or touchstart event held for 2000 ms), automated systems give up and the attack goes unnoticed.
2. Basic obfuscation with base64
The phishing code (the fake form stealing credentials) travels completely hidden inside the encoded variable. It is not encrypted; it is simple obfuscation with atob(). The goal is to prevent code inspectors or static antivirus signatures from detecting keywords like password, form action=, or login inputs within the initial script.
3. Network evasion through Blob URLs (URL.createObjectURL)
This is the most elegant part from the attacker's perspective. Instead of redirecting the user to an external malicious domain to show the fake login, the script decodes the Base64, creates a Blob object of type text/html, and generates a local URL in memory: blob:https://....
The impact: Corporate firewalls and proxies monitor network traffic. If the browser does not make an external GET request to download that malicious HTML, there is no network traffic to block. The phishing is built on the fly, within the memory of the victim's own browser.
4. Hyper-personalization (Auto-Grab)
By concatenating window.location.hash, the script carries the victim's email from the original link and passes it to the Blob. When the fake login renders, the "Username" or "Email" field already appears pre-filled. This breaks the victim's distrust, drastically increasing the attack's success.
How do we protect ourselves? (Mitigation Measures)
As developers and IT professionals, these types of attacks show us that traditional perimeter security (blocking IPs or domains) is no longer enough. Here are measures to mitigate and protect ourselves:
For Security Teams and SysAdmins
Monitoring non-standard URL schemes: Implement security policies in corporate browsers (via GPO or MDM) or EDR tools that detect or block redirects to suspicious URL schemes like blob: or data: when they come from unauthorized external sites.
Browser Isolation: Remote Browser Isolation (RBI) technologies execute code from unknown sites in isolated cloud containers, destroying the Blob before it can interact with the user's actual endpoint.
FIDO2 / WebAuthn Authentication (Security keys/Passkeys): The best defense against credential phishing. Even if the attacker manages to render a perfect Google form using a Blob, a physical security key (or Windows Hello / Touch ID) validates the browser's actual domain. Since the blob URL does not match the legitimate Google domain, the browser refuses to sign the request and the attack fails.
For Developers (Frontend Best Practices)
Content Security Policy (CSP): If you manage platforms where users or third parties can upload scripts, define strict CSP headers. Setting directives like object-src 'none' and restricting allowed origins in script-src prevents malicious scripts from abusing dynamic object creation.
Sanitization in hash handling: If your legitimate application reads data from window.location.hash for workflows, make sure to rigorously sanitize inputs to prevent code injections (XSS) or other DOM manipulations.
Conclusion
The modern frontend is extremely powerful, and attackers know it. Seeing how native tools like Blobs—which we use to generate dynamic PDFs or process images on the client—are reused to build undetectable phishing labs is a reminder that security must be multilayered.
What do you think? Join the conversation on our Discord and share your perspective.