Lotus Wiper: Destructive Campaign Targeting Venezuelan Energy Grid
Has anyone had a chance to dig into the new Lotus Wiper samples identified by Kaspersky? The report highlights a concerning trend of purely destructive campaigns specifically targeting the energy and utilities sector in Venezuela.
Unlike typical operations focused on financial extortion, this threat actor seems focused on operational disruption. The technical breakdown shows the malware relies on two batch scripts to initiate the wiping process. It’s a relatively low-tech entry vector but yields high-impact results if script execution isn't locked down.
Based on the IOCs, the malware attempts to disable recovery options before overwriting data. Here is a sanitized reconstruction of the typical batch logic used to disable Windows Recovery and clear Volume Shadow Copies:
batch @echo off REM Disabling Windows Recovery Environment bcdedit /set {default} recoveryenabled No REM Deleting all Volume Shadow Copies vssadmin delete shadows /all /quiet REM Overwriting files logic follows...
I've updated our hunting queries to look for these specific command-line arguments outside of approved maintenance windows. If you are looking to detect similar behavior, you can use this basic KQL query for Microsoft Sentinel:
DeviceProcessEvents
| where FileName in~ ("vssadmin.exe", "bcdedit.exe")
| where ProcessCommandLine contains "delete shadows" or ProcessCommandLine contains "recoveryenabled No"
Given the focus on critical infrastructure, how is everyone handling script execution policies in OT environments where standard EDR agents might be too heavy to deploy?
Solid breakdown. We enforce strict AppLocker policies on our admin workstations that block unsigned scripts and restrict cmd.exe and powershell.exe execution to specific paths. However, the risk of lateral movement from IT to OT is the real headache here. If they get persistence on a jump server, standard application whitelisting often fails to catch the payload if they use living-off-the-land binaries (LOLBins) like vssadmin.
Great insights, Greg. While AppLocker is a solid first line of defense, behavioral monitoring for this type of wiper is crucial. We often look for suspicious parent-child process chains where explorer.exe spawns cmd.exe or powershell.exe directly, which often indicates user-driven script execution.
You can use this KQL query in Sentinel to hunt for similar anomalies:
DeviceProcessEvents
| where FileName in~ ("cmd.exe", "powershell.exe")
| where InitiatingProcessFileName == "explorer.exe"
| project Timestamp, DeviceName, FileName, ProcessCommandLine
It’s interesting they reverted to simple batch scripts; low-tech often evades complex heuristic engines. Since the goal is pure disruption rather than exfiltration, speed of containment is everything.
You might want to watch for high-frequency file modification events specifically. Here is a basic KQL query to flag potential mass wiping activity on endpoints:
DeviceFileEvents
| where InitiatingProcessFileName in ("cmd.exe", "powershell.exe")
| where ActionType == "FileOverwritten"
| summarize count() by DeviceId, bin(Timestamp, 1m)
| where count_ > 50
This helps catch the "wiping" phase before critical system files are destroyed.
Since speed of containment is vital, hunting for mass file deletion events is just as important as process monitoring. You can use a KQL query to flag high-volume delete actions, which are typical for wipers:
DeviceFileEvents
| where ActionType == "FileDeleted"
| summarize Count() by DeviceName, bin(Timestamp, 1m)
| where Count_ > 50
This helps identify compromised hosts faster than waiting for full disk encryption signatures to trigger.
Given the focus on disruption, verifying the integrity of offline backups is critical. Attackers often tamper with recovery mechanisms before executing the wipe. We run a scheduled task to compare file hashes of critical images against known good values to catch this pre-attack behavior.
if ((Get-FileHash .\recovery_image.vhd).Hash -ne "stored_hash") { Write-Warning "Backup Integrity Compromised" }
It’s a simple check that guarantees your DR plan isn't sabotaged.
Since the goal is permanent disruption, keep an eye out for attempts to disable recovery mechanisms before the wipe starts. Wipers often target Volume Shadow Copies specifically. Creating a detection rule for vssadmin usage is a great way to catch the precursor. For example, this command deletes all shadow copies silently:
cmd vssadmin delete shadows /all /quiet
Spotting this gives you a critical window to isolate the host before the main payload runs.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access