Interlock: the ransomware that walks in the front door

The origin

Interlock first surfaced in late September 2024. Over the following two years it hit businesses, universities and critical infrastructure across North America and Europe. The FBI is blunt on one point: this isn't espionage, there's no nation behind it. The actors pick victims opportunistically, and the motive is money.

One detail caught researchers' attention: multiple open-source analyses report similarities between Interlock and Rhysida, to the point of suggesting shared code or lineage.

But what makes Interlock worth studying isn't its origin. It's how it gets in.

The vector: when the user is the exploit

1. 01
   Legitimate site

   the actors compromise a real site employees visit routinely, for work
2. 02
   Fake update

   disguised as a Chrome update or as security software
3. 03
   Fake CAPTCHA

   the page has already placed Base64 PowerShell in the clipboard
4. 04
   The user pastes

   opens the Run dialog and launches the payload with their own hands

The overwhelming majority of ransomware crews enter three ways: phishing with an attachment, purchased credentials, or a known vulnerability on an edge device. Interlock uses an atypical one — so much so that the FBI explicitly flags it as an "uncommon method among ransomware groups": drive-by download from compromised legitimate websites.

It works like this. The actors compromise a real site — one the victim's employees visit routinely, for work. On it they plant a payload disguised as an update. Early on it was fake Google Chrome or Microsoft Edge updates. Then, per Sekoia, the disguise evolved into something more insidious: fake security software updates.

FortiClient.exe
Ivanti-Secure-Access-Client.exe
GlobalProtect.exe
Cisco-Secure-Client.exe
AnyConnectVPN.exe
Webex.exe
zyzoom_antimalware.exe

Look at that list carefully. Those are the names of the tools the IT department tells employees to keep updated. The attacker isn't circumventing corporate security culture — they're using it as the delivery vehicle. A user who sees "update your VPN client" and clicks is doing, from their point of view, exactly the right thing.

ClickFix: the CAPTCHA that infects

The second initial-access variant is more elegant still, and worth understanding because it's now everywhere — the same technique has been used by Lumma Stealer and DarkGate.

It's called ClickFix, and it exploits a conditioned reflex. The user sees a fake CAPTCHA: "verify you're not a robot". But instead of the usual grid of traffic lights, the CAPTCHA gives instructions:

1. Press Windows + R
2. Press CTRL + V
3. Press Enter

What the user doesn't know is that the page has already placed a Base64-encoded PowerShell script in their clipboard. By following the instructions, they open the Run dialog and launch the payload with their own hands, on their own account, with no exploit involved.

This is the conceptual point that makes ClickFix hard to stop: there is no vulnerability to patch. No software misbehaves. The antivirus sees no exploit because there isn't one. It sees a user opening Run and executing a command — something administrators do ten times a day. ATT&CK gave this technique its own ID, T1204.004 (Malicious Copy and Paste), and its existence says a lot: the framework had to create a box for "the user pastes their own malware".

The attack chain

Once the payload runs, the sequence is methodical.

1. 01
   Persistence

   a RAT in the Startup folder, or a Run key named "Chrome Updater"
2. 02
   Reconnaissance

   six legitimate PowerShell discovery commands in seconds
3. 03
   Credentials

   cht.exe and klg.dll, then Kerberoasting towards domain admin
4. 04
   Lateral movement

   RDP, AnyDesk and PuTTY: all already allowlisted
5. 05
   Exfiltration and impact

   AzCopy to an Azure blob, then conhost.exe encrypts the VMs

Persistence

The fake Chrome executable is in fact a RAT. It runs a PowerShell script that drops a file into the Windows Startup folder: from then on, the RAT restarts at every login. Alternatively the actors modify the registry, adding a Run key named — with some cheek — "Chrome Updater".

Textbook masquerading (T1036.005): a name no administrator will look at twice.

Reconnaissance

A PowerShell script assembles a picture of the machine. Nothing exotic — all legitimate commands:

WindowsIdentity.GetCurrent()   -> who am I           (T1033)
systeminfo                     -> what machine        (T1082)
tasklist /svc                  -> what's running      (T1007)
Get-Service                    -> which services      (T1007)
Get-PSDrive                    -> which disks/shares  (T1082)
arp -a                         -> who's on the network(T1016)

None of these commands is malicious. The sequence is — six discovery commands in seconds, from the same process. That's exactly where detection belongs.

Credentials

With remote control established, they pull down a credential stealer (cht.exe) and a keylogger (klg.dll). The first harvests logins and URLs from browsers (T1555.003); the second logs keystrokes to a file called conhost.txt — again, a name that looks like Windows.

Since February 2025, Lumma Stealer and Berserk Stealer have also been observed. To reach domain admin accounts, Talos researchers hypothesise Kerberoasting (T1558.003).

Lateral movement

Valid credentials plus RDP (T1021.001). Plus AnyDesk for connectivity and PuTTY for movement. All legitimate tools, often already present and already allowlisted. This is living-off-the-land: the attacker uses your toolbox.

Exfiltration

Here's the shrewdest choice. The actors use Azure Storage Explorer and AzCopy to upload data to an Azure blob (T1567.002).

Why it works: traffic to Azure leaves almost every corporate network without tripping anything. It's Microsoft. It's already allowlisted. A DLP that blocks uploads to unknown domains doesn't blink at a transfer to *.blob.core.windows.net.

Impact

The encryption binary is called — inevitably — conhost.exe, like the legitimate Windows Console Host. It encrypts with AES + RSA. Encryptors exist for Windows, Linux and even FreeBSD: that last one is a rarity, and suggests interest in appliances and systems that often have no EDR.

One operationally important detail: Interlock encrypts virtual machines, leaving physical hosts and workstations untouched. If your EDR is deployed on workstations but not VMs, you are blind exactly where they strike.

After encryption, a DLL (tmp41.wasd) executed via rundll32.exe deletes the encryption binary (T1070.004). No artefact, no analysis.

The ransom note (!__README__!.txt) arrives via GPO — using the company's own distribution infrastructure. It contains no figure: just a unique code and a .onion address. Double extortion (T1657) is stated, and the group has already demonstrated it really does publish.

Detection

The mistake would be hunting hashes. Hashes change. Behaviours don't.

1. ClickFix leaves a precise trace. Execution via the Run dialog populates RunMRU in the registry:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU

A RunMRU entry containing powershell, -enc, or long Base64 strings is a very high-confidence signal. Normal users do not paste obfuscated PowerShell into the Run box. This single rule catches ClickFix regardless of payload.

2. PowerShell spawning anomalous children. powershell.exe launching rundll32.exe, or writing to the Startup folder, or modifying Run keys.

3. Legitimate names in the wrong places. conhost.exe lives in C:\Windows\System32. If it appears elsewhere, it isn't conhost. Same logic for cht.exe and klg.dll.

4. The discovery sequence. Six reconnaissance commands in rapid succession from the same parent process.

5. Anomalous Azure traffic. AzCopy or StorageExplorer.exe on an endpoint that has never touched Azure. Outbound volume matters more than destination.

6. EDR on VMs. Not a detection rule — a prerequisite. Interlock strikes there deliberately.

Remediation

CISA and the co-authoring agencies recommend the following. We've ordered them by effectiveness-to-effort against this specific chain:

Against initial access — where you actually win:

• DNS filtering to block access to malicious sites and applications
• Web application firewalls to intercept unknown commands or injection from suspicious domains
• User training to recognise and report social engineering. Against ClickFix the message is singular, and must be literal: no legitimate website will ever ask you to press Windows+R and paste something. Ever. Anyone who does is attacking you.

Against execution:

• Restrict command line and scripting where unnecessary (CPG 2.N). Not every user needs PowerShell.
• Robust EDR on VMs, systems and networks — VMs first, for the reasons above.

Against lateral movement:

• Network segmentation (CPG 2.F)
• MFA on all possible services, particularly webmail, VPN and access to critical systems (CPG 2.H)
• Least privilege and auditing of administrative accounts (CPG 2.E)
• Just-in-time access: admin accounts stay disabled until genuinely needed
• Filter traffic to stop unknown origins reaching internal remote services

To survive impact:

• Offline, encrypted, immutable backups (CPG 2.R) — immutable is the operative word: a backup the attacker can delete is not a backup
• A tested recovery plan (CPG 5.A) with copies in a physically separate location

On paying: the agencies do not encourage it. Paying doesn't guarantee recovery, and it funds the next attack.

What it teaches

The theme of this dossier isn't a piece of malware. It's that the most effective attack chain of 2025–2026 contains not a single exploit.

A legitimate site. A CAPTCHA. A user following instructions. PowerShell, which is preinstalled. RDP, already on. AnyDesk, which IT might genuinely use. Azure, which is allowlisted. Filenames identical to Windows'.

There is no CVE to patch anywhere in that sequence. And that inverts the defensive priority: against Interlock, a flawless patching programme protects you far less than a user who knows that no CAPTCHA ever asks you to open the Run dialog.