LeakNet's New ClickFix Tactic: Thoughts on Defense?
Saw the latest on LeakNet ransomware shifting away from standard credential theft and moving to ClickFix attacks via compromised sites. For those who missed it, they're essentially tricking users into running fake "fix" commands for browser errors.
What's interesting is their use of a Deno-based in-memory loader to bypass traditional detections. Since Deno isn't as common as Node.js in enterprise environments, we might need to tune our EDR rules to flag suspicious Deno processes spawning from PowerShell or CMD.
I'm thinking about detection logic. Since this relies on users pasting commands, we should be watching for specific PowerShell patterns. Here's a rough KQL query to start hunting for suspicious Deno invocations:
DeviceProcessEvents
| where FileName has "deno.exe"
| where ProcessCommandLine contains "eval" or ProcessCommandLine contains "run"
| where InitiatingProcessFileName in~("powershell.exe", "cmd.exe", "mshta.exe")
Has anyone seen this in the wild yet? How are you handling user education against social engineering tactics like ClickFix?
Solid query. To add to that, we're blocking unsigned Deno executables via AppLocker. It's a bit aggressive, but for our environment, the risk of a Deno-based loader outweighs the utility of a niche JS runtime on user endpoints.
We also updated our phishing training to include specific examples of "Copy/Paste to Fix" errors. User awareness is the only real patch for ClickFix.
I've started monitoring for specific parent-child process relationships. ClickFix usually involves the browser spawning a shell (like cmd or PowerShell), which then spawns the payload.
If you're using Sigma, this rule helps catch the initial shell execution:
detection:
selection:
ParentImage|endswith:
- '\chrome.exe'
- '\msedge.exe'
- '\firefox.exe'
Image|endswith:
- '\powershell.exe'
- '\cmd.exe'
- '\pwsh.exe'
condition: selection
It generates some noise with legitimate IT support tools, but better safe than sorry with LeakNet active.
The shift to Deno is clever. It's often whitelisted because it's seen as a dev tool. We found that simply restricting execution to Program Files and adding specific folder exceptions for developers helped reduce the attack surface significantly without breaking workflows.
Also, make sure to check DNS logs. If a workstation suddenly resolves a rarely seen TLD right after a Deno process starts, that's a huge red flag.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access