Deconstructing GigaWiper: Analyzing the New Modular Backdoor
Just reviewed the Microsoft analysis on the new GigaWiper backdoor. It’s a textbook example of destructive modularity. Rather than a monolithic tool, the authors have bolted together three distinct destructive capabilities: a full disk wiper, a Windows drive overwriter, and a 'fake' ransomware module.
The ransomware aspect is particularly insidious—it encrypts files but intentionally discards the key, rendering recovery impossible even if the victim pays. This confirms the trend toward pure destruction disguised as extortion.
For hunting, we need to focus on the precursors. The backdoor likely needs to disable recovery mechanisms before wiping. I'm currently rolling out a KQL query to catch the common vssadmin deletion strings that usually precede these events:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine contains "vssadmin" and ProcessCommandLine contains "delete" and ProcessCommandLine contains "shadows"
| project Timestamp, DeviceName, FolderPath, ProcessCommandLine, InitiatingProcessAccountName
Additionally, checking for unexpected disk signature changes via PowerShell is a good baseline for the wiper component:
Get-Disk | Select-Object Number, FriendlyName, PartitionStyle, Signature
Given that this is a backdoor, C2 traffic is vital. Are we seeing standard HTTP/S C2 or something more obfuscated in the wild? How are others handling the 'fake ransomware' classification in your playbooks—is it triggering extortion workflows or destruction workflows?
We treat any encryption activity that lacks a clear ransom note or C2 heartbeat as a destructive attack immediately. It cuts out the negotiation phase and buys us time for isolation.
We also look for the wevtutil cl command clearing logs, which often accompanies these wipers. You can hunt for that with:
DeviceProcessEvents
| where ProcessCommandLine contains "wevtutil" and ProcessCommandLine contains "cl"
This saved us during a recent 'fake' ransomware incident that turned out to be a wiper.
The modularity is the scary part. It allows the attacker to adapt based on the victim's profile—wiping a high-value target vs. 'rattling' a smaller one with fake ransom.
From a sysadmin perspective, AppControl (WDAC) is becoming the only reliable defense against these bolted-together binaries. If you haven't started signing your internal scripts, now is the time. Blocking vssadmin entirely via GPO is also a solid, if slightly aggressive, mitigation step.
Has anyone managed to extract the C2 configuration strings yet? I'm curious if they are using hardcoded domains or some sort of DGA (Domain Generation Algorithm).
If they are reusing older components, the crypto implementation for the 'fake' ransomware might be weak. Even if the key is tossed, analyzing the cipher could help identify similar strains in the future. I'll be spinning up a sandbox tomorrow to poke at the encryption routine.
That behavior confirms pure destruction, so verify backup immutability immediately. For detection, we’re focusing on the handoff between the dropper and the wiper module. Specifically, we hunt for unusual handle requests to physical drives.
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=10; TargetObjectName='\\Device\\Harddisk*'} | Where-Object {$_.GrantedAccess -eq 0x1F0FFF}
Are you seeing this specific access pattern across the different victim environments?
To detect the wiper module, focus on raw disk handle requests. Standard applications shouldn't access \\.\\PhysicalDrive. We use this KQL hunt:
DeviceFileEvents
| where FileName contains "\\\\.\\PhysicalDrive"
| where InitiatingProcessFileName !~ "diskpart.exe"
Filtering out diskpart and admin tools keeps the noise manageable.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access