AcidPour Wiper Malware: Threat Analysis and Detections

In recent years, several destructive malware variants have emerged in the wild, often used in geopolitical attacks to cripple compromised hosts or network systems. In March 2024, SentinelOne discovered a new variant of the AcidRain wiper malware, featuring updated capabilities and attack vectors. This variant, named AcidPour, was designed to irreversibly delete data from targeted systems, rendering them inoperable.

Unlike typical ransomware, AcidPour focuses on data destruction rather than financial gain. It targets critical sectors of Linux devices like SCSI SATA, Memory Technology Devices (MTD), MultiMediaCard Storage, DMSETUP and Unsorted Block Image devices, overwriting files to make recovery nearly impossible. Often deployed in coordinated cyberattacks, this destructive malware can pose a serious risk to data for both organizations and individuals. Understanding its behavior and impact is crucial for developing effective detection and mitigation strategies against this destructive wiper.

In this blog, the Splunk Threat Research Team provides an analysis of AcidPour, including related tactics and techniques, as well as how you can use Splunk’s out-of-the-box security content to help defend against this wiper malware.

Tactics and Techniques

Defense Evasion

Indicator Removal: Self Wiper (T1070.004)

Unlike AcidRain, AcidPour has a defense evasion technique where it overwrites itself with a generated sequence of bytes from 0-255 followed by a command line message “Ok”. This technique serves as a defense evasion for analysts and malware researchers.

^{Figure 01: Overwrite itself}

Then it will create a fork()/new/child process that will be set as the session leader by calling the setsid() api. Afterwards, it will open the “/dev/null” file with the “WRITE_ONLY” flag.

In the event of a failed attempt to open '/dev/null', the program takes a proactive step by closing three standard file descriptors: 'stdin', 'stdout', and 'stderr'. This precautionary measure ensures that no unintended input/output operations occur on these descriptors. Conversely, if the program successfully opens '/dev/null', it proceeds to redirect the aforementioned three standard file descriptors to '/dev/null' for streamlined processing.

^{Figure 02: Closing three standard file descriptors}

Time Based Evasion (T1497.003)

Another interesting technique we observed in AcidPour is the use of select() function to sleep its code. AcidPour has two possible arguments that will be used for computing the timeout parameter, which specifies the maximum amount of time (in seconds) that select() should wait for events before returning.

^{Figure 03: Time-based evasion technique}

Below, you can see an example of AcidPour strace logs without parameters. It will automatically timeout for 613 seconds 10+ minutes).

^{Figure 04: Time-based evasion strace logs}

In Figure 05 below, the parameter '35' is passed to AcidPour's strace job that serves as the timeout value for the select() function. This causes the program to pause for 35 seconds, effectively acting as a sleep command.

^{Figure 05: Time-based evasion strace logs}

Impact

Data Destruction (T1485)

As part of its destructive payload, the malware systematically wipes, overwrites, and deletes multiple directories. It specifically targets critical directories such as “/boot”, which are essential for rebooting the compromised Linux machine. The files within these targeted directories are overwritten with 32KB of randomly generated bytes, making recovery nearly impossible.

^{Figure 06: Destroy files in boot directory}

^{Figure 07: Destroy more files}

Unlike AcidRain, AcidPour targets a broader range of device node paths for wiping out. Below is a table listing devices it attempts to erase or overwrite.

AcidPour employs two distinct methods to delete files, contingent upon the device path it targets.

One of these techniques involves the file block overwrite approach. With this method, the wiper systematically overwrites files located on the specified device paths with randomly generated 256KB (0x40000) buffers, repeating the process multiple times.

^{Figure 08: File block overwrite approach}

The other technique employed by AcidPour is similar to AcidRain’s method of using system Input/Output Control (IOCTL) commands to carry out its destructive actions. Specifically, it uses the following IOCTL commands:

• memgetinfo: This command retrieves information about memory regions, such as their size and attributes.
• memunlock: This command unlocks a memory region, allowing it to be accessed or modified.
• memerase: This command erases the contents of a memory region, effectively wiping out any data stored within it.
• memwriteoob: This command writes data out of bounds (OOB) of a memory region, potentially causing corruption or unintended behavior.

^{Figure 09: Wipe data via IOCTL command}

System Shutdown/Reboot (T1529)After wiping and deleting files, the compromised host or system will reboot, rendering it unbootable as all critical files have been wiped and deleted.

^{Figure 10: System shutdown/reboot}

While there are similarities between AcidPour and AcidRain or VPNFilter's 'dstr' module in terms of file wiping capabilities, VPNFilter (originally discovered by Cisco Talos) includes additional features for data exfiltration and code injection, while AcidPour is purely designed to destroy or cause damage to compromised host or production networks.

Detecting AcidPour with Splunk Security ContentBy understanding AcidPour behaviors, the Splunk Threat Research Team was able to group existing detections with generated telemetry and datasets designed to help defend against and respond to this threat. You can find these detections below, and for our full repository of security detections, visit research.splunk.com. 

Learn More

This blog helps security analysts, blue teamers and Splunk customers identify AcidPour malware by enabling the community to discover related TTPs used by threat actors and adversaries. You can implement the detections in this blog in Splunk Enterprise Security using the Enterprise Security Content Update app or the Splunk Security Essentials app. To view the Splunk Threat Research Team's complete security content repository, visit research.splunk.com.

Feedback

Any feedback or requests? Feel free to put in an issue on Github and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.

Contributors

We would like to thank Teoderick Contreras for authoring this post and the entire Splunk Threat Research Team for their contributions: Michael Haag, Lou Stella, Bhavin Patel, Rod Soto, Eric McGinnis, Jose Hernandez , Patrick Bareiss and Gowthamaraj Rajendran.

References

• https://serhack.me/articles/understanding-ubi-file-system-embedded-devices-reolink/
• http://www.linux-mtd.infradead.org/faq/ubifs.html
• http://www.linux-mtd.infradead.org/faq/ubi.html
• https://forum.openwrt.org/t/copy-original-firmware-dev-mtd-for-restore/172916
• https://stackoverflow.com/questions/18097549/how-to-open-android-phone-internal-memory-mmcblk0-in-read-mode-using-open
• https://askubuntu.com/questions/599044/luks-and-loop-device
• https://superuser.com/questions/131519/what-is-this-dm-0-device
• https://docs.kernel.org/admin-guide/device-mapper/dm-raid.html
• https://stackoverflow.com/questions/55117708/ubi-layout-volume-not-found