From the Field: ClickFix and the Process That Wasn’t

A ClickFix alert came in this week. I killed the flagged process within minutes, started cleanup, and that’s when the real incident started. Locked files revealed components the original alert never mentioned, and Windows lied about which process held the locks.

The Alert and the Easy Part

ClickFix campaigns are everywhere right now. The user falls for a fake verification prompt, runs a PowerShell one-liner, and an EDR alert fires with a flagged PID. Our EDR caught it cleanly and gave me the remediation steps. Confirm the PID, kill the process, and work through the cleanup list. Standard stuff.

I confirmed the PID matched the alert’s process and that it was running out of the user’s profile folder, not a system path. Killed it with Stop-Process -Id <PID> -Force and watched it disappear. Felt like a win. It wasn't.

When Cleanup Stops Being Cleanup

The remediation list had scheduled tasks to delete, registry entries to remove, and a stack of files and folders to wipe. The tasks and registry came down without issue. Then I hit the files.

Cannot delete file: The action can't be completed because 
the file is open in 360 ScreenRecord.

That message stopped me cold. “360 ScreenRecord” is a Chinese screen recording app. We don’t use it. The user didn’t install it. And when I searched for it as a running process or an installed app, it didn’t exist. Windows was telling me that a process that wasn’t running was holding the file handle.

That’s the moment the incident changed shape. The original alert covered one process. Whatever was holding these file locks was something else entirely, and it was hiding its name.

Following the File, Not the Lock Owner

I stopped trusting what Windows said about the lock owner and started working backward from what I could actually see. I grabbed the executable name straight off the path of the locked file and searched for it as a running process:

Get-Process -Name "actualfilename" -ErrorAction SilentlyContinue | 
    Select-Object Id, Name, Path

Multiple PIDs returned. All running. None of them showed up under “360 ScreenRecord” in any normal enumeration. The malware was either spoofing its window metadata or using process names that Windows surfaces differently in the file-handle dialog than in process listings.

Stop-Process -Name "actualfilename" -Force

That killed all of them in one shot. The files were released, and the cleanup finished cleanly.

What I Took From It

Two things stuck with me.

First, the EDR alert is the opening move, not the conclusion. The platform did its job. It caught the initial execution and flagged the loader. But ClickFix payloads almost always include multiple components running simultaneously, and EDR only alerts on what crosses its detection threshold. Treat “killed the alerted process” as containment, and you’ll miss the rest. Locked files during cleanup aren’t a nuisance; they’re a signal.

Second, don’t trust what Windows tells you the locking process is. The Properties dialog and “file in use” messages pull from metadata that malware can manipulate. The actual file path of what you’re trying to delete is the more honest source. Work backward from that, find what’s holding it open by name, and verify with PIDs.

Containment isn’t remediation, and remediation isn’t always over when the runbook says it is. The story keeps unfolding if you keep listening to what the system is telling you.

Have you hit something similar, where Windows attributed a file lock to a process that didn’t exist? I’d be curious how you tracked it down.