How Hackers Bypass Your Email Security Without Sending a Single Malicious File

During routine email security monitoring, I intercepted a phishing email carrying a malicious HTML attachment. What made this sample interesting was not its novelty. HTML smuggling is a well-documented technique but the specific combination of layered obfuscation, Blob-based payload delivery, and LNK proxy execution that points to a deliberate, operationally mature threat actor.

This post documents the static analysis methodology I used to decompose the sample, the evasion logic embedded in the payload, and the detection engineering implications for defenders operating at the email gateway and endpoint layers.

Why this technique is resurging

HTML smuggling is not new. It was popularised by threat actors including Qakbot and Nobelium/APT29 as a mechanism to bypass secure email gateways (SEGs) that inspect attachments but cannot fully render and execute HTML at scan time. The core premise: instead of attaching a malicious file directly, the attacker encodes the payload inside the HTML document itself. The malicious binary never traverses the wire as a standalone file, it is assembled in the browser’s memory and delivered silently.

What this sample demonstrates is that the technique continues to evolve. The specific obfuscation chain I observed; hex-encoded document.write, nested atob() decoding, Blob URL construction, and LNK-based proxy execution via rundll32.exe which represents a deliberate attempt to defeat both static signature detection and behavioural heuristics at multiple stages of the kill chain.

This matters because many organisations still rely on SEGs configured to block known malicious file extensions at the gateway. An HTML attachment containing no directly malicious bytes will often pass through unchallenged.

The sample: initial triage

The phishing email contained a single HTML attachment. Opening the source revealed a <script> block invoking document.write() with a atob()-encoded argument containing hex-escaped characters:

<script>
  document.write(atob("P\x47h0bW\x77+Cjx\x69b2R5..."))
</script>

Two layers of obfuscation are immediately visible:

1. Hex escape sequences (\x47, \x68, etc.) within the Base64 string designed to break pattern matching on the raw Base64 payload without affecting runtime execution
2. atob() decoding: the outer Base64 layer, which the browser executes transparently

This dual-layer approach is significant: it defeats regex-based detection rules looking for known Base64 payloads, while remaining fully functional in any modern browser.

Static analysis methodology

Rather than executing the payload in a browser, I performed full static analysis using Python, an approach that is safer, repeatable, and more amenable to automation and detection rule development.

Step 1: Normalising the hex escapes

The first task was to resolve the hex-encoded characters in the obfuscated string to recover the raw Base64. Python handles this natively:

obfuscated = r"P\x47h0bW\x77+Cjx\x69b2R5..."
normalised = obfuscated.encode('utf-8').decode('unicode_escape')

This reveals a clean Base64 string, now ready for decoding.

Step 2: Decoding the Base64 layer

python

import base64
decoded = base64.b64decode(normalised).decode('utf-8')

The decoded output is a second-stage HTML document containing a structured JavaScript payload.

Step 3: Analysing the Blob delivery mechanism

The decoded JavaScript reveals the delivery logic. Rather than injecting a file path or network request, the payload constructs the malicious binary entirely in memory using the Web Blob API:

function b64toBlob(b64Data, contentType) {
    // converts Base64-encoded payload to a Uint8Array
    // wraps in a Blob object with specified MIME type
}

var blob = b64toBlob(encodedZip, 'application/zip');
var url  = URL.createObjectURL(blob);var a = document.createElement('a');
a.href = url;
a.download = 'legit_invoice.zip';
a.style = 'display:none';
document.body.appendChild(a);
a.click();
document.body.removeChild(a);
URL.revokeObjectURL(url);

 

This Blob URL technique is particularly evasive for several reasons:

• The payload ZIP is never written to disk until the user’s browser saves the download — it exists only in memory as a Blob
• The download is triggered programmatically with no visible UI prompt in many browser configurations
• URL.revokeObjectURL() is called immediately after, destroying the in-memory reference and leaving no artefact for forensic recovery from the browser process
• The filename legit_invoice.zip is a social engineering anchor, exploiting the invoice-related context established by the phishing email

The final stage: lnk proxy execution

Extracting and decompressing legit_invoice.zip reveals a single file: safe.lnk.

The .lnk extension (Windows Shell Link) is a critical signal. Examining the file contents with cat reveals an execution chain targeting rundll32.exe:

rundll32.exe shell32.dll,<export> [arguments]

This is a textbook living-off-the-land binary (LOLBin) abuse pattern. The attacker is not dropping a custom executable — they are leveraging a signed Windows system binary (rundll32.exe) to proxy execution of malicious code. This serves two defensive evasion objectives simultaneously:

1. Allowlist bypass: Many endpoint security products and application control policies explicitly trust rundll32.exe because blocking it causes significant breakage in legitimate Windows environments
2. Attribution obfuscation: Process trees showing rundll32.exe as the parent are common and may not trigger anomaly-based detection rules tuned on unusual parent-child process relationships

This specific pattern — HTML smuggling → Blob delivery → ZIP → LNK → rundll32.exe — has been documented in campaigns attributed to APT41 (DEADEYE malware launcher) and various financially-motivated threat actors operating Qakbot-derived infrastructure. The presence of this execution chain in a phishing email targeting [finance/legal/claims processing] recipients is consistent with a targeted campaign rather than opportunistic spam.

Detection engineering: from analysis to actionable defence

Understanding the technique is only useful if it generates detections. Here is what this analysis produces directly:

YARA rule — HTML smuggling with hex-obfuscated Base64

rule HTML_Smuggling_HexObfuscated_Base64 
{
    meta:
        description = "Detects HTML files using hex-escaped Base64 in document.write for payload smuggling"
        author      = "Tolulope Adewuyi"
        date        = "2024-02-13"
        reference   = "Original field analysis"
        tlp         = "WHITE"

 strings:
        $dw_atob    = "document.write(atob(" nocase
        $hex_escape = /\\x[0-9a-fA-F]{2}/ 
        $b64_chars  = /[A-Za-z0-9+\/]{50,}={0,2}/
        $blob_api   = "createObjectURL" nocase
        $revoke     = "revokeObjectURL" nocase

    condition:
        $dw_atob and $hex_escape and $b64_chars and
        ($blob_api or $revoke)
}

This rule is designed to fire at the email gateway or sandbox layer — before the HTML is rendered — by matching on structural indicators that are consistent across obfuscation variants, not just this specific sample.

Sigma rule — LNK execution via rundll32 from user download path

title: LNK File Execution via rundll32 from Browser Download Directory
id: a1b2c3d4-...
status: experimental
description: >
    Detects rundll32.exe execution where the parent process or working directory
    is consistent with a browser download path, indicating potential LNK-based
    HTML smuggling payload execution.
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\rundll32.exe'
        ParentImage|endswith:
            - '\explorer.exe'
            - '\chrome.exe'
            - '\msedge.exe'
            - '\firefox.exe'
        CommandLine|contains:
            - 'Downloads'
            - 'Temp'
    condition: selection
falsepositives:
    - Legitimate installer scripts launched from download directories
level: medium
tags:
    - attack.execution
    - attack.t1218.011
    - attack.defense_evasion

Hunting query (Splunk / KQL)

For organisations with EDR telemetry, the following hunting logic surfaces instances of this technique across historical logs:

process_name="rundll32.exe"
AND (parent_process IN ("chrome.exe","msedge.exe","firefox.exe","explorer.exe"))
AND (command_line CONTAINS "Downloads" OR command_line CONTAINS "Temp")
AND file_path ENDSWITH ".lnk"
| stats count by host, user, command_line, parent_process
| where count < 3

The count < 3 threshold is deliberate, repeated rundll32 executions from download paths may be legitimate software behaviour; a single or very low-frequency hit is more likely to indicate a smuggling payload executing for the first time.

Implications for defenders

Three things stand out from this analysis as actionable recommendations for security teams:

1. Reconfigure email gateways to detonate HTML attachments, not just scan them. Static inspection of HTML files will not catch Blob-based smuggling. Sandboxed detonation — rendering the HTML in a controlled environment and observing its runtime behaviour — is the only reliable detection method at the gateway layer.

2. Monitor rundll32.exe execution chains from user-writable paths. The LOLBin abuse pattern described here is detectable through process telemetry if the right rules are in place. The MITRE ATT&CK technique T1218.011 (Signed Binary Proxy Execution: Rundll32) provides a framework for building these detections.

3. Treat .lnk files in email-delivered archives as high-risk. Windows users rarely receive legitimate .lnk files as email attachments. A gateway or endpoint policy that quarantines ZIP archives containing .lnk files would have blocked this payload at the delivery stage, independently of the smuggling technique.

Closing observations

What makes this sample representative of current threat actor tradecraft is not any single technique — it is the deliberate layering of multiple evasions, each targeting a different detection layer:

• Hex obfuscation → defeats static Base64 signature matching
• Blob delivery → evades gateway file attachment inspection
• lnk → bypasses executable file restrictions
• rundll32.exe → abuses allowlisted system binary

This is not a sophisticated nation-state tool. It is a competent, operationally mature campaign using well-understood techniques in a configuration that is still effective against a significant proportion of enterprise defences. That gap between what defenders know and what they have actually deployed is where these campaigns continue to succeed.

The YARA rule and Sigma detection published here are offered freely to the community. If you encounter variants of this technique in your own environment, I’d welcome comparison notes — contact via LinkedIn or leave a response.

Tolulope Adewuyi is an Infrastructure and Security Engineer with 9 years of experience in cybersecurity, cloud, and infrastructure. Specialisms include DFIR, threat intelligence, and penetration testing.

MITRE ATT&CK references: T1027 (Obfuscated Files or Information), T1566.001 (Phishing: Spearphishing Attachment), T1218.011 (Signed Binary Proxy Execution: Rundll32), T1105 (Ingress Tool Transfer)