Lumara in Action: How We Contained a ClickFix Compromise Within 20 Minutes

What looked like a routine verification check ended up compromising a corporate laptop. Within 20 minutes, we had isolated the device and secured the employee’s account.

On a Sunday afternoon, an employee working away from the office visited a legitimate Australian business website and completed what looked like a routine verification check. The site was real, but attackers had compromised it and used a familiar verification prompt to deliver malicious instructions.

The prompt copied a command to the employee’s clipboard and asked them to open Windows Run and paste it. When they followed those instructions, the command contacted a newly established IP address, downloaded a secondary payload and executed it on the laptop.

The deception worked, and what happened next determined how far the compromise would go.

A Legitimate Website Delivered the Attack

ClickFix attacks work by persuading someone to run a malicious command themselves. Rather than presenting an obvious warning or suspicious download, the attacker disguises the instructions as a CAPTCHA, verification check or technical fix that feels familiar enough to trust.

In this case, the credibility of a legitimate Australian business website made the prompt convincing. The employee followed a process designed to look routine, which is precisely why the technique remains effective.

As we explained in our earlier article on LummaStealer and fake CAPTCHAs, the method changes, but the entry point does not. ClickFix succeeds by weaponising trust in processes people have learned to complete without hesitation.

The Payload Reached the Attacker’s Infrastructure

Once the employee ran the command, it contacted a newly established hostile IP address and downloaded a secondary payload. That payload executed on the laptop and connected to command-and-control infrastructure, opening a channel through which the attacker could issue further instructions.

Microsoft Defender contributed significantly to detecting the malicious activity, while SentinelOne gave our analysts the endpoint telemetry needed to trace what had executed and where it had connected. The evidence showed that this was not a blocked attempt. The command had run, the payload had deployed and the laptop had called home.

At that point, the attacker had a foothold. Our priority was to close it before they progressed further.

We Contained the Compromise Within 20 Minutes

The employee was away from the client’s office, and the incident was unfolding on a Sunday afternoon. Waiting for the laptop to return was not an option, and disconnecting from home Wi-Fi would not prevent the device from reconnecting through a mobile hotspot or another available network.

Our analysts moved from investigation to containment. Using SentinelOne’s isolation capability, we cut the laptop off from network communication so it could no longer reach the attacker’s infrastructure or other systems. We also disabled the affected account, reset the employee’s password and terminated all active sessions.

Within 20 minutes of the malicious command executing, we had isolated the laptop and secured the account. We observed no further attacker commands during that window, and we contacted the client with a confirmed account of what had happened, what the evidence showed and what we had already done.

The Evidence Showed Where the Attack Stopped

Containment closed the immediate path, but our analysts still needed to determine whether the attacker had taken further action. Using the available endpoint telemetry, we reconstructed the sequence from the initial command through to the connection with the attacker’s infrastructure.

We found no evidence that the payload had accessed password stores in Chrome, Edge or Firefox, and no evidence of lateral movement within the client’s environment. We also checked our broader client base for communication with the same hostile IP address and found none.

The compromise had occurred, but we found no evidence that the attacker had issued further commands or moved beyond the initial foothold before containment. The laptop remained isolated and was returned to the client’s head office, where it was re-imaged rather than treated as safe after a basic clean-up. The employee received a replacement device and continued working while the client returned the affected laptop to a known state.

Live Detection Is the Difference

The 20-minute response was possible because detection and defence remained active on a Sunday afternoon. The hostile IP address appeared to be only a few hours old and may not yet have reached reputation lists, so reputation-based blocking could not be relied on alone.

Security awareness can help people question a CAPTCHA that asks them to open Windows Run, but when the deception succeeds, organisations need live endpoint visibility, remote isolation and analysts who can interpret the sequence while there is still time to act.

Lumara Sentry, part of our broader Lumara SecOps Cloud, combines SentinelOne endpoint detection and response with 24/7 monitoring by our Australian SOC. Our analysts investigate suspicious execution, isolate affected devices, secure compromised accounts and use the available telemetry to determine whether the activity has spread.

Could your team isolate a compromised device before the attacker made the next move? See how Lumara Sentry can help your team detect, isolate and contain endpoint threats before they spread.