ClickFix Tactics Evolving: Mitigating UAC-0145's Fake CAPTCHA Delivery
Saw the CERT-UA alert today regarding UAC-0145 (a sub-cluster of Sandworm) leveraging the ClickFix technique against Ukrainian targets. It's concerning to see APT actors successfully weaponizing fake CAPTCHA prompts to trick users into running data-stealing malware themselves.
The mechanics are simple but effective: the user visits a compromised or malicious site, sees a fake 'verify you are human' prompt or error code, and ends up copying a hidden PowerShell script to their clipboard. When they paste it—usually instructed to do so in a 'Run' dialog or terminal—the infection chain begins.
I'm currently working on detection logic for this specific behavior. Since the initial access relies on social engineering rather than a vulnerability exploit, endpoint visibility is crucial. We're seeing the payload often obfuscates itself using environment variables to bypass basic string matching.
I've been experimenting with this KQL query to catch the suspicious PowerShell invocation patterns often associated with ClickFix:
DeviceProcessEvents
| where FileName == "powershell.exe"
| where ProcessCommandLine has "iex" or ProcessCommandLine has "Invoke-Expression"
| where ProcessCommandLine has "clipboard" or ProcessCommandLine has "Get-Clip"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
Is anyone seeing specific IoCs or C2 domains associated with this latest UAC-0145 wave? I'm particularly interested in the persistence mechanisms they are using once the initial data stealer lands.
We've seen a similar spike in ClickFix activity, though not necessarily attributed to UAC-0145 directly in our telemetry. Your KQL query is a solid start, but we've had better luck focusing on the parent process. In these attacks, the powershell.exe is almost always a child of cmd.exe or launched directly from the Run dialog (explorer.exe), which is atypical for administrative scripts.
I’d recommend adding an exclusion for known management tools to reduce noise. Also, enabling AMSI (Antimalware Scan Interface) logging is critical here; even if the script is obfuscated, AMSI often catches the de-obfuscated strings in memory before execution.
From a sysadmin perspective, the most effective block we've found against ClickFix isn't detection—it's prevention via Attack Surface Reduction (ASR) rules. Specifically, the 'Block Office applications from creating child processes' and 'Block JavaScript or VBScript from launching downloaded executable content' rules have stopped the droppers we've tested.
However, blocking PowerShell execution entirely isn't feasible for us. Has anyone had success with AppLocker policies restricting scripts to only run from specific signed directories? I'm worried about breaking legacy line-of-business apps.
Solid advice on the ASR rules, Frank. Since ClickFix relies on the clipboard, I’d recommend monitoring for PowerShell processes invoking Get-Clipboard followed by Invoke-Expression. This specific sequence is a high-fidelity signal for this attack vector. We’ve been rolling out a detection rule for this behavior:
Get-Clipboard | iex
Catching the execution regardless of the obfuscation method used in the prompt.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access