DynoWiper, ZOV, and destructive operations

DynoWiper is a destructive Windows wiper recently deployed inside a Polish energy company. Its code, deployment choices, and operator behavior tell a bigger story than a single incident. This piece unpacks what the wiper actually does, how it was pushed, and the practical choke points defenders can work.

What DynoWiper actually does to Windows systems

DynoWiper follows a compact but effective routine: discover local and removable drives, overwrite file content quickly, then force a reboot. The overwrite routine uses a fixed, small random buffer created at start. Files at or below that size get fully overwritten, larger files have only selected regions clobbered to maximize throughput per second. This is a speed over certainty trade: the goal is to break boot and applications before defenders can intervene, not to forensically erase every byte.

Three-phase flow

• Phase 1, recursive wipe across drives while skipping core system folders such as Windows and System32.
• Phase 2, expand scope. In one variant, exclusions at the root, for example C:\Windows, are deliberately not honored, while deep exclusions, for example C:\Windows\System32, remain. In a later rebuild, Phase 2 switched to straight deletions via DeleteFileW, no overwrites.
• Phase 3, trigger a reboot to complete the disruption.

One concrete indicator

In the observed case, the operator staged multiple binaries into a shared IIS path, for example C:\inetpub\pub\, and introduced a short delay between phases in some builds. A short sleep between phases is a tell for timing-based evasion and can be hunted in sandboxes and EDR telemetry by correlating mass file touches, consistent short sleeps, and a shutdown event within minutes.

Operator fingerprints visible in the binaries

The wiper did not land fully formed. Three related builds appeared within a short window, each adjusting logic after the previous one failed to achieve the intended impact. A build artifact pointed to a developer environment using Vagrant. This suggests a hands-on-keyboard feedback loop: compile on a disposable or snapshotable box, deploy, observe blockade, tweak, then redeploy. That pattern is common in destructive operations where time pressure outweighs stealth.

Non-obvious contribution: treat this as a diagnostic lens, the Iterative Destruction Pattern. When multiple siblings of a wiper surface with small timing or exclusion changes and rapid redeployment from the same share, it usually means a defensive control interfered with execution and the operator is actively probing to bypass it. This lens predicts that, in similar environments, defenders will get two or three near-miss chances before the fourth build lands. This inference fails if the adversary pre-stages many variants and rotates them without observing outcomes, or if a continuous integration pipeline produces binaries in batches regardless of field results.

Practical example: one variant preserved system directories during the first pass, then removed the root exclusion on the second pass. That sequencing aims to keep the process alive long enough to reach the reboot call. It also gives defenders a small window to isolate hosts between passes if they key on mass file-handle creation surges.

How DynoWiper aligns with ZOV, and why it matters

DynoWiper’s logic rhymes with a family used against Ukrainian targets, often labeled ZOV. Both iterate fixed and removable drives, both use directory exclusions to survive long enough to finish, and both conclude by forcing a reboot. The key difference is flavor, not skeleton: buffer size and content, the exact exclusion list, and whether a cosmetic payload such as a wallpaper drops at the end. These are wrapper changes around a stable core, which is a hallmark of an actor aiming to avoid simple hash or byte-pattern detections while preserving operator muscle memory.

Side by side, at a glance

Actionable tip: build compound detections that key on behavior sequences rather than strings. Example, scheduled task creation tied to a path on a web or file share, rapid directory walking across multiple volumes, short sleeps between bursts, then a shutdown call. Content markers such as a three-letter prefix in the overwrite buffer are brittle and will be removed once detected.

GPO as the blast multiplier, and the choke points to watch

The wiper rode on top of Active Directory Group Policy. In one case, a PowerShell deployment script embedded target specific variables, for example domain and GPO names, created a scheduled task, and either copied the binary to endpoints or executed it from a shared path. Once Domain Admin level is reached, distribution becomes a solved problem for the attacker. That shifts detection to governance and telemetry, not just malware signatures.

Operational choke points to instrument

• Group Policy guardrails, require change tickets and a second person approval for GPO link and script changes, and forward all GPO modification events to a tamper resistant log store.
• Scheduled task telemetry, alert when a domain wide task appears that runs from administrative shares, web roots, or user profile temp paths.
• Share execution controls, block or audit execution from common staging paths such as inetpub or broad read shares using application control allowlists.
• PowerShell scope control, enforce Constrained Language Mode on domain controllers, and allow only signed scripts from a code signing publisher.

Anti-pattern to avoid

Avoid relying on endpoint blocking alone once directory services are compromised, because a single GPO push can disable sensors, rotate scripts, or execute from paths that your allowlist forgot. This fails through a simple mechanism, the policy applies before agents update, so the attacker races the control and wins. Treat GPO itself as a production deployment system and harden it accordingly.

A representative scenario from an energy network

Context, a Windows domain with a mix of engineering workstations and business PCs, EDR present, no mandatory GPO approvals, execution from web roots not explicitly blocked.

Trigger, T+0, a domain admin token is obtained through credential theft, then a PowerShell script is staged on a domain controller.

Cascade, T+4h, the script creates a GPO with a scheduled task targeting all computers. The task runs a binary directly from a shared IIS directory to avoid copying. EDR on several hosts blocks initial execution, logging mass file touches and a shutdown call. The operator recompiles the binary, removes a root level exclusion, and redeploys the task. A later variant switches to DeleteFileW for the second pass, hoping to sidestep content inspection.

Response, T+8h, defenders isolate subnets based on EDR telemetry, disable the rogue GPO link, and remove the scheduled task. They block share based execution via application control and cut access to the IIS share. A forensic triage shows partial overwrites on noncritical volumes, no OT components directly touched.

Lesson, require dual control on GPO linking, alert on scheduled tasks that reference shares, and treat a rapid sequence of similar binaries as an operator in the loop who will try again within hours.

Attribution, a working hypothesis, and what would disprove it

The overlap in tactics with prior destructive campaigns is substantial, from GPO distribution to the wipe-then-reboot cadence and directory exclusion logic. Medium confidence attribution to Sandworm is reasonable on that basis alone. My synthesis is the Same Skeleton, New Skin hypothesis, the actor maintains a minimal wiper core, then adapts wrappers per target to evade content detections while keeping operator workflow identical. This predicts more short lived wipers with small code deltas, not a jump to kernel level bootkits, unless defenders start reliably catching the user mode behavior chains early.

Falsifiability, this hypothesis fails if upcoming destructive incidents show a pivot to raw disk access drivers, Volume Shadow Copy manipulation before wipe, or pre boot tampering as the primary technique, or if distribution favors EDR API abuse over GPO. It also weakens if initial access, staging, and wipe execution are shown to be executed by a single crew with a consistent toolchain that diverges from the one summarized here.

Controls to implement in the near term

• Enforce two person approval for GPO link changes, and forward event IDs for GPO creation, link, and script updates to a central, immutable log.
• Block execution from web roots, admin shares, and broadly readable file shares using Windows Defender Application Control or an equivalent allowlist.
• Alert on domain wide scheduled tasks, especially those with paths under \hostname\ shares or inetpub, and those that call shutdown.
• Hunt for short sleep bursts plus mass file handle operations across multiple volumes, then a reboot. This sequence is more stable than any single signature.
• Restrict PowerShell on domain controllers to signed scripts, and monitor for attempts to dump LSASS with interactive tools, a common precursor signal.
• Test bare metal recovery for domain controllers and critical servers. This works when backups are stored off domain with independent credentials, and fails if recovery media or credentials are tied to the same compromised directory.

One last what not to do, do not restore a domain controller and immediately relink GPOs en masse. Review each link and script path first, because a malicious deployment can re trigger on reboot and reinfect freshly restored machines.