GigaWiper: The 'Frankenstein' Backdoor Blending Wipers and Fake Ransomware
Just caught the Microsoft write-up on this new Windows backdoor, 'GigaWiper.' It’s a stark reminder of the shift toward 'modular' destruction. Instead of a single-purpose wiper, the operators have bolted together three distinct legacy destructive tools into one interface, giving them the option to choose their chaos flavor.
What stands out to me is the 'Fake Ransomware' component. It scrambles files using encryption but never saves the key. This is purely destructive, yet designed to look like a financially motivated incident to confuse attribution and response timelines. Combine that with a raw disk wiper and a Windows drive overwriter, and you have a nasty toolkit.
Since the behavior varies (encryption vs. raw disk writes), detection needs to cover multiple vectors. We've been looking for direct disk handle access which usually flags these wipers before they fully execute. Here is a quick PowerShell snippet we use to hunt for processes attempting direct physical drive access:
# Detect potential direct disk access attempts (Common in wipers like GigaWiper)
$processes = Get-CimInstance Win32_Process
$suspicious = @()
foreach ($proc in $processes) {
if ($proc.CommandLine -match "\\\\.\\PhysicalDrive[0-9]+" -or $proc.CommandLine -match "\\\\.\\[A-Z]:") {
$suspicious += [PSCustomObject]@{ Name=$proc.Name; PID=$proc.ProcessId; CmdLine=$proc.CommandLine }
}
}
if ($suspicious) { $suspicious | Format-Table -AutoSize } else { Write-Host "No suspicious direct disk access found." }
With the increasing sophistication of these 'blended' threats, are we seeing a trend where pure extortion is being replaced by pure destruction masked as extortion? How are you guys tuning your EDRs to distinguish between legitimate disk utilities and these wipers?
Good catch on the direct disk handle detection. From a SOC perspective, the 'fake ransomware' angle is particularly annoying because it triggers all the standard 'crypto' alerting, causing analysts to initially triage it as a standard playbook event rather than an immediate emergency disk wipe. We've started correlating crypto-events with VSS shadow copy deletions in our SIEM to flag this specific dual-behavior faster.
The modularity is the real threat here. An attacker can run recon, decide if the target is high-value enough for fake ransom (to panic the victim) or just wipe it if they are in a hurry. In terms of mitigation, strictly limiting SeDebugPrivilege and removing admin rights from user accounts can stop the backdoor from installing the necessary drivers to perform the raw disk overwrite, but that doesn't help if they already have SYSTEM.
I've seen similar tactics in the wild with ICS-focused wipers. They use the 'encryption without key' method specifically to bypass backup recovery verification checks that some automated DR solutions run. If the DR software sees 'encrypted' files, it might just queue them for decryption rather than realizing the data is effectively scrambled trash. Hard recovery if you don't catch it in the first few minutes.
That modularity is a double-edged sword for them; while it offers flexibility, it creates a messy process tree. Since they bolt on legacy tools, we can hunt for improbable parent-child relationships. I've had success catching these by flagging when cmd.exe or powershell.exe spawns unsigned binaries that aren't standard admin utilities.
DeviceProcessEvents
| where InitiatingProcessFileName in ("cmd.exe", "powershell.exe")
| where IsSigned == 0
| where Timestamp > ago(7d)
That "Frankenstein" assembly creates a distinct timeline artifact. Because these legacy tools lack a unified C2, they often execute in rapid succession locally once triggered. This creates a "burst" of process activity—recon followed immediately by destruction—within seconds.
Analysts can hunt for this velocity anomaly to detect the modular deployment:
DeviceProcessEvents
| summarize ProcessCount = count() by DeviceId, bin(Timestamp, 5s)
| where ProcessCount > 4
| join kind=inner (DeviceProcessEvents) on DeviceId, Timestamp
This behavior often differentiates automated destruction from standard admin tasks.
In an OT context, the impact extends beyond data to operational uptime. If these legacy wiper components hit an Engineering Workstation, restoring project files is often more complex than standard IT recovery. To catch this behavior on critical assets, I recommend hunting for the combination of cipher.exe and vssadmin.exe, which are rarely used together in normal operations.
DeviceProcessEvents
| where FileName in~ ('cipher.exe', 'vssadmin.exe')
| summarize count() by DeviceName, FileName, Timestamp
Spotting these executing in a tight window on an HMI server is a major red flag.
That 'Frankenstein' assembly is a nightmare for recovery, but it leaves a messy filesystem footprint. Since the fake ransomware component scrambles files without a key, we can hunt for rapid, high-entropy file writes in user directories—something standard backups might miss until it's too late.
Try this KQL query to spot the 'burst' of file creation associated with the encryption simulation:
Sysmon
| where EventID == 11
| summarize count() by Computer, bin(Timestamp, 1m)
| where count_ > 500
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access