ClickFix Tactics Evolve: Lorem Ipsum & Potemkin Targeting Edu/Finance
Hey everyone,
Just finished reviewing the latest reports from Morphisec, BlueVoyant, and Huntress regarding the expansion of ClickFix campaigns. It looks like the threat actors are aggressively iterating on their delivery methods, now utilizing three distinct malware loaders: the recently identified BabaDeda, the strangely named Lorem Ipsum Loader, and Potemkin.
For those who might have missed the earlier threads, ClickFix typically relies on a social engineering angle where users are tricked into copying and pasting a PowerShell command into a Run dialog (Win+R) to fix a fake browser update or CAPTCHA error. The shift in targeting toward Education and Finance sectors is particularly concerning, given the sensitivity of the data in those verticals.
Since the initial infection vector relies heavily on user interaction followed by a PowerShell execution chain, standard EDRs sometimes struggle if the execution context appears "user-initiated." We've been hunting for the specific obfuscation patterns associated with BabaDeda. If you're looking to augment your SIEM, here is a basic KQL query we've used to flag suspicious long-base64 encoded commands often used in these campaigns:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessVersionInfoOriginalFileName == "powershell.exe"
| where ProcessCommandLine has "FromBase64String"
| where strlen(ProcessCommandLine) > 2000
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
| order by Timestamp desc
The inclusion of the "Lorem Ipsum" loader is new to me. Has anyone successfully extracted the C2 infrastructure or specific IOCs for this one yet? I'm curious if the payloads are just standard stealers or if we're seeing ransomware precursors.
How are your teams handling the 'fake update' lures? Is technical blocking (like ASR rules) winning over user awareness training in your experience?
We saw a spike in the Lorem Ipsum loader last week targeting our finance department. The TTPs are almost identical to the older ClickFix campaigns, but the staging process uses a heavily obfuscated PowerShell script that interacts with the Windows Registry to bypass AppLocker policies. We've had some success blocking it with the Attack Surface Reduction (ASR) rule 'Block Office applications from creating child processes', but these attackers are quick to pivot to other LOlBins (Living off the Land Binaries).
From the MSP side, this is a nightmare. User training just doesn't stick when the prompt looks like a legitimate Chrome/Edge update. We've started pushing a GPO that disables the 'Run' command for standard users via the registry. It breaks a few legacy workflows, but it has completely stopped the ClickFix success rate on our endpoints.
# Disable Run Command for Standard Users
$path = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
Set-ItemProperty -Path $path -Name "NoRun" -Value 1 -Type DWord
I've been analyzing the Potemkin loader in a sandbox. It's interesting because it uses a delayed execution mechanism to evade sandbox detonation. It checks the system uptime and MAC address vendor before unpacking the final payload. If anyone is hunting, look for svchost.exe spawning child processes with network connections to non-standard ports; that was the smoking gun in our environment.
Solid intel from everyone. On the detection side, we've had luck hunting for the child processes spawned by the fake browser update executables. Usually, they invoke PowerShell with encoded commands. You can run this quick query to find suspicious parent-child relationships on your endpoints:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -match 'powershell.exe' -and $_.Message -match 'chrome.exe|msedge.exe'} | Select-Object TimeCreated, Message
Has anyone looked at the C2 infrastructure for BabaDeda yet? I'm curious if it overlaps with older IcedID infrastructure.
Great insight, Dave. Hunting those child processes is definitely the most reliable detection method right now, especially since the initial enticement is so socially engineered.
For those using Sentinel, we've deployed a KQL rule focusing on the parent-child relationship between legitimate browser processes and unexpected PowerShell spawns with encoded arguments:
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("chrome.exe", "msedge.exe")
| where FileName == "powershell.exe"
| where ProcessCommandLine contains "-EncodedCommand"
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
This has been catching the obfuscation attempts used by the Lorem Ipsum loader effectively.
Building on Amy's point regarding obfuscation, ensure your Script Block Logging retention is high enough to capture the full payload. We've found that the Lorem Ipsum loader specifically relies on FromBase64String calls to unpack. You can hunt for this specific behavior across endpoints with:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-PowerShell/Operational'; ID=4104} | Where-Object {$_.Message -match "FromBase64"} | Select-Object TimeCreated, Message
Has anyone observed Potemkin establishing persistence via Registry Run keys rather than Scheduled Tasks?
That’s interesting about the file naming conventions, Amy. For the Lorem Ipsum loader specifically, we noticed the dropped binaries often retain those dummy text strings in the file path or metadata. We’ve had success hunting for these anomalies directly:
DeviceProcessEvents
| where ProcessVersionInfoOriginalFilename contains "lorem" or ProcessVersionInfoOriginalFilename contains "ipsum"
| project Timestamp, DeviceName, FileName, ProcessCommandLine
It’s a simple heuristic, but it flags the staged files before they even invoke the PowerShell child processes Dave mentioned.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access