UAC-0145 (Sandworm) Recycling ClickFix Tactics Against Ukrainian Targets
Just caught the latest alert from CERT-UA regarding UAC-0145. It looks like the Sandworm crew (GRU) is dusting off the ClickFix technique to target Ukrainian entities. For those who haven't dealt with this yet, the mechanic is insidiously simple: users are presented with a fake browser CAPTCHA that asks them to 'verify' they are human by copying and running a PowerShell command.
Instead of solving a puzzle, the victim is pasting an obfuscated script straight into their terminal. The script usually fetches a secondary payload—in this case, data-stealing malware.
Given that social engineering bypasses a lot of traditional perimeter defenses, I've been tuning our detection logic to focus on the PowerShell execution chain. We're seeing success monitoring for specific encoded command patterns typical of ClickFix campaigns. Here is a rudimentary Sigma rule I'm deploying to catch the 'copy-paste' behavior triggering encoded payloads:
title: Potential ClickFix PowerShell Execution
status: experimental
description: Detects suspicious PowerShell execution patterns associated with ClickFix campaigns, specifically Base64 encoded commands.
logsource:
product: windows
service: security
detection:
selection:
EventID: 4688
NewProcessName|contains: 'powershell.exe'
CommandLine|contains:
- 'FromBase64String'
- 'hidden'
- 'windowstyle'
condition: selection
falsepositives:
- Administrative scripts
level: high
Has anyone else observed this specific UAC-0145 activity in their telemetry? How are you handling user awareness training against these 'technical support' style scams?
We saw a similar spike last month. The key differentiator for us was the User-Agent string in the logs preceding the PowerShell execution. The ClickFix landing pages often have very specific, slightly malformed UA strings. We block those at the perimeter now, but endpoint detection is still critical because users often bring their own devices or work off-network.
Great rule, but be careful with false positives on the 'windowstyle' flag; a lot of legitimate admin scripts use it to hide the console. I'd recommend adding a filter to exclude signed scripts or known admin paths. We've had success locking down the Constrained Language Mode (CLM) for non-admin users, which stops the obfuscated payload from decrypting in memory even if they run it.
It's wild that this still works. The psychological aspect of 'I just need to verify I'm not a robot' is powerful. We've started simulating this in our internal phishing campaigns. The failure rate is higher than standard credential harvesting links, which is scary. Technical controls like AMSI triggers are good, but user training here is non-negotiable.
Great insights on the behavioral side. To add a technical layer of defense, ensure Script Block Logging is enabled; it captures the deobfuscated code in memory even if the attacker uses Invoke-Expression. You can enable it via Group Policy or run:
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" -Name "EnableScriptBlockLogging" -Value 1
This has been a lifesaver for analyzing the payload post-execution when the original command was just noise.
To add a preventative layer alongside logging, consider enforcing PowerShell Constrained Language Mode on standard user endpoints. This effectively sandboxes the session, blocking the Win32 API calls that most of these obfuscated ClickFix payloads try to invoke. It stops the exploit chain cold without needing to rely on signature detection. You can check your current enforcement level with:
$ExecutionContext.SessionState.LanguageMode
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access