PROBABLYPWNED
MalwareFebruary 19, 20264 min read

Inside DynoWiper: Mersenne Twister PRNG and File Destruction

SANS ISC analyzes DynoWiper's internals revealing Mersenne Twister seeding, 16-byte overwrite buffers, and directory exclusions. Technical breakdown of Sandworm's latest wiper.

James Rivera

Security researchers at SANS Internet Storm Center have published a technical teardown of DynoWiper, the data destruction malware Sandworm deployed against Poland's power grid in late December 2025. The analysis reveals implementation details including the wiper's pseudo-random number generation, file corruption strategy, and selective directory targeting.

How DynoWiper Initializes

The malware begins by initializing a Mersenne Twister MT19937 pseudo-random number generator with a fixed seed value of 5489. It then re-seeds the PRNG using a value generated by std::random_device, adding entropy from the host system. This two-stage seeding approach ensures some unpredictability in the destruction pattern while maintaining deterministic behavior during testing.

According to the SANS ISC diary entry, researchers recovered three distinct DynoWiper samples compiled between December 26-29, 2025. The PDB path embedded in the binaries—pointing to a Vagrant VM build environment—suggests automated compilation infrastructure.

The Data Corruption Process

DynoWiper operates in two distinct phases: corruption and deletion.

During the corruption phase, the wiper:

  1. Enumerates logical drives using GetLogicalDrives()
  2. Identifies fixed and removable drives for targeting
  3. Recursively traverses directories while skipping protected folders
  4. Generates a 16-byte buffer filled with random data
  5. Overwrites target files using this buffer

For files 16 bytes or smaller, the entire contents get overwritten. Larger files receive partial corruption—the wiper generates pseudo-random offsets (maximum 4,096 bytes apart) throughout the file and writes the same 16-byte junk data to each location. This optimization speeds up destruction while ensuring file recovery becomes impractical.

Directory Exclusions

The malware deliberately avoids certain system directories to prevent premature operating system failure. These exclusions allow the wiper to complete its destruction before the system becomes unstable:

  • system32
  • windows
  • program files / program files(x86)
  • temp
  • recycle.bin / $recycle.bin
  • boot
  • perflogs
  • appdata
  • documents and settings

Researchers at ESET noted that this exclusion logic closely mirrors the ZOV wiper previously attributed to Sandworm, though ZOV uses a larger 4,098-byte buffer prefixed with the string "ZOV" followed by null bytes.

The Deletion Phase

After corrupting files, DynoWiper enters its deletion phase. The wiper re-enumerates drives and directories—this time skipping root-level exclusions—and permanently removes files using the DeleteFileW() API.

Before forcing a system reboot, the malware obtains a process token and enables SeShutdownPrivilege. It then calls ExitWindowsEx() to restart the machine, completing the destruction cycle. The reboot ensures corrupted system files prevent normal recovery operations.

Attribution Evidence

ESET attributes DynoWiper to Sandworm with medium confidence based on operational overlap. The Group Policy deployment scripts, targeting of energy infrastructure, and technical similarities to previous Sandworm wipers like ZOV support this assessment. ESET has also published additional IOCs including SHA-1 hashes for three DynoWiper variants.

The attack leveraged supporting infrastructure at 31.172.71[.]5 (Fornex Hosting S.L.) running a SOCKS5 proxy. Attackers downloaded additional tools including Rubeus for Kerberos attacks and rsocx for reverse proxy connections.

MITRE ATT&CK Mapping

The technical analysis maps DynoWiper to several ATT&CK techniques:

  • T1059.001 - PowerShell execution
  • T1059.003 - Windows Command Shell
  • T1053.005 - Scheduled Task creation
  • T1003.001 - LSASS credential dumping
  • T1561.001 - Disk content wiping
  • T1529 - System shutdown/reboot

Defenders monitoring for these techniques in critical infrastructure environments should review detection rules for unauthorized scheduled tasks and mass file access patterns. The combination of credential harvesting followed by scheduled wiper deployment represents a multi-stage attack pattern defenders should anticipate.

Indicators of Compromise

SHA-1 HashFilenameDetection
4EC3C90846AF6B79EE1A5188EEFA3FD21F6D4CF6[redacted]_update.exeWin32/KillFiles.NMO
86596A5C5B05A8BFBD14876DE7404702F7D0D61Bschtask.exeWin32/KillFiles.NMO
69EDE7E341FD26FA0577692B601D80CB44778D93schtask2.exeWin32/KillFiles.NMO

Network Indicator: 31.172.71[.]5 (SOCKS5 proxy infrastructure)

Why This Matters

The technical sophistication of DynoWiper falls somewhere between crude script-based wipers and complex modular malware. The Mersenne Twister implementation and selective corruption strategy suggest professional development, while the fixed initial seed and exposed PDB paths indicate areas for improvement the threat actor will likely address in future variants. The attack pattern mirrors other state-sponsored APT operations targeting critical sectors—reconnaissance followed by staged payload deployment.

Energy sector organizations—particularly those in NATO countries—should review the CISA guidance on protecting critical infrastructure from destructive attacks. The failed Poland attack demonstrates that endpoint detection tools can block wiper execution, but the broader Sandworm campaign against Western energy infrastructure remains active.

Organizations should implement application allowlisting, segment OT networks from IT environments, and maintain offline backups that wipers cannot reach through network traversal.

Related Articles