In late December 2025, a destructive cyber operation targeted an energy-sector organization in Poland using previously undocumented data-wiping malware that ESET researchers have named DynoWiper. The malware was deployed with the intent to irrecoverably delete data on infected Windows hosts, thereby impairing systems necessary for business continuity and recovery. Although defensive controls prevented significant impact, detailed analysis reveals a structured, multi-phase destructive workflow. Based on Tactics, Techniques, and Procedures (TTPs) and code overlaps with historical incidents, ESET attributes DynoWiper to the Sandworm threat actor with medium confidence.
1. Attribution and Threat Actor Context
Sandworm Overview
- Sandworm (also tracked as Unit 74455 of Russia’s GRU by U.S. authorities) is a highly capable, Russia-aligned Advanced Persistent Threat (APT) group with a long history of disruptive attacks on critical infrastructure.
- Historically responsible for a series of high-impact operations that involve destructive malware, including NotPetya, Industroyer, and BlackEnergy variants that caused widespread outages in Ukraine and impacted global supply chains.
- Frequently targets energy grids, utilities, and industrial sectors, consistent with the profile of the Poland energy incident.
Confidence Level and Rationale
Attribution to Sandworm is judged as medium confidence for the following reasons:
- There is a strong overlap between DynoWiper and known Sandworm destructive malware in operational patterns (wiper deployment mechanisms, artifact similarities).
- The sector targeted — energy — aligns with Sandworm’s historical objectives.
- Preparatory tools and deployment techniques (e.g., scheduled tasks, shared directories, PowerShell abstraction) resemble Sandworm behaviors.
- Absence of publicly known alternative actors with comparable capabilities in this context.
However, because initial access vectors remain unknown (and could have been facilitated by other actors cooperating or preceding Sandworm), the confidence is deliberately moderate and not high.
2. Incident Timeline and Operational Details
Attack Window
- December 29 – 30, 2025: Three distinct DynoWiper samples were deployed to the victim’s domain.
- All samples were executed from a shared network directory (often used to stage malware in enterprise environments).
- EDR/XDR controls (specifically ESET PROTECT) appear to have blocked execution or limited destructive impact.
Deployment Vector and Execution
Based on observed artifacts:
- Multiple revisions of the malware were built and deployed on the same day, indicating iterative development and rapid deployment attempts by threat operators.
- File metadata (including Visual Studio PDB paths) indicates compilation using a Vagrant environment, suggesting virtual machine staging prior to deployment.
- Execution was orchestrated via Windows Scheduled Tasks — a common persistence/execution technique that avoids interactive triggers and ensures scheduled execution on domain systems.
3. Malware Design and Workflow
Classification
- DynoWiper is classified as a data-wiping malware — meaning its primary goal is to destroy files irrecoverably, not ransom or extort.
- ESET classifies DynoWiper as Win32/KillFiles.NMO.
Phases of Operation
DynoWiper’s internal workflow, as determined through static and dynamic analysis, consists of three distinct phases:
Phase 1 — Recursive Data Destruction
- Recursively traverses fixed and removable drives to overwrite and delete files.
- Uses a 16-byte random buffer generated once per execution:
- Files ≤ 16 bytes are fully overwritten.
- Larger files have portions overwritten to accelerate destruction.
- Certain critical system paths are initially excluded to delay defensive detection (e.g., \Windows\System32, Program Files directories), though exclusions may differ slightly between sample variants.
- For some variants, additional files and directories are removed without overwriting, directly via API calls (e.g., DeleteFileW).
- The malware ignores certain Windows directories in the early loop to reduce immediate detection; however, later phases remove broader targets in root directories.
- The algorithm used is consistent with destructive wiper behavior rather than opportunistic ransomware deletion.
Phase 2 — Escalation and Broad Deletion
- Some variants remove more system directories by expanding deletion to entire root structures.
- In cases where the malware is executed with high privileges, all files on fixed drives may be deleted entirely.
Phase 3 — System Reboot
- Following destructive activity, the wiper forces a system reboot to finalize damage and prevent recovery workflows.
- This is often done through system APIs or equivalent shell invocation.
4. TTPs and MITRE Mapping
Mapped to MITRE ATT&CK v11 where applicable:
| Stage | Technique | ATT&CK ID |
|---|---|---|
| Initial Access (unknown) | Pending investigation | — |
| Execution | Windows Scheduled Tasks | T1053.005 |
| Execution | Command/Scripting Interpreter | T1059.x |
| Discovery | File & Directory Discovery | T1083 |
| Impact | Disk Content Wipe | T1561.001 |
| Impact | System Shutdown/Reboot | T1529 |
| Defense Evasion | Exclusion of key system dirs | (artifact-specific) |
Note: Initial access remains undetermined, making it a priority for further incident response and forensic analysis.
5. Indicators of Compromise (IOCs)
Below are actionable IOCs derived from published analysis (SHA-1 hashes detected as DynoWiper by ESET and associated artifacts):
| Hash Type | Value | Description |
|---|---|---|
| SHA-1 | 4EC3C90846AF6B79EE1A5188EEFA3FD21F6D4CF6 | DynoWiper sample (<redacted>_update.exe) |
| SHA-1 | 86596A5C5B05A8BFBD14876DE7404702F7D0D61B | DynoWiper (schtask.exe) |
| SHA-1 | 69EDE7E341FD26FA0577D692B601D80CB44778D93 | DynoWiper (schtask2.exe) |
Detections: Security products (EDR/XDR) will detect these as variant identifiers such as Win32/KillFiles.NMO depending on vendor categorization and versioning.
6. Operational and Defensive Observations
Defender Insights
- Presence of Active Directory Group Policy in prior Sandworm operations suggests “domain-level deployment” capability, but in this campaign, execution was achieved via network share and scheduled tasks — possibly due to segmentation or defensive posture.
- The attacker may have exercised progressive build and deploy strategy (multiple compile timestamps) in response to defensive feedback.
Mitigating Factors
- EDR/XDR solutions limited execution of the malware variants, significantly reducing real impact.
- Early deployment blocking prevented OT systems (critical SCADA controllers) from being targeted in this incident.
7. Summary and Key Takeaways
- DynoWiper is a purpose-built data-wiping malware designed to irreversibly destroy files on Windows endpoints.
- The malware was deployed against an energy entity in Poland during late December 2025.
- Based on behavioral and forensic linkage, ESET researchers attribute the activity to the Sandworm APT with medium confidence.
- Rapid iterative builds and deployment attempts show an active adversary adjusting to defensive observations.
- EDR/XDR products played a critical role in mitigating impact, highlighting the value of modern defensive controls in critical infrastructure environments.
