Anatomy of a ClickFix-to-RAT campaign

Draft for review. This write-up is reconstructed for the site launch — verify every hash, path, and indicator against your own case notes before publishing, and replace the bracketed placeholders with the real values from the investigation.

A user opens what looks like a routine document. A moment later they are following on-screen instructions to “fix” a display problem — pasting a command into a dialog they were told to trust. That is the entire trick behind ClickFix: the malware doesn’t exploit the machine, it exploits the person, and the person runs the first stage themselves.

This is a walk through one such case: how the lure was delivered, what the payload actually did, and — the part that matters for defenders — which artifacts let us reconstruct the whole chain after the fact.

The lure

The delivery vehicle was a trojanized build of a legitimate Electron application — a repackaged draw.io diagramming client. Electron apps are attractive to an operator for one simple reason: the malicious logic can live in bundled, minified JavaScript inside the app’s resources/app.asar archive, well away from where most users (and some tools) think to look, while the application still launches and behaves normally.

The social-engineering layer sat on top: a prompt instructing the victim to run a snippet to resolve a fake error. Copy, paste, execute. The first stage was now running with the user’s own privileges, no exploit required.

First stage

The initial command was the usual ClickFix shape — a one-liner that reaches out to fetch the next stage rather than carrying it inline. In this case it pulled down and executed a payload that established persistence and opened a channel to the operator’s infrastructure.

Key first-stage behaviours worth pulling apart in triage:

• Living-off-the-land execution to stay under the radar of signature-based controls.
• A staged fetch — the loud, detectable part (the actual RAT) never touches disk until after the quiet first stage has run.
• User-context persistence, because the operator never needed admin to get a foothold.

Command and control

The RAT beaconed to a lookalike domain — chimefusion[.]com — the kind of plausible, brandable name that survives a casual glance at proxy logs. This is where a good egress record earns its keep: the domain has no business reason to appear in a corporate environment, and its first-seen timestamp lines up cleanly with the execution of the first stage.

If you take one habit from this case, make it this: correlate first-DNS-resolution of an unknown domain against process-creation events on the host that asked for it. That single join turns “a weird domain appeared” into “this process, spawned by this parent, at this second, reached for it.”

What gave it away

No single artifact broke the case. The chain did:

1. Process ancestry — the Electron app spawning a shell interpreter is not normal. A diagramming tool has no reason to launch a command interpreter.
2. The staged fetch — a network request to an unfamiliar host, moments after that anomalous spawn.
3. Persistence — a freshly written user-context autorun pointing at the second stage. (This is exactly the class of artifact a fast persistence sweep is built to surface — more on that in a separate note.)
4. The C2 domain — young, unattributed, and present nowhere else in the environment’s history.

Read in isolation, each of these is a shrug. Read as a sequence, they are an intrusion with a clear beginning, middle, and current state.

Indicators

Replace with the verified values from your case file before publishing.

C2 domain     chimefusion[.]com
Delivery      Trojanized Electron draw.io build (app.asar)
Vector        ClickFix — user-executed first stage
First stage   [command / hash]
Second stage  [RAT family / hash]
Persistence   [autorun location]

Takeaways for defenders

• ClickFix defeats “don’t open attachments” training. The user isn’t opening a malicious file; they’re being coached to run a command. Awareness training has to name this pattern specifically.
• Watch process ancestry, not just process names. The malicious step here was a normal binary spawned by an abnormal parent.
• Egress visibility is not optional. The C2 domain was the cleanest single indicator in the whole case, and it was only useful because there was a record of the lookup to correlate.

Human review closed this one. An automated triage layer that scored the initial detection as low-confidence and moved on would have filed an active RAT infection under “noise” — which is precisely the failure mode this practice is built to avoid.