SmokeLoader Utilizes Optional Plugins To Perform Tasks Such as Stealing Data and DoS Attacks

SmokeLoader, first seen on criminal forums in 2011, has evolved into a highly modular malware loader designed to deliver a variety of second-stage payloads, including trojans, ransomware, and credential stealers.

After Operation Endgame disrupted numerous campaigns in mid-2024, the loader reemerged in early 2025 as two distinct variants: version 2025 alpha and version 2025.

Both variants address previous performance bugs, enhance evasion capabilities, and expand the plugin framework that enables disparate malicious activities.

Zscaler researchers noted that these updates allow SmokeLoader to operate more stealthily and efficiently on compromised hosts.

Initially, SmokeLoader’s primary function was to inject a main module into Windows Explorer for persistent execution and beaconing to command-and-control (C2) servers.

The stager, responsible for this injection, previously lacked proper checks and would continually inject new copies of the module at ten-minute intervals, resulting in severe performance degradation.

Zscaler analysts identified that version 2025 alpha introduced a mutex check in the stager, terminating the injection process if the mutex already exists.

This mutex generation algorithm, which derives a random lowercase string based on the first four bytes of the bot ID, prevents repeated injections and conserves system resources.

Beyond loader stability, SmokeLoader’s plugin framework has matured significantly. Operators can optionally deploy modules that harvest browser credentials, hijack sessions, perform distributed denial-of-service (DoS) attacks, and mine cryptocurrency.

Each plugin is delivered as a second-stage payload, triggered based on configuration flags received from the C2.

This flexibility allows threat actors to tailor payloads to specific objectives, from data exfiltration in targeted espionage to volumetric DoS in extortion campaigns.

Infection Mechanism and Persistence

SmokeLoader’s infection chain begins with a reconnaissance email or exploit kit that delivers the stager as a shellcode-packed executable.

Upon execution, the stager resolves Windows API dependencies by hash, decrypts code blocks with a hardcoded offset, and injects the main module into the explorer.exe process using 64-bit shellcode.

Once inside explorer.exe, the main module creates a scheduled task for persistence, now named “MicrosoftEdgeUpdateTaskMachine%hs,” where the placeholder is the first 16 characters of the bot ID.

This contrasts with earlier variants that used “Firefox Default Browser Agent %hs,” evidencing the author’s attempt to masquerade as legitimate update services.

After establishing persistence, the main module generates the same mutex to avoid duplicate execution and begins beaconing to C2 servers using an updated protocol that includes a four-byte CRC32 checksum.

This checksum is calculated over the payload starting at offset six, ensuring integrity and hindering simplistic network detections.

The response handling also changed: the initial four-byte command length field is now XOR-obfuscated with the RC4 key, complicating static signature matching.

Throughout this process, Zscaler analysts observed that SmokeLoader’s network communications consistently mimic legitimate browser user agents and TLS handshakes, further blending malicious traffic with normal web browsing.

By integrating both stager and main-module enhancements along with versatile plugins, SmokeLoader remains a potent threat for data theft and DoS operations under a single, adaptable framework.

Free live webinar on new malware tactics from our analysts! Learn advanced detection techniques -> Register for Free