A Wiper Attack on a Venezuelan Oil Company: Reverse Engineering the Lotus Wiper that Disrupted PDVSA Systems
In early 2026, Kaspersky published an article identifying a new wiper-type malware called Lotus Wiper. This malware targeted the infrastructure of a Venezuelan oil company with the aim of disrupting its systems. However, what initially appeared to be a standard cybercrime proved to be something more significant when considering the context surrounding the Venezuelan oil company at the time of the attack.
The United States had been conducting an economic and military offensive against Venezuela since late 2025, culminating in the capture of dictator Nicolás Maduro in January 2025. According to the Kaspersky report, this malware was used in an incident targeting PDVSA (Petróleos de Venezuela S.A.) just days before the final operation. CNN also reported that PDVSA had suffered a cyberattack similar in nature to ransomware. Adding to this context, U.S. President Donald Trump stated in a speech that U.S. cyber forces had directly participated in the military operation within Venezuelan territory, assisting with environmental positioning (TAO maybe?).
I will leave the full analysis of this raw data to Threat Intelligence specialists and analysts, because I am merely a humble malware analyst. That said, let us examine the samples that make up Lotus Wiper.
Threat Summary and Tatics, Techniques and Procedures Mapping
As I said before, Lotus Wiper is a multi-stage destructive malware (wiper) family first documented by Kaspersky in early 2026 and deployed against PDVSA (Petróleos de Venezuela, S.A.), Venezuela’s state-owned oil company. It has no ransom, extortion, or financial component: its sole objective is to render targeted hosts permanently inoperable and unrecoverable. The intrusion coincided with heightened US, Venezuela geopolitical and military tensions, and the malware is tightly tailored to PDVSA’s environment, hardcoded pdvsa.com domain, a deliberately preserved PdvsaAIT account (likely a backdoor), and a trigger keyed to the victim’s Domain Controller, pointing to a deliberately targeted, destruction-focused operation rather than opportunistic crimeware. Attribution beyond this circumstantial context is not established in the analysis.
The malware comprises three components plus a loader/decryptor, executed in sequence:
- Trigger (OHSyncNow.bat) : a lightly obfuscated batch script that periodically polls the PDVSA DC for OHSync.xml under NETLOGON\lotus\ and only detonates the next stage when the artifact is present, acting as an environment-bound execution guardrail.
- Disk Content Wiper (notesreg.bat) : removes account access, isolates the host from the network, and destroys file content and partition data using living-off-the-land utilities (diskpart clean all, robocopy /MIR from an empty source, fsutil free-space filling, rmdir).
- Decryptor (nstats.exe) : a minimal C binary that XOR-decrypts (single-byte key 0x03) the encrypted final stage and writes it into a benign binary that is then executed, defeating static detection of the payload.
- Disk Structure Wipe (third stage) : a compiled, multi-threaded destructor that zeroes GPT/MBR structures via direct physical-disk access (\.\PhysicalDrive0–127), zeroes file content through the filesystem driver (FSCTL_SET_ZERO_DATA), deletes all restore points, and forces a shutdown.
Lotus Wiper places heavy emphasis on anti-forensics and EDR evasion: it destroys each volume’s USN Change Journal before and after wiping, thrashes MFT records via repeated renaming, performs zeroing at the filesystem-driver level to avoid user-mode write telemetry and entropy-based detection, opens volumes with minimal access rights to stay under detection thresholds, relies on native APIs (no vssadmin/fsutil child processes or command-line indicators), and enumerates volumes with FindFirstVolumeW/FindNextVolumeW to reach partitions without drive letters (recovery partitions,mount points, unmapped disks). The combined effect (the author’s “Wipe Overkill”) leaves a host with no valid partition table, no recoverable file content, no shadow copies, and a corrupted forensic timeline, typically ending in an immediate crash or BSOD on reboot.
Below you can see the hashes of the samples that I’ll analyze it in this post.
| SHA256 | File |
| 405177294f6f9268432a43998049ad0d4a61c6909216533b8713c911bc430755 | OHSyncNow.bat |
| 9d05854c95c6afa68911bd28af12282185e0fe34f2e58fddbc503ab22d1508d7 | notesreg.bat |
| 1d6f374087087738b7699ebf91f1cfdb3b2a65c2e9be72e106ee7c9814be3274 | nstats.exe |
| b290d1bfec94fdf5f6c346a52ae090e6c7cf072d9bf875bd6e6a2dc27cc3c44a | Encrypted 3th Stage |
| 111ea3f5c4a4239a3f5f08de5f243e9d01da9d021fc393e277c1e6cadc27d327 | Decrypted 3th Stage |
MITRE ATT&CK TTP Mapping
| Tactic | Technique ID | Technique / Sub-technique | Procedure observed in Lotus Wiper |
|---|---|---|---|
| Execution | T1059.003 | Command and Scripting Interpreter: Windows Command Shell | Trigger and Disk Content Wiper implemented as cmd/batch scripts (OHSyncNow.bat, notesreg.bat). |
| Execution | T1106 | Native API | Third stage performs destruction via native APIs (CreateFileW, DeviceIoControl, SRSetRestorePointA/SRRemoveRestorePointA, ExitWindowsEx), avoiding child processes and CLI artifacts. |
| Privilege Escalation | T1134 | Access Token Manipulation | ImpersonateSelf + AdjustTokenPrivileges to enable SeBackupPrivilege/SeRestorePrivilege; FILE_FLAG_BACKUP_SEMANTICS (0x02000000) to bypass ACLs when opening files. |
| Defense Evasion | T1480 | Execution Guardrails | Next stage runs only if OHSync.xml exists at pdvsa.com\NETLOGON\lotus\, binding execution to the PDVSA environment. |
| Defense Evasion | T1027 | Obfuscated Files or Information | Variable-name obfuscation across both batch scripts; final stage stored XOR-encrypted (key 0x03) on disk. |
| Defense Evasion | T1140 | Deobfuscate/Decode Files or Information | nstats.exe XOR-decrypts the third stage before execution (validated via CyberChef XOR 0x03). |
| Defense Evasion | T1036 | Masquerading | Benign-looking artifacts (OHSync.xml, notesreg.bat, nstats.exe, nevent.exe, ndesign.exe); decrypted payload written into a non-malicious binary prior to execution. |
| Defense Evasion | T1112 | Modify Registry | Sets HKLM…\Winlogon\CachedLogonsCount to 0 to block cached-credential logons after DC isolation. |
| Defense Evasion | T1070 | Indicator Removal | Destroys each volume’s USN Change Journal (FSCTL_CREATE/QUERY/DELETE_USN_JOURNAL) before and after wiping; MFT thrashing via successive renames to break NTFS timeline reconstruction. |
| Defense Evasion | T1070.004 | Indicator Removal: File Deletion | Self-deletes .exe artifacts on re-run (l2f39m0.xml guard); robocopy /MIR (empty source) and rmdir /s /q mass deletion. |
| Discovery | T1082 | System Information Discovery | ver (OS version), wmic logicaldisk get Caption (drives), fsutil volume diskfree (free space), IOCTL_DISK_GET_DRIVE_GEOMETRY_EX (disk geometry). |
| Discovery | T1033 | System Owner/User Discovery | net user enumeration of local accounts; qwinsta to list active sessions. |
| Discovery | T1135 | Network Share Discovery | wmic share where name=’NETLOGON’ to validate share presence on the DC. |
| Impact | T1531 | Account Access Removal | Randomizes local passwords (32-char), skips PdvsaAIT backdoor, disables accounts (/active:no), restricts logon window (/times:friday,01:00-02:00); forces logoff of sessions. |
| Impact | T1489 | Service Stop | Disables and stops the UI0Detect (Interactive Services Detection) service. |
| Impact | T1485 | Data Destruction | robocopy /MIR (empty source) + rmdir to destroy Users, ProgramFiles, ProgramFiles(x86), Documents and Settings; free-space-filling file to defeat carving. |
| Impact | T1561.001 | Disk Wipe: Disk Content Wipe | Multi-threaded zeroing of file/volume content across all mounted volumes via FSCTL_SET_ZERO_DATA. |
| Impact | T1561.002 | Disk Wipe: Disk Structure Wipe | diskpart clean all; direct-write zeroing of the first 34 / last 33 sectors (protective MBR, primary/backup GPT headers, partition entry arrays). |
| Impact | T1006 | Direct Volume Access | Opens \.\PhysicalDrive0–127 with GENERIC_READ_WRITE to write raw sectors, bypassing the filesystem. |
| Impact | T1490 | Inhibit System Recovery | Deletes all restore points via SRSetRestorePointA/SRRemoveRestorePointA (no vssadmin); IOCTL_DISK_UPDATE_PROPERTIES to invalidate cached partition tables. |
| Impact | T1529 | System Shutdown/Reboot | ExitWindowsEx(EWX_SHUTDOWN|EWX_FORCE) forces reboot onto an unbootable system. |
Let’s dig deeper in this malware family!
Lotus Wiper Architecture
Based on the samples shared by Kaspersky, it can be observed that Lotus Wiper consists of three components:
- A Trigger: activated when a specific file is found on the victim’s infrastructure Domain Controller.
- Disk Content Wiper: the next stage executed by the Trigger, aimed at wiping the operating system’s content.
- Disk Structure Wipe: the final stage, which is decrypted and executed in memory.
Below, a high-level visual overview of the observed execution flow can be seen, based on samples shared by Kaspersky.
The Trigger and the Disk Content Wiper
Both the Trigger and the Disk Wipe Content component are batch scripts, with the Disk Wipe Content script being slightly obfuscated. We will analyze them to understand the connection to the PDVSA incident and the structure of the implemented disk-wiping mechanism. The SHA256 hashes for the scripts are provided below.
405177294f6f9268432a43998049ad0d4a61c6909216533b8713c911bc430755 OHSyncNow.bat
9d05854c95c6afa68911bd28af12282185e0fe34f2e58fddbc503ab22d1508d7 notesreg.bat
The “Trigger”, which is self-explanatory, is a batch script that periodically and randomly checks for the existence of OHSync.xml on the victim’s Domain Controller. The script employs variable obfuscation to confuse and delay static analysis, yet it remains straightforward in its function.
Below, we can see the first part of the script, which declares the variables needed for subsequent actions while also performing the following checks:
- It checks for the existence of the C:\lotus directory, if it does not exist, the script creates it.
- It checks for the “UI0Detect” service, aiming to disable it if found. UI0Detect (Interactive Services Detection) is a legacy Windows system service (UI0Detect.exe) designed to detect when a background service running in Session 0 attempts to display a user interface. Microsoft completely removed and disabled this service starting with Windows 10 Build 1803 and Windows Server 2019. This indicates that this part of the campaign also targets legacy environments (which often serve as entry points into OT networks).
- It checks for the existence of the NETLOGON share, assigning a boolean value to the variable K0f.
The second part of the script checks for the existence of the OHSync.xml file within the pdvsa.com\NETLOGON\lotus\ path, contingent upon the previous check. While a casual reading of the script might be somewhat confusing, this can be easily resolved by renaming the variables. If the artifact exists at the specified path, the next stage, identified as notesreg.bat, is executed.
The next stage, notesreg.bat, corresponds to the Disk Content Wiper phase; let us proceed with its analysis.
The Disk Content Wipe process begins by establishing the global variables to be used throughout its execution, including the obfuscation of those variables, following the same TTP. Shown below are the names of three .exe artifacts, as well as an .xml artifact that will serve for validation purposes.
First, the script verifies the existence of the C:\lotus directory and designates a file named lotus_out.log to record the actions performed during this stage.
If the l2f39m0.xml artifact already exists, the script assumes execution has already taken place; it then deletes all .exe artifacts and terminates. If the artifact is not found, the script creates it with the integer 1 as its sole content.
After passing the validation checks, the script enters the first phase: Phase 3.1, Account Access Removal [T1531]. You will notice that the goal of Lotus Wiper is not merely to destroy data, but to render the device inaccessible.
In this phase, random 32-character passwords are generated for local users identified during the net use loop, skipping only the PdvsaAIT account (likely used as a backdoor). Finally, all accounts are disabled using the /active:no flag.
Continuing the workflow, the script enters the Access Restriction and Session Termination phase (steps 3.2–3.4).
The script changes the CachedLogonsCount registry key to 0. This prevents users from logging in using cached credentials should the machine lose communication with the Domain Controller (which occurs in the next step).
The script also checks the Windows version. If it is newer than Windows XP/Server 2003, it uses the qwinsta command to list active sessions and the logoff command to immediately log off all logged-in users.
After restricting access to the device via user accounts, the script proceeds to implement Total Network Isolation and Data Destruction in phase 3.5.
The script severs the machine’s communication to prevent incident responses and isolate it from the network; it executes the ipconfig /release command to drop the current IP address, followed by a loop using netsh interface set interface “…” DISABLE to physically disable (at the OS level) all active network adapters.
Once the device has been rendered inaccessible, the script uses wmic logicaldisk get Caption to list all mounted drive letters, for each drive, it opens a new hidden command prompt window and injects the select volume and clean all commands into the diskpart utility.
Essentially, the clean all command instructs the disk to overwrite all its sectors with zeros, permanently destroying the partition table and data (a time-consuming process that runs in the background).
A backup of the system prerequisites is created in the local folder (C:\lotus) to preserve DLLs and utilities that will still be used during the execution of this script and the next stage.
To delete files extremely quickly and stealthily, the script employs an ingenious technique using Robocopy, using the command %SYSTEMDRIVE%\%dBl%\robocopy.exe %SYSTEMDRIVE%\ %dBl%\ H7NJ5HfOE6JkR [DESTINATION] /MIR.
The /MIR (Mirror) flag ensures the destination directory becomes an exact replica of the source. Since the source folder (H7NJ5HfOE6JkR) is empty, Robocopy silently deletes all files and folders within the destination directories.
The targets for this deletion are the Users, ProgramFiles, ProgramFiles(x86), and Documents and Settings directories. If Robocopy is unavailable, it falls back to a simple rmdir /s /q.
To thwart file recovery (file carving) tools, the script creates a 10MB temporary file.
It uses the fsutil volume diskfree command to calculate the exact number of bytes of free space on the disk. It then creates a massive new file named a11d7be1879 with a size matching the remaining free space. This effectively wipes the disk by filling the allocated space.
Finally, we reach the last phase, 3.13 the Final Sweep and Payload Execution, where the script loops through all root directories (C:\*). It applies the Robocopy (or rmdir) technique to every folder, with the exception of the malware’s own directory (C:\lotus).
Lastly, if additional executables (nstats.exe, nevent.exe, ndesign.exe) are present, it executes them.
In short, basically a huge Wipe Overkill.
The last line is interesting, as it reveals the execution flow of the next phase and provides a preview of each artifact’s function. The nstats.exe artifact is the decryptor for the final stage of Lotus Wiper; it accepts two arguments:
- The first argument is the encrypted next stage;
- The second argument is a non-malicious binary whose content will be overwritten with the decrypted code of the next stage and subsequently executed.
So, let’s move on to the analysis of the Decryptor.
The Decryptor
The Decryptor is extremely simple and straightforward, featuring just a single function. Good engineering 🙂 !
The decryptor uses native C libraries, such as fopen, fseek, fwrite, fread, malloc, etc., with the aim of being simple and straightforward. Shown below is the start of its execution, where it reads the encrypted file and allocates memory to store the encrypted data.
The sole purpose of the Decryptor is to load the encrypted data into memory, decrypt it, and write it to the target executable file (2nd argument).
Below, one can observe the completion of this process, where the encrypted data loaded into a memory buffer is decrypted using a simple XOR algorithm with a 1-byte key (0x03), with the result written to the target file.
When loading the encrypted third stage of Lotus Wiper into IDA Pro via the CyberChef plugin, it is possible to perform decryption using the XOR algorithm with the key identified during the previous analysis.
Now, let’s move on to the final part of this article: the analysis of the third stage of Lotus Wiper, the Disk Structure Wipe.
The Disk Structure Wipe
This is the final component that executes the system’s Data Structure Wipe phase, completing the Wiper’s “Overkill” routine. This component implements three independent yet complementary destruction vectors, executed in a sequence controlled by WinMain:
- Destruction of the partitioning structure for up to 128 physical disks (\\.\PhysicalDrive0 … 127) by zeroing out the first 34 and last 33 sectors of each device, a layout corresponding exactly to the protective MBR, the primary GPT header, the primary partition entry array, and the entire GPT backup set.
- Destruction of file contents across all mounted volumes, performed recursively and using multiple threads via FSCTL_SET_ZERO_DATA, followed by repeated random renaming and deletion.
- Anti-forensics measures, involving the destruction of each volume’s USN Change Journal (both before and after the file scan) and the thrashing of MFT records through successive renaming operations.
The process concludes with a forced system shutdown (ExitWindowsEx(EWX_SHUTDOWN|EWX_ FORCE)), ensuring the victim reboots on a machine with no valid partition table and no recoverable file content.
Below, you can see the main() function, which is the entry point for the entire third component. In the main function, one can observe a loop iterating through physical disks, capable of performing operations on up to 128 of them, following a basic check of the binary’s current privileges. Nothing of particular interest occurs within this privilege-checking function, so it is not worth including here. If the handle is valid, the Wiper proceeds with the data destruction process.
During each iteration of the previously identified loop, the following instructions are executed for each discovered disk, gathering its handle and other characteristics to orchestrate the destruction of the disk’s metadata (MBR and GPT). Shown below is the routine that continues the process previously described: the function receives the disk index identified in the loop and formats the string \\.\PhysicalDrive%d to access the physical disk directly, bypassing the file system. Accessing the disk with GENERIC_READ_WRITE permissions requires Administrator or SYSTEM privileges. If the handle is valid, the process proceeds to calculate the disk geometry. This explains why the initial action performed in main() is a privilege check.
The malware uses DeviceIoControl with the IOCTL_DISK_GET_DRIVE_GEOMETRY_EX code to populate the OutBuffer array.
- HIDWORD(OutBuffer[2]): Bytes 20 through 23 of the structure. This corresponds exactly to the BytesPerSector field (usually 512 or 4096 bytes).
- OutBuffer[3]: Bytes 24 through 31 of the structure. This corresponds to the DiskSize field (total disk size in bytes).
Continuing with the rest of the function below, it can be observed that the variable v5 calculates the total number of disk sectors (DiskSize / BytesPerSector).
The hexadecimal values 0x22 (34) and 0x21 (33) are not arbitrary. They specifically target the GPT (GUID Partition Table) architecture:
- The first 34 sectors (0x22) of a disk contain: Sector 0 (Protective MBR), Sector 1 (Primary GPT Header), and Sectors 2 through 33 (Partition Entries).
- The last 33 sectors (0x21) of a disk contain: The backup copy of the Partition Entries (32 sectors) and the Backup GPT Header (1 sector).
The code includes handling for extremely small disks (smaller than 34 sectors), adjusting the counters to avoid exceeding the write limit. It then calculates the exact number of bytes that need to be overwritten: v11 * BytesPerSector.
Overwriting occurs in two parts:
- The file pointer is moved to offset 0 (liDistanceToMove: 0), overwriting the first 34 sectors with zeros.
- If the first write is successful, it targets the backup. The pointer is moved to DiskSize – (33 * BytesPerSector), obliterating the secondary GPT, which makes it impossible for standard recovery tools to automatically restore the partition table.
After the recording sequence the FlushFileBuffers forces the operating system to flush the write cache directly to the physical disk, ensuring that the destruction occurs immediately.
Finally the function call DeviceIoControl again, but to IOCTL_DISK_UPDATE_PROPERTIES is the final stroke, because it forces Windows to invalidate the cached partition table and re-read the disk structure (which is now zeroed out). This typically results in an immediate operating system crash, occasionally capable of causing a Blue Screen of Death (BSOD) in critical processes that lose access to their volumes.
The function is called twice; its sole purpose is to fill all the disk space with zeros.
At this stage, a sequence of functions forms a volume-parallelized destruction pipeline featuring built-in anti-forensics across three distinct layers (content, filename metadata, and the transaction journal). The high-level workflow is illustrated below.
First, the routine determines the size of the thread pool to be used for executing actions in parallel. The speed of the destruction process will depend on the device’s available resources (CPU).
When enumerating volumes, it is important to note that the developers chose not to use APIs such as GetLogicalDrives or GetLogicalDriveStringsW, opting instead for FindFirstVolumeW and FindNextVolumeW. What is the practical impact of this implementation change? The loop will process volumes that lack drive letters; this means that recovery partitions, volumes mounted as directories (mount points), unmapped data partitions, and attached disks without assigned letters will all be affected.
In each iteration, a buffer is allocated and copied, and a thread with destructive potential is executed for every identified volume.
Within the worker function executed by each thread, we see a structure demonstrating knowledge of specific timeline recovery procedures used in incident response during disk forensics, specifically, a function responsible for clearing USN records before and after the operation. We also observe, once again, a function that adjusts the current thread’s token to ensure it possesses the necessary privileges to perform these destructive actions.
Among the calls for deleting USN records, this is the function that implements the ability to prevent file carving based on data remaining in the MFT. In the CreateFileW call, the dwFlagsAndAttributes argument contains a flag that is actually a set of flags, with destructive intent. Below are each flag that make up the final flag 0x82300000.
| 0x80000000 | FILE_FLAG_WRITE_THROUGH | Without lazy write, the destruction is persisted immediately and survives a crash or power failure during the operation. |
| 0x02000000 | FILE_FLAG_BACKUP_SEMANTICS | ACL bypass via SeBackupPrivilege/SeRestorePrivilege, opens files the user would not otherwise have permission to access. |
| 0x00200000 | FILE_FLAG_OPEN_REPARSE_POINT | Opens the link, not the target, consistent with the reparse point filter. |
| 0x00100000 | FILE_FLAG_POSIX_SEMANTICS | Case-sensitive |
Subsequently, DeviceIoControl is called with the FSCTL_SET_ZERO_DATA flag as the wIoControlCode argument and the volume handle, obtained via the earlier CreateFileW call, as the hDevice argument. Using the FSCTL_SET_ZERO_DATA flag ensures that the zeroing operation is performed by the file system driver rather than in user mode. This approach is fundamentally driven by a clear evasive intent: EDR solutions and threat hunting rules typically rely on detecting patterns of massive write operations in user mode (such as DeviceFileEvents involving high write volumes or entropy-based detection), whereas the action resulting from the implementation described above is executed by file system drivers and thus generates no signal.
To destroy the USN Change Journal, the 3th stage of Lotus Wiper executes three DeviceIoControl calls using a volume handle, opened in the \\?\Volume{GUID} format with only FILE_WRITE_ATTRIBUTES access, the minimum required level, which is insufficient to trigger detections looking for volume access with broad permissions:
- FSCTL_CREATE_USN_JOURNAL with deliberately minimal parameters (MaximumSize = 1024, AllocationDelta = 256), ensuring a valid journal exists while immediately truncating pre-existing records;
- FSCTL_QUERY_USN_JOURNAL to retrieve the 64-bit UsnJournalID, required for the next step;
- FSCTL_DELETE_USN_JOURNAL with DeleteFlags USN_DELETE_FLAG_DELETE, which completely eliminates the journal. All operations are performed via native APIs, without fsutil.exe or child processes, thereby evading command-line-based detection rules.
This functionality is enhanced by the routine’s placement, each volume thread invokes it twice, once before the wipe and once after, as previously noted. The first pass erases the file system’s legitimate history, while the second deletes the hundreds of thousands of rename and delete entries generated by the destructive activity itself. This renders impossible the timeline reconstruction that forms the basis of NTFS forensic analysis, leaving behind only a recreated journal with a MaximumSize of 1024 bytes (highly anomalous compared to the standard size of tens of megabytes, verifiable via fsutil usn queryjournal) and a recent UsnJournalID with FirstUsn and NextUsn values close to zero.
Finally, prior to the forced system reboot, as seen in the body of the main() function, a function executes that seals the chain with an additional anti-recovery measure: the deletion of all system restore points. It accomplishes this far more elegantly than by using binaries such as vssadmin.exe and its derivatives.
Windows restore point sequence numbers are monotonically increasing integers starting at 1. When creating a new point using SRSetRestorePointA, it’s automatically obtains the system’s highest sequence number, which, by definition, represents the upper bound of all existing points. It then iterates backwards from N down to 1, calling SRRemoveRestorePointA to delete every restore point, including the one it just created.
It is enumeration without explicitly enumerating. It requires no WMI (SystemRestore class), no parsing of C:\System Volume Information\SPP\, and no listing APIs. It simply creates a point, reads the index, and counts backwards.
Conclusion
It is relatively rare to encounter new families of wiper malware, and whenever we do, the context is invariably rife with geopolitical disputes. This is due to the very nature of wiper malware: it destroys data without any financial motive, aiming solely to cause destructive impact. Historically, such malware has typically been employed in cyberattacks supporting military operations, such as instances where Iranian and Russian APT groups targeted military and political entities of interest to their respective states.
In this instance, we observe a multi-stage wiper featuring a trigger mechanism highly tailored to the PDVSA environment, followed by an aggressive wiping phase comprising two stages that execute both disk content wiping and disk structure wiping. We also see how these actors developed not only the wiper stages themselves but also a simple yet effective loader; this component decrypts the third stage and injects its payload into a benign binary to evade static detection.