AllTech
On this page
Field notes from the engineering team
A recent high-severity alert at a small-town Utah police department began with something ordinary: a user ran a command.
There was no software vulnerability being exploited and no conventional malicious attachment. The attack depended on a person being persuaded to copy, paste, and run a command presented as though it were part of a routine verification or repair step. That technique is commonly called ClickFix.
In this case, the activity was detected, investigated, and closed in approximately 15 minutes. The attacker did not establish lasting persistence, deploy ransomware, remove data, or interrupt the department’s operations. That outcome is encouraging, and the details are worth walking through because they show how a modern social-engineering attack can combine ordinary Windows tools into a chain that is difficult to recognize one action at a time.
The premise: make the user run it
ClickFix attacks are built around a simple idea: rather than trying to force malware onto a computer through an exploit, convince the person at the keyboard to run the first command for the attacker.
The prompt may resemble a CAPTCHA, browser error, document warning, or “fix this problem” instruction. It asks the user to open a Windows utility, paste text, and press Enter. To the user, this can look like a harmless troubleshooting step. To an attacker, it is a way to get code running under that user’s own account.
Security tools and users are often trained to look for suspicious downloaded attachments or unfamiliar applications. A command run through the Windows Command Line Interpreter (cmd.exe) can appear less alarming on its own, especially when the Windows utilities involved are working as designed at a technical level but serving an illegitimate purpose.
What the command set in motion
The command executed on this workstation did not present its intent plainly. It used caret obfuscation, inserting ^ characters between letters. For example, a command such as curl can be written as c^u^r^l. Windows interprets it as the original command, but simple text matching may not.
That was the first signal that this was not routine activity. The obfuscated command then downloaded a file from an external domain into the user’s local AppData folder.
The downloaded file was executed through mshta, the Microsoft HTML Application host. mshta is a legitimate Windows binary, which is why it can be useful in an attack chain: it is already present on many systems and is not inherently malicious. When attackers use legitimate, trusted tools in this way, it is often described as “living off the land.” The tool is real; the purpose and surrounding behavior are not.
From there, the process attempted to make itself survive a reboot. It tried to establish persistence through both a scheduled task and an autorun registry key. It also used a file whose actual name did not match its claimed or displayed name, adding another layer of disguise.
Individually, some of these actions can occur in normal administrative work. Taken together, they describe a recognizable attack chain:
- A user executes a copied command in the Windows shell.
- The command is intentionally obscured.
- It retrieves a file from outside the organization.
- A trusted Windows binary launches that file.
- The process attempts to run again later through scheduled-task and registry-based persistence.
- The file identity is disguised.
Why the sequence mattered
The activity mapped to multiple MITRE ATT&CK techniques, including Command and Scripting Interpreter and Windows Command Shell (T1059 and T1059.003), User Execution (T1204), and Malicious Copy and Paste (T1204.004). The last of those is especially relevant to the ClickFix pattern: the user’s action is the initial foothold.
The alert also identified Obfuscated Files or Information (T1027), System Binary Proxy Execution (T1218), Scheduled Task/Job (T1053), and Registry Run Keys / Startup Folder (T1547.001). Each one corresponds to a practical stage visible in the activity: concealment, execution through a trusted Windows component, and attempts to remain present after the initial command.
Additional observed behaviors included techniques associated with disguise, indirect command execution, Windows Management Instrumentation, software discovery, automated collection, DLL hijacking, DLL injection, and search-order hijacking. A nontechnical reader doesn’t need to follow every technique to see the central concern: the process was trying to do more than run once. It was attempting to hide, learn about its environment, and remain available to the attacker.
A small department does not need to be a high-profile target for this to matter. A single workstation can be an entry point into systems that support public safety and day-to-day operations. The risk goes beyond the initial file to what can happen if that activity is allowed to continue unnoticed.
Detection is more than one alert
The endpoint detection and response platform detected and flagged the activity as high severity. That platform is provided at no cost to Utah public-sector entities by the Utah Department of Cybersecurity. AllTech manages and monitors the platform with administrative rights; we do not provide, sell, or own it.
No single unusual process made this event actionable. A command shell, an AppData write, mshta, a scheduled task, or a registry change can each have legitimate explanations in the right context. The combined sequence (the obfuscation, external download, trusted-binary execution, disguised file, and persistence attempts) created a much clearer picture.
Security monitoring is most useful when it can correlate related events quickly enough for a person to evaluate the story they tell. In this incident, the platform surfaced the activity and AllTech’s team was brought in directly to assist with operations and remediation, working alongside the state.
The response window
The alert was detected, handled, and closed in approximately 15 minutes. By the time the incident was resolved, the attacker had not established lasting persistence or exfiltrated data. There was no ransomware deployment, data loss, or downtime for the department.
That outcome should not be read as proof that the attack was harmless. The command had already progressed beyond a misleading prompt: it had downloaded a file, used a legitimate Windows execution path, and attempted multiple persistence mechanisms. It was stopped before those efforts became durable.
For a small department, that timing can be the practical difference between a contained security event and a prolonged recovery effort. The first visible action in a ClickFix attack may take only seconds. The important work is recognizing what follows and responding while the attack is still in motion.
The practical takeaway
There was nothing exotic about the building blocks in this incident. The attacker relied on a familiar social-engineering prompt, a command interpreter, a download, and Windows components that already existed on the workstation. The sophistication was in how those pieces were combined to obscure intent and create a path toward persistence.
Small departments should not have to identify that pattern by manually reviewing command lines, file paths, scheduled tasks, and registry changes after the fact. What protected the department in this case was real-time visibility, correlation across the activity, and people ready to respond immediately. The technology produced the signal, and a human team helped turn that signal into a resolved incident before it became lasting access.
How we help
This kind of detection and response is what our managed SOC does. It reviews alerts from the managed EDR that our endpoint security service runs on every workstation and server, 24/7. When an alert turns out to be an active attack, incident response contains it and removes the attacker’s persistence.
Police departments and other municipalities often have a small IT team, or one person, covering every building. If you want to know whether a command like this one would be seen on your network, ask us.
