Could Your Energy or Utility Network Survive the Lotus Data Wiper Malware?

Most malware wants leverage. Lotus wants silence. Kaspersky documented Lotus as a targeted data wiper used against Venezuelan energy and utilities firms, built to erase disks and strip away recovery paths . If you run an energy or utility environment, the question isn’t “could we get hit?” It’s “would we see the setup moves early enough to stop the wipe?” Let’s walk the exact attack chain, what to monitor, and what resilience looks like when the goal is irreversible damage .

Lotus in plain terms: a wiper with a checklist, not a smash-and-grab

Lotus isn’t built to “get paid.” It’s built to make systems stay down.

Kaspersky’s analysis describes Lotus as a data wiper malware used in targeted attacks against Venezuelan energy and utilities organizations. The design goal is blunt: overwrite physical drives and remove recovery options so the environment can’t be brought back with a quick restore or a simple rebuild . That’s a different threat model than most teams prepare for, because the usual incident response plan assumes you’ll have something left to recover.

Here’s the key difference in plain language:

• Ransomware usually needs your data intact (so you’ll pay).
• A wiper like Lotus wants your data gone (so you can’t operate).

Kaspersky’s description is explicit: Lotus “overwrites the content of physical drives” and “systematically deletes files,” aiming to leave systems “in an unrecoverable state” . When a wiper goes after recovery mechanisms as part of its mission, your “last line” protections (restore points, snapshots, rollback features, even some forensic artifacts) can get targeted too, not just the business files you care about.

Why the Venezuela context matters (without turning it into a headline)

The Lotus activity was observed in a timeframe that “aligns with geopolitical tensions in the region,” per reporting on Kaspersky’s findings . For energy and utility operators, that matters because disruptive malware often follows pressure campaigns: hit operations, hit trust, hit safety margins.

You may also see Lotus referenced alongside the mid-December 2025 disruption at Venezuela’s state oil company PDVSA. The important caveat: there’s no public evidence that PDVSA systems were actually wiped, or even details confirming the attack’s exact nature . Don’t overfit your threat intel to one incident headline.

Take the lesson that is solid: Lotus looks like an operation that treats wiping as a process, with steps and checks—not a chaotic “run it and hope” payload. That’s why the early setup activity is where defenders still have room to win .

The pre-wiper chain: the part your defenders can still win

Lotus doesn’t start by wiping disks. It starts by making you slow, blind, and locked out.

Kaspersky’s write-up (as summarized in reporting) shows a staged approach using two batch scripts that “prepare the system for the final payload by weakening defenses and obstructing normal operations” . That prep window is your best shot at stopping the wipe.

Stage 1: OhSyncNow.bat (setup + coordination)

The first script, OhSyncNow.bat, does two things defenders should treat as a serious early warning:

1. Disables the Windows UI0Detect service
2. Performs an XML file check to coordinate execution across domain-joined systems

That coordination point matters. A “one host” incident can turn into a domain-wide timed event if the attacker is trying to trigger the same actions across multiple machines.

Stage 2: notesreg.bat (take away your ability to respond)

When conditions are met, Lotus moves to notesreg.bat, which Kaspersky notes will :

• Enumerate users
• Disable accounts via password changes
• Log off active sessions
• Disable all network interfaces (NICs)
• Deactivate cached logins

Read that again with an operator’s mindset. This isn’t “persistence.” It’s pre-destruction isolation.

Why these steps are operationally nasty (and why they’re detectable)

These actions are chosen because they attack how response actually happens in energy/utility environments:

• Reduced visibility: if endpoints are getting pushed offline (NICs disabled) , your EDR telemetry and remote admin tools can go quiet right when you need them.
• Broken admin response: mass password changes and forced logoffs can lock responders out, kill active remediation sessions, and slow down containment.
• Host isolation right before destruction: once network interfaces are disabled , even “good” actions like pushing a script to stop a process or collecting triage data get harder.

If you want a simple mental model: Lotus tries to cut the cords first, then it destroys what’s left.

The destructive toolkit: ‘living off the land’ commands that should scare you

Once the prep work is done, Lotus doesn’t need fancy custom tools to start breaking things. It leans on built-in Windows utilities—the stuff admins use every day—then uses them in ways that scream “wiper.”

Kaspersky observed the malware enumerating drives and running diskpart clean all to overwrite them with zeros 【】. That’s not data theft. That’s straight-up destruction.

The Lotus “toolbox” (and what each command is doing)

1) diskpart clean all — zero the drive

• Lotus uses diskpart clean all to overwrite disks with zeros 【】.
• Practical impact: partitions and data get wiped at scale. On many systems, you’re looking at a rebuild, not a restore.

2) robocopy — overwrite directory contents

• Kaspersky also saw Lotus using robocopy to overwrite directory contents 【】.
• Why it’s nasty: robocopy is normal in IT ops. Attackers hide in that normality while destroying data in-place.

3) fsutil — fill free space to complicate recovery

• Next, Lotus calculates free space and uses fsutil to create a file that fills the disk, making restoration harder 【】.
• Translation: even if you were thinking “we’ll do file carving” or “maybe we can recover remnants,” the attacker is trying to bury you in zeros and garbage.

Fast monitoring defenders can implement (without a rebuild of your SOC)

You won’t catch every wiper by signature. You can catch behavior.

Set alerts for unexpected execution of:

• diskpart.exe (especially with clean / clean all) 【】
• robocopy.exe where the pattern looks like mass overwrites, not a scheduled copy job 【】
• fsutil.exe used to create very large files (disk-fill behavior) 【】

Then correlate it with the operational “shut the doors” signals that tend to come right before destruction:

• account resets / forced logoffs
• network interface changes (NICs going down unexpectedly)

Even basic correlation like “diskpart within 30 minutes of mass logoffs or NIC disable events” can turn a messy incident into a contained one.

Inside the Lotus payload: why recovery gets so ugly, so fast

The “living off the land” phase is bad. The Lotus wiper payload is worse because it drops below the file layer.

Kaspersky notes that Lotus operates at a lower level, interacting with disks via IOCTL calls, retrieving disk geometry, and then overwriting physical sectors—not just deleting files you can try to undelete 【】. In simple terms: it’s not just trashing documents. It’s going after the surface those documents live on.

What Lotus does at the system level (translated into plain English)

Kaspersky’s summary of the payload includes these actions 【】:

• Enables all privileges in its token
  Meaning: it tries to give itself the rights needed to do the destructive stuff without getting blocked.
• Deletes Windows restore points using the Windows System Restore API
  Meaning: one of the easiest “roll back” options gets removed early 【】.
• Wipes physical drives by retrieving disk geometry and overwriting all sectors with zeroes
  Meaning: this is closer to “erase the drive” than “delete a folder” 【】.
• Clears the USN journal
  Meaning: it removes a key record of file system activity, which can hurt both investigation and some recovery workflows 【】.
• Repeats wipe cycles and restore point deletion multiple times
  Meaning: it doesn’t trust a single pass. It tries again 【】.
• Updates disk properties via IOCTL_DISK_UPDATE_PROPERTIES after the final wipe
  Meaning: it’s cleaning up state after the destruction pass 【】.

Why “we’ll just restore it” can fail in real environments

Teams usually fall back on three ideas during a crisis:

• File restore
• EDR rollback / remediation
• Rebuild from snapshots

Lotus is engineered to make those options unreliable. If restore points are deleted and disks are physically overwritten, your best-case outcome shifts from “restore quickly” to “re-image everything.” And if your recovery path is online and reachable from the same identity and network blast radius, the wiper can hit that too—especially if you haven’t tested restoring under pressure.

This is the moment where resilience stops being a checkbox and turns into a rehearsal problem.

Detection + resilience playbook for utilities: what to watch, what to lock down, what to rehearse

Lotus is one of those threats where minutes matter. Kaspersky called out specific precursor signals that are practical to monitor, even in busy Windows-heavy utility environments .

What to watch (and what to do when you see it)

Treat these as “stop-the-line” alerts, not tickets.

• UI0Detect service manipulation
  • Why it matters: it’s an early setup move tied to the attack chain .
  • Response action: isolate the host, pull volatile triage (process tree, command line history if available), and hunt for the related batch/script execution around the same timestamp.
• NETLOGON share changes
  • Why it matters: Kaspersky flags this as a precursor activity worth monitoring .
  • Response action: treat as potential domain staging. Check who changed it, from where, and whether similar changes are happening across multiple DCs/servers.
• Mass account/password changes
  • Why it matters: Lotus prep activity includes disabling accounts via password changes .
  • Response action: assume responder lockout is part of the plan. Trigger a pre-approved “break glass” process (out-of-band admin accounts, emergency access workstation, offline runbooks).
• Disabling of network interfaces (NICs)
  • Why it matters: Kaspersky notes disabling all network interfaces as part of the staging .
  • Response action: don’t wait for EDR to report back. Escalate to onsite/plant IT hands and OT support to preserve access paths and prevent more endpoints from being cut off.

Also, Kaspersky explicitly calls out unexpected usage of diskpart, robocopy, and fsutil as a red flag . If you see those pop up near any of the identity/network events above, treat it as active destruction, not “suspicious admin behavior.”

What to lock down so a wiper can’t turn one foothold into a fleet event

• Make destructive admin utilities harder to run at scale
  • Start with strict allow-lists on where tools like disk management utilities can run (jump hosts, tightly controlled admin workstations).
• Tighten identity during vendor access and account lifecycle moments
  • A lot of destructive incidents begin with account takeover, then “legitimate” remote actions.
  • This is where something like Cloaked can help in a very specific way: reducing credential exposure during vendor access and account setup/rotation by using masked identities and safer contact details, so fewer real emails/phone numbers get reused, phished, or spilled during high-change periods.

What to rehearse (because wipers punish assumptions)

Kaspersky’s generic guidance against wipers/ransomware is simple and brutal: keep offline backups and validate restorability frequently .

For utilities, “tested restores” isn’t a quarterly checkbox. It’s proving you can:

• restore after domain issues (accounts changed, sessions killed)
• restore without relying on online paths that could be reachable from compromised hosts
• stand systems back up with the same sequencing operations expects (auth, core services, then app layers)

If you can’t do that on demand, a wiper doesn’t just erase data. It erases your timeline.

‍