Variola: From ClickFix to a Modular Implant

Key Takeaways

• Blackpoint’s Adversary Pursuit Group (APG) traced a ClickFix intrusion to a previously unclassified modular Windows implant, which APG is tracking as Variola. 

• Variola preserves host identity, configuration, and working controller information across executions, allowing operators to maintain continuity without rebuilding context each time the implant runs. 

• The implant uses encrypted, authenticated command and control and can rotate between configured controllers while updating its local state with infrastructure that successfully responds. 

• Variola is modular by design, allowing operators to retrieve and load additional components on demand rather than relying on a single fixed payload. 

• Its capabilities extend beyond remote command execution into process and session manipulation, browser focused activity, and support for additional collection components. 

• For MSPs, the risk extends beyond the initial ClickFix event. Once Variola is running, its stateful design and component model give an operator room to adapt and expand activity on the affected system. 

• The Blackpoint APG assesses with moderate confidence that Variola is likely undergoing active development, with multiple builds and deployment methods suggesting the operators are refining the framework prior to potential broader use.  

Executive Summary

Blackpoint’s Adversary Pursuit Group (APG) investigated a ClickFix intrusion that used Windows Terminal and PowerShell to retrieve a GitHub hosted payload named sha. That payload unpacked and launched additional stages in memory, ultimately loading a previously unclassified modular Windows implant that APG is tracking as Variola. 

Once running, Variola establishes a stable host identity and stores configuration, working controller information, cached payloads, and additional components in an encrypted local store. The implant can collect system information, execute commands and scripts, download additional payloads, update itself, and move functionality into other Windows sessions and processes. Its modular design also allows operators to retrieve and load additional components as needed rather than relying on a single fixed payload. 

Variola also includes browser focused functionality and interfaces for additional collection and component delivery, showing that it was designed as a broader post compromise platform rather than a simple downloader or remote access tool. 

For MSPs, the key concern is that Variola can turn a relatively simple ClickFix infection into a much more flexible foothold. Once established, the implant can preserve context, move functionality into other processes, and add new capabilities as needed, giving an operator room to expand activity beyond the initial point of execution. Early containment is especially important because the risk is not limited to the first payload or process that was observed. 

APG identified multiple related Variola builds and alternate deployment formats in the same GitHub repository used during the intrusion. Those samples shared the same core architecture, controller trust model, storage format, internal interfaces, and component loading behavior, providing evidence of an actively developed malware family rather than a one-off payload. The name Variola comes from the smallpox marker embedded in one of the framework’s loader stages, a direct reference to the virus that causes smallpox. 

A Framework in Motion

Based on the technical capabilities of the framework and its modular architecture, the Blackpoint APG assesses with moderate confidence that Variola was likely developed to support sustained, operator directed access with an emphasis on credential theft, session compromise, and flexible post compromise operations. Its modular architecture, browser focused functionality, and support for additional collection components suggests a framework designed to adapt to different objectives rather than execute a predetermined sequence of malicious actions. However, the Blackpoint APG has limited visibility into the operator’s intended goals or which capabilities they prioritize; the uncertainty in those factors led to our moderate confidence assessment. 

The presence of multiple closely related builds and deployment methods also suggests continued development and experimentation, although the available evidence does not establish the scale of deployment or whether Variola is operated by a single threat actor or distributed among multiple operators.  

The framework’s potential to exploit authenticated browser sessions could allow attacker to access applications and services without repeating the initial credential theft or authentication process. For defenders, this means the scope of an intrusion could extend beyond the original endpoint, particularly where compromised accounts have access to sensitive business applications or administrative services.   

Technical Analysis 

ClickFix Hands Off to GitHub

The intrusion started with a ClickFix execution chain that moved from explorer.exe into Windows Terminal and PowerShell. A minimized PowerShell process rebuilt the contents of the ue4db environment variable and passed it into ScriptBlock::Create, which ultimately launched %TEMP%.ps1 (Figure 1). 

That script reached out to GitHub and pulled down a payload named sha from raw[.]githubusercontent[.]com/<redacted>/deploy/refs/heads/main/sha. Before making the request, it forced TLS 1.2 and was configured to retry the download up to three times. The response was then decoded in memory using a repeating 16 byte XOR key combined with the byte position (Figure 2). 

After decoding, the script wrote the payload into %TEMP% using an eight character GUID derived filename and launched it with Start-Process. That handoff moved execution into the first Variola loader stage.

Beneath the Rust Cover

The decoded sha executable is a Rust based loader whose main job is to recover and launch the next stage in memory. Its execution path centers on an embedded payload that is decrypted using a 32 byte XOR key, copied into newly allocated memory, and transferred into for execution. 

The stage recovered by the Rust loader begins with the MZER marker and acts as a position independent reflective loader. Rather than passing the embedded PE through the normal Windows loader, it rebuilds the image manually in memory. The loader allocates space for the image, copies each section into its expected virtual address, applies relocations, resolves imports, and prepares the mapped image for execution. 

The reflective loader contains several developer artifacts that stand out from the surrounding code. Most notably, the PE includes a dedicated smallpox section alongside the standard PE sections (Figure 3). The section name does not appear to affect the loader’s execution but provides a distinctive internal marker that reappears across related builds.

APG also identified a small helper function that references two plaintext developer strings: “I love my job & wife. My wife loves your money. Family business since 2009” and “A thousand and one samples still nothing to call your own” (Figure 4). The first string is stored within the smallpox section, while the second is stored elsewhere in the loader. Neither appears to participate in payload decoding or execution, but together they provide a glimpse into developer artifacts intentionally left within the malware. 

Once the image is reconstructed, the loader finalizes memory protections and transfers execution into the mapped x64 payload, handing control to the Variola core. The recurring smallpox marker later became the basis for APG tracking the implant as Variola. 

Identity That Survives the Process

Before normal tasking begins, Variola creates a stable identifier for the infected host. It reads HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid, hashes the ASCII value with SHAKE256, keeps the first 12 bytes, and formats the result as a 24-character uppercase hexadecimal identifier. If MachineGuid is unavailable, the implant falls back to a value derived from the computer name and system volume serial number. 

That identifier is stored in uid.dat, typically under %ProgramData%\4A-D3\uid.dat. The record is wrapped in a structured envelope that uses a unique 32 byte key, XSalsa20 encryption, and a CRC-32/MPEG-2 integrity check. This gives Variola a consistent way to recognize the same host across executions without relying on the process or filename that originally launched it. 

The same storage system is used for more than host identity. Variola keeps runtime configuration, a cached copy of the agent, the last known working controller, and dynamically delivered components in the same encrypted object store. Together, these records allow the implant to preserve its working state between executions instead of rebuilding that context each time it starts.

Store Key/Type	Purpose
1,3	Runtime configuration, including controller hosts, selection policy, and runtime flags
4,4	Cached agent PE used for updates and process placement
C8,0A	Last known working or preferred controller
0x9D0D4	Dynamically delivered component PE and metadata

A C2 Protocol Built Around Trust

Variola does not send tasking directly over HTTP. Instead, it wraps each exchange in an encrypted and authenticated protocol built around Protocol Buffers and embedded controller keys. 

For every outbound request, the implant generates a new secp256k1 keypair and performs ECDH using an embedded controller public key. The resulting shared secret is expanded with SHAKE256 to derive the XSalsa20 key and nonce used to encrypt the protobuf payload. Each request begins with the client’s 33 byte compressed ephemeral public key followed by the encrypted message. 

Responses use a separate trust mechanism. Variola expects the first 64 bytes of the response to contain an Ed25519 signature, which it verifies using a second embedded controller public key before processing the encrypted payload (Figure 5). This prevents the implant from accepting tasking from a controller that cannot produce a valid signature.

The transport layer supports both WinHTTP and WinINet, respects the system proxy configuration, and can rotate between configured controllers using failover or round robin selection. When a controller responds successfully, Variola updates its local HOST record with the working endpoint so future executions can prioritize infrastructure that has already been reachable.

Making C2 Blend

Variola does more than encrypt its controller traffic. The implant also contains large internal wordlists used to build randomized URI paths that resemble normal application and enterprise web traffic. Rather than relying on a single static endpoint, it can combine directory names, actions, compound terms, and common web extensions into paths such as /api-docs/approve/activate-feature/track-changes.php, /service-center/generate-invoice/list-reports, and /preferences/get-resource/deactivate-account/split-resources. 

The same codebase contains a pool of Microsoft themed user agents, language preferences, cookie names, and other HTTP values that can be mixed into requests. Examples include Microsoft-CryptoAPI/10.0, Microsoft-Windows-Update-Agent/10.0.19041.3636, Microsoft-OneDrive/22.2.1028.0007, and Microsoft-Defender/11.0. The HTTP client also includes the header X-Api-Key: secret-token. 

APG also identified an earlier version of Variola in a public malware sandbox that was observed communicating with URI paths tied directly to these embedded wordlists. That overlap gave APG another useful way to connect related Variola activity beyond individual hashes, filenames, or infrastructure.

Built as a Platform 

Variola’s built in command set covers the basics an operator would expect from a remote access implant, including software and system discovery, payload execution, hidden PowerShell, JScript execution, file deletion, updates, component unloading, and self-termination. What makes the framework more interesting is that the core does not need to carry every capability itself. 

Each remote task includes both a task identifier and a target component. When the task is meant for something other than the core, Variola first checks whether that component is already loaded. If not, it searches its encrypted local cache and validates the stored copy using a 256-byte fingerprint derived with SHAKE256. Missing or outdated components can be retrieved from the controller, written back to the encrypted store, and manually mapped into memory. 

Once loaded, components receive a callback into the Variola core that exposes shared services for storage, runtime operations, transfers, configuration, and controller communication. Variola also exposes a larger internal interface identified as CAv2, which provides a 31 command RPC surface for components to interact with the core. This design lets additional capabilities rely on services already implemented by Variola instead of rebuilding them inside every module. 

Task ID	Handler	Purpose
1002	GetSoftware	Installed software inventory
1003	SystemInfo	Host, session, hardware, and security profiling
1004	DownloadExecute	Decode or retrieve a PE and launch it
1005	PowerShell	Hidden encoded PowerShell execution
1006	WScript	JScript execution through cscript.exe
2006	Update	Replace the cached agent payload
5001	DeleteFile	Delete a supplied path
5002	UnloadModule	Unload a mapped component
5003	Terminate	Exit the Variola process

The wider protocol shows that Variola was designed to extend well beyond its built-in command set. APG recovered tasking and report definitions for VNC, credential and cookie collection, wallet theft, MFA theft, and several forms of user monitoring. Additional Protocol Buffer structures define keystroke capture, screenshots, video, clipboard data, mouse activity, window focus, and session events. These definitions show that the framework was built to support a much broader capability set, although not every corresponding collection component was embedded in the sha build reviewed here. 

Several of these capabilities follow patterns historically associated with mature banking trojans and fraud platforms. Variola combines browser process injection, live cookie database access, web inject support, VNC style remote access, credential collection, and modular surveillance functionality within the same framework. APG did not identify direct code lineage with a known banking trojan family, but the overall design places Variola much closer to a fraud focused post compromise platform than a conventional remote access tool. 

The protocol also contains distinctive internal identifiers including WALLET_THEFT_EXECUTE and MFA_THEFT_EXECUTE, which provide useful pivots for identifying related builds even when the surrounding loader or infrastructure changes. 

Choosing Where the Agent Lives

Variola does not inject into whatever process happens to be available. The core includes a session and process broker that enumerates Windows sessions, queries user tokens, and ranks interactive contexts before choosing where additional capability should run. Processes such as explorer.exe, sihost.exe, and RuntimeBroker.exe are preferred, while system processes including lsass.exe, services.exe, and winlogon.exe are treated as poor generic hosts. 

The framework can use its cached agent payload to provision another process and includes the native memory operations needed to allocate, write, protect, and execute code remotely. This gives Variola a way to move into the user session that best fits a requested task instead of keeping every capability tied to the process that originally launched the implant. 

Chromium receives more specialized handling. One agent mode hooks NtCreateUserProcess and watches for child processes launched with the –utility-sub-type=network argument used by Chromium’s Network Service process (Figure 6). When one is detected, Variola can suspend the process, inject another configured agent, and resume execution. 

The injected browser mode hooks NtCreateFile and NtOpenFile for the browser’s Network\Cookies database and related WAL and SHM files, changing the sharing flags so those files remain accessible while the browser is running. The core does not contain the credential collection logic itself, but it creates the access needed for another component to work with those live browser databases. 

This browser workflow is one of the more distinctive parts of Variola. Internal markers including BHkReady_ and BHnReady_ are used by the browser agent as it prepares live Chromium data for access by additional components. 

The general model has precedent in banking malware, where a core process monitors browser creation and injects specialized components for session theft or web manipulation. Variola follows the same broad strategy through its own process broker, agent modes, component interface, and browser hooks. APG did not identify a direct source code relationship with a known banking trojan family. 

The same codebase also defines protobuf structures for keystrokes, screenshots, video, clipboard data, mouse clicks, window focus, and session events. Task IDs 9100 through 9103 are reserved for a separate media component, although that collection implementation was not embedded in the sha build reviewed here. 

Beyond sha: Additional Variola-Related Repository Artifacts 

The GitHub repository that hosted sha contained several other files that helped place the ClickFix delivered sample in a much larger development and deployment environment. Many used generic or misleading names such as cfg, checksum, storage, license, kvt, keystore, and several manifest variants. 

Several of these files were closely related Variola builds or alternate wrappers around the same core. cfg and checksum used the same general loader architecture as sha, while storage, license, and kvt unpacked into successive builds of the Variola core. The latter three were compiled within hours of one another and shared nearly identical code, pointing to active development and rapid iteration while the repository was in use. 

The manifest, manifest_, and manifest12 files showed that Variola was also packaged through several different delivery paths. These included directly encoded PE files, reflective MZER images, and an NSIS installer that bundled a Python runtime to decrypt and launch the framework. Despite the different wrappers, the underlying builds retained the same controller trust model, CAv2 interface, storage conventions, and execution architecture found in sha. 

The related samples also exposed development artifacts that remained consistent across the framework. One Variola build contained the PDB path C:\dev\bot2\client\core\cmake-build-release\core.pdb, while other samples retained markers including smallpox, the CAv2 interface, the 4A-D3 storage convention, and the same controller trust model. These recurring artifacts provided additional ways to track the codebase across different builds and packaging formats.

Repository Artifact	High-level Role	What It Adds to the Research
cfg / checksum	Sibling Variola wrappers or builds	Repeated repackaging of the same framework and provides additional lineage samples.
storage / license / kvt	Successive packed Variola core builds	Shows rapid same day development and close code continuity across builds.
keystore	Related packed Variola-family build	Adds another framework-relative sample despite its misleading filename.
manifest / manifest_ / manifest12	Alternate Variola deployment formats	Shows reflective, conventional PE, and NSIS/Python staging paths for the same framework lineage.
654.exe	Aura Stealer 1.8.1 (x64-vm)	Establishes a separate credential-theft branch in the repository; no direct Variol to Aura link was identified.

One artifact stood apart from the Variola lineage. 654.exe delivered Aura Stealer 1.8.1 (x64-vm), including functionality for modern Chromium credential and session collection. Its presence shows that the repository was being used to stage more than Variola, but the available evidence does not establish a link between the two. 

The repository shows this was more than a single payload uploaded for one intrusion. It contained multiple Variola builds, several ways to package and launch the implant, and a separate stealer payload, giving APG a broader look at how the malware was being developed and staged. 

Conclusion 

What started as a short ClickFix execution chain ultimately led to a much more capable implant. Once sha handed execution into the Variola core, the operator had access to a framework that could preserve host state, maintain working controller information, move into other Windows sessions and processes, and load additional components as needed. 

That modular design is what makes Variola stand out. The core does not need to carry every capability itself. Instead, it provides the storage, communication, execution, and component loading services that additional modules can build on. The browser focused functionality follows the same model, preparing live Chromium processes and data stores for use by other components rather than handling every collection function directly. 

For an attacker, those pieces can be combined as an intrusion develops. Initial access can be used to establish the Variola core, additional components can then extend what the operator is able to do, and browser focused modules can put credentials and authenticated sessions within reach. That gives the operator a path to move from a single compromised endpoint into broader account access, additional payload execution, and further activity within the environment without needing to repeat the original ClickFix chain. 

The related builds recovered from the same GitHub repository also show that Variola was being actively developed and packaged in several different ways. Across those samples, the storage format, controller trust model, internal interfaces, and component architecture remained consistent even as the surrounding loaders and delivery methods changed. Those recurring artifacts give defenders stronger ways to track Variola than relying on a single hash, filename, or piece of infrastructure. 

How MSPs Can Defend Against Variola 

• Reduce ClickFix execution opportunities. Restrict unnecessary use of PowerShell and Windows Terminal, especially when launched from browsers or other user-driven processes. 

• Limit execution from user writable locations. Use application control to prevent unsigned or unapproved executables from running from temporary directories, user profile paths, and other common staging locations. 

• Monitor script-based downloads from public hosting. Pay particular attention to PowerShell or other scripting engines retrieving content from GitHub raw URLs and immediately writing or executing it. 

• Hunt for Variola host artifacts. Monitor for creation or access to the 4A-D3 storage directory, uid.dat, and framework specific mutexes such as Local\host-ensure-core and Local\ledger-migrate-17000. 

• Detect suspicious process injection and session movement. Variola can place its agent into other Windows processes and user sessions, so remote memory allocation, writes, protection changes, and thread creation should be reviewed when they involve unexpected process relationships. 

• Watch for unusual Chromium process interaction. Variola specifically targets Chromium Network Service processes and accesses live Network\Cookies database files. Unexpected process injection or access to these files from non-browser processes should be treated as suspicious. 

How Blackpoint Reduces Exposure 

Blackpoint focuses on the behaviors that remain useful even when attackers rotate payloads, filenames, or infrastructure. In Variola activity, that includes the ClickFix execution chain, suspicious PowerShell and GitHub hosted payload retrieval, process injection, browser interaction, and framework artifacts that persist across related builds. 

By correlating those behaviors across the intrusion, the Blackpoint SOC can identify activity that may otherwise look unrelated when viewed one event at a time. That gives analysts more context to contain the affected system quickly, hunt for related activity elsewhere in the environment, and reduce the chance that the operator can continue expanding access through additional Variola components. 

Indicators of Compromise 

Host and File Indicators 

Type	Indicator	Context
SHA-256	82357327e965c8d1bb82b277268cecc16a428da4bab472b1a60d238331fde9cf	Decoded sha Rust loader delivered during the ClickFix intrusion
SHA-256	b2b1afa2905c63921433cada66ec9bbeb473eb467bf6501fc003e313b1cf1059	Reflective Variola loader stage
SHA-256	b1b797eaecec815741d6078b698bdceb6ea1e6e75b123d9b8c1781832ffeb9f6	Embedded Variola core DLL
Directory	%ProgramData%\4A-D3\	Primary Variola encrypted state storage location
Directory	C:\Windows\Temp\4A-D3\	Fallback Variola state storage location
Path	%ProgramData%\4A-D3\uid.dat	Primary host identity record
Path	C:\Windows\Temp\4A-D3\uid.dat	Fallback host identity record

Framework Hunting Artifacts 

Type	Indicator	Context
Mutex	Local\host-ensure-core	Variola core coordination
Mutex	Local\ledger-migrate-17000	Migration and handoff coordination
String	CAv2	Internal version 2 component RPC marker
String	BHkReady_	Browser agent coordination marker
String	BHnReady_	Browser agent coordination marker
PE section	smallpox	Distinctive developer supplied section found in Variola loader builds
Build path	C:\dev\bot2\client\core\cmake-build-release\core.pdb	Developer and build artifact recovered from related Variola code
String	I love my job & wife. My wife loves your money. Family business since 2009	Developer string associated with the smallpox loader section
String	A thousand and one samples still nothing to call your own	Additional developer string referenced by the loader

Additional GitHub Repository Artifacts 

These files were recovered from the same GitHub repository used to host sha and provide repository level context. They should be distinguished from the payload directly observed in the ClickFix intrusion. 

File	SHA-256	Context
cfg	336ede8fe2d7cdee389a59c7dd891a47ae6d9514cef284f39281e30550535639	Sibling Variola wrapper carrying the same core lineage as sha
checksum	4d9c820da79ed29d7a9184ca2d0b6016dce38a2bd610faa67029751825f382cf	Sibling Variola wrapper or build variant
storage	78b54ec97c6750eeb4a3c083bd487af91ef864a488b877e9cc25800d341566fb	Packed Variola core build
license	12e7b2d8882e5376cb17d4f5d522d3ddae85e55c238a41391b5682e52483a00c	Packed Variola core build
kvt	2e77b5516d136a12d374b37371a35b6e9c8d452c84a33166dc22de12b2a8ff58	Packed Variola core build
keystore	ba6b9344b2eb24c5dd85696789ce13f9c47763e026a71f9d30d6f3922b8c83eb	Related packed Variola family sample
manifest	e25e0b0c8bfe056476b98382dd92d153be7fcba5c9a3b29df36fc7f997151a63	Reflective Variola deployment form
manifest_	4a7d01c385eb3eb2983daedbb9642f16eb6dfae0ba2e56db3ae997641dc28538	Encoded standard PE deployment build
manifest12	fa9a4ce0e4348e99097351f89b484851ef084e1873d67f79559ed9e190e8cd35	NSIS and Python Variola staging package
654.exe	7a693dad6ab41916f343524b5cb2306ff79ad413df5dffba309b6d2f635c635d	Separate Aura Stealer 1.8.1 payload hosted in the same repository

Network Indicators 

Type	Indicator	Context
URL	hxxps://raw[.]githubusercontent[.]com/<redacted>/deploy/refs/heads/main/sha	ClickFix payload source
Domain	n.alox[.]one	Bootstrap/controller hostname observed in related Variola deployment material
IP / Port	172.86.113[.]167:4333	Related infrastructure observed with a sibling sample, not directly tied to the original ClickFix execution
HTTP header	X-Api-Key: secret-token	Variola HTTP client artifact, best used as a hunting signal in combination with other indicators