LeakNet boosts ransomware with ClickFix lures, stealthy Deno loader

Ransomware group LeakNet is scaling its operation by integrating mass-market social engineering lures via ClickFix techniques with a stealthy Deno-based loader that executes entirely in memory, drastically reducing the time defenders have to respond.

Currently averaging around three victims monthly, LeakNet is investing in its own infrastructure, moving away from relying on initial access brokers (IABs) for footholds and instead running direct campaigns.

Instead of purchasing credentials from IABs, LeakNet deploys ClickFix prompts on compromised legitimate websites, tricking users into manually executing commands (often via msiexec) that trigger the loader. This loader uses Deno, a legitimate JavaScript/TypeScript runtime, to decode and run base64-encoded payloads directly in memory without dropping files to disk.

In linked incidents, researchers noted two key LeakNet innovations: first, ClickFix prompts coercing users into running msiexec; second, a bring-your-own-runtime (BYOR) approach where the legitimate Deno binary runs attacker code via data URLs, leaving minimal disk artifacts.

These two infection paths converge into a consistent post-exploitation playbook, allowing defenders to hunt predictable behaviors even when the initial entry changes.

ClickFix: A New Front Door for LeakNet

ClickFix is a social engineering technique abusing fake error messages or verification pages to trick users into copying and running attacker-supplied commands, often via Windows Run (Win+R).

LeakNet deploys these lures on compromised, otherwise legitimate sites, like a fake Cloudflare Turnstile page instructing users to execute msiexec targeting attacker infrastructure, downloading the loader.

This method, bypassing obviously malicious domains and avoiding targeted spear-phishing, means any employee casually browsing can be an entry point with no clear profile or early warning for defenders.

This shift lowers LeakNet’s per-victim acquisition cost, removes the bottleneck of waiting for IAB-sold access, and widens the victim pool beyond lists curated by other actors.

Once the initial command is executed, LeakNet often pivots to a Deno loader that runs base64-encoded JavaScript/TS directly in memory via a data URL, leaving minimal disk artifacts. Observed loaders were initiated by VBS and PowerShell scripts with decoy names like Romeo*.ps1 and Juliet*.vbs.

The Deno process collects host details (user, hostname, memory, OS version), hashes them into a unique ID, checks with attacker infrastructure to select a C2 endpoint, and enters a polling loop fetching/executing additional code.

Because Deno is a signed, widely-used runtime, the suspicious element isn’t the binary itself but its context: unusual command-line arguments, execution outside developer environments, unexpected parent processes, and persistent outbound C2 traffic.

Inside LeakNet’s Post-Exploitation Playbook

Despite evolving entry methods, LeakNet’s post-compromise actions are highly consistent, creating detection opportunities.

The group begins with DLL sideloading, placing a trojanized jli.dll alongside a legitimate Java binary under C:\ProgramData\USOShared, making the malicious DLL appear part of normal Java/Windows Update activity.

After execution, LeakNet uses a repeatable C2 URL pattern, then shifts to lateral movement with PsExec after first running “cmd.exe /c klist” to enumerate active Kerberos tickets.

For staging and exfiltration, operators use S3 bucket infrastructure blending into normal cloud traffic, masking malicious transfers.

Given LeakNet’s reliance on trusted binaries, cloud services, and compromised websites, defenders need to move beyond signatures and focus on behavioral signals. High-value detections include msiexec commands from browsers/Win-R, Deno executing base64 data URLs outside dev environments, java.exe loading jli.dll from C:\ProgramData\USOShared, anomalous PsExec from non-admin accounts, and unexpected outbound S3 connections.

Organizations can reduce risk by enforcing policies blocking newly registered domains where possible, preventing regular users from invoking Win-R or PsExec, and pairing these controls with automated response playbooks.

IOCs