REF1695: ISO Lures, CPA Fraud, and the Return of Fake Installers
Hey everyone,
Just caught the Elastic report on REF1695 and wanted to get your thoughts on the delivery mechanism. It’s a financially motivated operation active since late 2023, but what stands out is the pivot from simple cryptomining to CPA (Cost Per Action) fraud.
The actors are using fake software installers distributed as ISO files. Once mounted, the user is presented with a fake installer that deploys a RAT (like Lumma Stealer) and a crypto miner. Interestingly, they monetize further by directing victims to "content locker" pages for software registration—essentially getting paid for every user they funnel to these survey/ad walls.
From a defensive perspective, ISO files are annoying because they often bypass Mark of the Web (MotW) protections if not handled correctly by the browser/email client. I'm currently working on detection logic for the mounting and execution phase.
Here is a KQL query I'm testing to hunt for suspicious PowerShell activity related to ISO mounting:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine contains "Mount-DiskImage"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
Has anyone else observed the "content locker" redirection in their proxy logs? I’m curious if standard URL filtering is catching these registration pages or if they are using fast-flux domains to bypass reputation lists.
Also, how are you handling ISO blocking at the perimeter? GPO or edge blocking?
Solid query. We've had success blocking ISO archives at the mail gateway using a transport rule, but users downloading these from 'file sharing' sites remains a gap. Regarding the CPA fraud, the content locker domains usually have very low TTLs. We started correlating successful HTTP 200 connections to newly registered domains (from logs) immediately following a process spawn from C:\Users\Public\ or Downloads\. That correlation helped us catch a similar campaign last month.
We treat ISOs like EXEs in our environment—straight up block via Attachment Filter in Exchange and strict blocking on web proxies. However, the CPA angle is clever; it lowers the risk for the attacker compared to pure ransomware. I haven't seen the locker pages in our logs yet, likely because our web filter blocks 'gambling/survey' categories by default. It might be worth checking your allow-lists if you think you're infected.
Blocking ISOs is solid hygiene, but for the gaps where users bypass controls, focus on the execution chain. REF1695 relies on the mount-to-execution handoff. We've hunted for PowerShell mounting an image followed immediately by a suspicious process launch.
Here is a basic KQL query to start hunting that behavior:
DeviceProcessEvents
| where ProcessCommandLine contains "Mount-DiskImage"
| join kind=next (DeviceProcessEvents
| where FileName in~ ("cmd.exe", "powershell.exe", "msiexec.exe")) on DeviceId, Timestamp
This catches the pivot from mounting the ISO to the fake installer kicking off.
Great insights on blocking. To add to the detection side, since these ISOs mount as virtual drives, hunting for processes executing from DRIVE_CDROM or paths starting with \?\Volume{ is highly effective. This catches the initial setup.exe invocation regardless of the file name used. Here is a basic KQL hunt for that behavior:
DeviceProcessEvents
| where FolderPath startswith @"\\?\\Volume{"
| summarize count() by FileName, SHA256
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access