Formbook's Invisible Hand: How DLL Side-Loading and JavaScript Obfuscation Are Rewriting the Evasion Playbook

Executive Summary

Formbook has long been a fixture of the commodity malware landscape — a credential-harvesting, keylogging infostealer available-as-a-service that threat actors have deployed in campaigns since at least 2016. What makes the latest research from WatchGuard's threat intelligence team noteworthy is not the presence of Formbook itself, but the sophistication of the delivery and evasion architecture wrapping it. Security engineers, incident responders, and threat hunters operating in enterprise Windows environments should treat this research as an urgent signal: a well-understood, widely-detected malware family is actively evolving its pre-execution tradecraft to outpace signature-based and behavioral detection engines simultaneously.

This campaign is particularly relevant for organizations relying on legacy endpoint detection stacks, security teams that have deprioritized JavaScript-based threat vectors following the broader shift to Office macro exploitation, and managed service providers responsible for mid-market clients who often lack the telemetry depth to catch multi-stage evasion chains. The combination of DLL Side-Loading and obfuscated JavaScript as a dual-layer evasion mechanism represents a meaningful tactical evolution — and one that deserves careful dissection. The following analysis draws directly on findings reported by WatchGuard researchers and published via Infosecurity Magazine, with CypherByte's own threat context and defender guidance layered throughout.

Technical Analysis

The attack chain identified by WatchGuard researchers begins at the initial access layer with what appears to be a standard phishing delivery — a format familiar enough that perimeter filters and even moderately-trained users may not immediately flag it. The first meaningful technical pivot occurs when the victim executes a dropper that launches obfuscated JavaScript. This JavaScript is not serving as the payload; it is functioning as an obfuscated loader, deliberately designed to frustrate static analysis tools that would otherwise identify malicious intent at the pre-execution stage. The obfuscation techniques applied are layered — string concatenation, encoding schemes, and dynamic variable reassignment are stacked to produce JavaScript that superficially resembles legitimate web application code when scanned in isolation.

The second evasion layer is where this campaign makes its most technically interesting move. Once the JavaScript stage has executed and control is handed off, the attack leverages DLL Side-Loading — a technique that exploits the way Windows processes handle Dynamic Link Library search order resolution. In a DLL side-loading attack, a legitimate, signed executable is placed alongside a malicious DLL that shares the name the legitimate binary is programmed to load. Because Windows resolves DLL paths by searching specific directories in a predictable sequence before checking system directories, the malicious DLL is loaded in place of the genuine one. Critically, because a trusted, signed binary is performing the load operation, many security products that rely on process trust hierarchies or code-signing validation will not flag the resulting malicious code execution.

The specific pairing here is deliberate in its elegance: the JavaScript obfuscation defeats file-based and static scanning at the entry stage, while DLL side-loading defeats process-level behavioral monitoring at the execution stage. These are not redundant techniques — they are specifically targeted at different detection layers. The Formbook payload itself, once successfully loaded into memory via the side-loaded DLL, behaves as expected for this malware family: capturing keystrokes, harvesting credentials from browser stores and application memory, intercepting clipboard data, and establishing command-and-control communication. The payload's capability set is well-documented, but its ability to reach execution without triggering alerts is the variable that has been materially upgraded in this campaign.

Impact Assessment

Affected systems are broadly any Windows endpoints in environments that have not hardened their DLL search order configurations, disabled or restricted Windows Script Host (WSH) execution for JavaScript files, or deployed application control policies capable of blocking unsigned or out-of-baseline DLL loads. This is not a narrow attack surface. The majority of standard enterprise Windows deployments — particularly those running Windows 10 or Windows 11 without additional hardening beyond default configurations — are technically susceptible to the DLL side-loading component of this chain.

The real-world consequences follow Formbook's well-established damage profile but are amplified by the evasion capability. In a standard detected Formbook infection, incident response timelines can begin within hours of initial execution. In a campaign where the malware successfully evades detection through layered obfuscation, dwell time extends significantly — and it is during extended dwell periods that the most severe downstream consequences accumulate. Harvested credentials can be used for lateral movement, business email compromise, or sold on access broker markets. Keylogging data captured over days or weeks can expose privileged account credentials, VPN authentication details, and internal application access tokens. For organizations in financial services, healthcare, legal, or any sector handling sensitive client data, the regulatory and reputational consequences of extended undetected infostealer activity are substantial.

CypherByte's Perspective

This research, credited to WatchGuard's threat intelligence team, illustrates a trend we at CypherByte have been tracking across multiple threat families: the commoditization of sophisticated evasion. Formbook is not an APT tool. It is a for-hire infostealer accessible to relatively low-sophistication threat actors. The fact that this level of evasion engineering is now embedded in commodity malware campaigns should recalibrate how security teams think about threat tiering. Layered evasion chains — once associated primarily with nation-state tooling — are now table stakes for mid-tier cybercriminal operations.

There is also a meaningful signal here about detection philosophy. Organizations that have built their security posture around signature-based detection supplemented by code-signing trust as a proxy for safety are operating on assumptions this campaign specifically invalidates. The use of legitimately signed binaries as side-loading vehicles is a direct attack on the mental model that "signed equals safe." Security teams need to be investing in behavioral analytics that evaluate what a process actually does at runtime — memory writes, network connections, child process spawning — rather than relying on trust derived from the identity of the initiating binary. This is not a new principle, but this campaign is a concrete, current example of why it remains critically underimplemented.

Indicators and Detection

Defenders should orient detection efforts around the behavioral signatures of each stage in the chain rather than file hashes, which will rotate with each campaign iteration. Key detection opportunities include:

JavaScript Execution Anomalies: Monitor for wscript.exe or cscript.exe spawning child processes, particularly where the JavaScript source is located outside of standard application directories. Heavily obfuscated scripts often trigger entropy-based detection rules — ensure your SIEM or EDR has entropy scoring enabled for script file analysis. Flag execution of .js files directly from email attachment staging directories or user temp folders.

DLL Side-Loading Indicators: Identify signed executables loading DLLs from non-standard or user-writable directories. Alert on known legitimate binaries loading DLLs that do not match expected hash values or file paths. Tools like Sysmon with appropriately tuned ImageLoad event rules are particularly effective here. Look for signed binaries executing from unusual directories — a trusted binary running from %APPDATA% or a temp folder is a meaningful anomaly signal.

Formbook Runtime Behaviors: Post-execution, Formbook exhibits characteristic behaviors including: process hollowing or injection into common Windows processes, periodic HTTP or HTTPS beaconing to C2 infrastructure, reading of browser credential stores, and clipboard polling. Network-layer detection should monitor for beaconing patterns with regular intervals to newly-registered or low-reputation domains.

Recommendations

1. Restrict JavaScript Execution via Windows Script Host: For environments where direct .js file execution via WSH is not a business requirement — which is the majority of enterprise environments — disable WSH or implement policy to block direct JavaScript file execution. This collapses the first stage of this specific chain entirely. Group Policy can enforce this across domain-joined endpoints within a single change window.

2. Implement DLL Safe Search Mode and CWD Protections: Ensure SafeDllSearchMode is enabled across the environment (it is enabled by default in modern Windows but can be disabled by application installers). Audit applications that load DLLs from relative rather than absolute paths, as these are prime side-loading targets. Consider deploying application control policies that alert or block DLL loads from user-writable directories by signed system binaries.

3. Deploy Sysmon with ImageLoad Event Logging: If not already in place, deploy Sysmon with Event ID 7 (ImageLoad) logging enabled and tuned rules that flag known-legitimate signed binaries loading DLLs from non-standard paths. Correlate these events with process creation and network connection events to identify full execution chains.

4. Tune EDR Behavioral Rules for Script-to-Process Chains: Work with your EDR vendor to ensure behavioral rules cover the specific pattern of obfuscated script execution leading to DLL load events. Many EDR platforms support custom detection logic — this campaign's chain is well-defined enough to translate into precise behavioral rules that will catch future variants even as file-level indicators rotate.

5. Conduct Threat Hunting on Historical Telemetry: Given that this campaign's evasion techniques may have allowed it to operate undetected in environments with existing telemetry, threat hunters should run retrospective queries for: signed binaries executing from temp or appdata directories, wscript.exe spawning non-standard child processes, and outbound connections from injected processes. A campaign that evades real-time detection may still leave recoverable forensic artifacts in historical logs.

Source credit: This analysis is based on threat research originally reported by Infosecurity Magazine, drawing on findings from WatchGuard's threat intelligence team. CypherByte's analysis, detection guidance, and recommendations represent our own independent security research perspective applied to the disclosed findings.