DOUBLECUP LaaS: Decoding the ClickFix & Steganography Threat
Has anyone else dug into the new DOUBLECUP loader-as-a-service campaign detailed today? The Russian operators are mixing social engineering with some clever evasion techniques. They are leveraging ClickFix lures—those fake browser errors or captchas that trick users into copying and running a PowerShell "fix."
The interesting part is the staging mechanism. Instead of a direct EXE download, they drop a steganographic PNG image into the victim's browser cache. To the file system, it looks like a cached image, but it contains the malicious payload.
The execution flow essentially looks like this:
- User is socially engineered via ClickFix to run a PowerShell script.
- Script downloads a PNG and saves it to the browser cache directory.
- Script extracts hidden shellcode from the PNG (steganography) and executes it.
- Final payloads: CountLoader and a new RAT called DeviceManager.
Because the payload sits in the standard browser cache, standard file scanners might whitelist it based on location alone. I'm thinking we need to monitor for recent image creation in cache folders paired with PowerShell activity.
Here is a quick snippet to scan Chrome's cache for suspicious, recently modified PNGs:
$chromeCache = "$env:LOCALAPPDATA\Google\Chrome\User Data\Default\Cache"
if (Test-Path $chromeCache) {
Get-ChildItem -Path $chromeCache -Filter "*.png" -Recurse -ErrorAction SilentlyContinue |
Where-Object {$_.LastWriteTime -gt (Get-Date).AddHours(-24)} |
Select-Object FullName, Length, LastWriteTime
}
Given that DeviceManager is a new, undocumented RAT, how are you guys handling the detection gap before signatures drop? Are you relying on behavioral heuristics for the loader itself?
We've seen a similar uptick in ClickFix campaigns, but the steganography angle is a new twist for us. From a SOC perspective, the key indicator is usually the PowerShell command itself—look for CopyTo-Clipboard or IEX commands triggered immediately after a browser process spawns a shell.
We've been blocking the specific landing domains associated with ClickFix, but they rotate so fast. Focusing on the cached images might be a better interim control while we wait for AV vendors to flag the specific PNG hashes used by DOUBLECUP.
Interesting approach using the browser cache. If you suspect a machine is compromised, you can dump the PNG and run it through zsteg or steghide to verify the payload, assuming you have the file on disk.
# Install zsteg if missing (gem install zsteg)
zsteg -a suspicious_cached_image.png
If you see output resembling shellcode or PE headers, you've confirmed the steganography. As for defense, strict Application Whitelisting (AppLocker) for PowerShell is really the only way to stop the initial ClickFix execution chain effectively, though it's painful to implement.
The undocumented RAT part is what worries me. Without signatures, we are flying blind on the C2 traffic. I'd recommend setting up some Suricata/Snort rules to alert on any non-standard HTTP traffic coming from user-land processes that shouldn't be initiating network connections, especially if they follow the timing of a browser cache write.
Also, check your EDR for "MemCopy" or "VirtualAlloc" API calls originating from PowerShell child processes—that's a strong indicator of in-memory payload execution like this.
Since the threat actors often wipe the steganographic image from the cache immediately after execution, relying solely on disk artifacts can be tricky. I recommend hunting for the PowerShell decoder logic itself. These loaders typically invoke .NET classes to read pixel data. You can catch this behavior in Defender or Sentinel by querying for System.Drawing usage in PowerShell processes:
DeviceProcessEvents
| where FileName == "powershell.exe"
| where ProcessCommandLine contains "System.Drawing.Bitmap"
This helps identify the infection vector even if the file is already deleted.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access