Splunk Inc.

07/25/2024 | News release | Distributed by Public on 07/25/2024 10:05

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.

Devices Common Products Short Description
/dev/sd* Hard disk drives (HDDs), solid-state drives (SSDs), external USB drives, and network-attached storage (NAS) This represents block devices on Linux systems, typically corresponding to SCSI (or SATA) drives.
/dev/mtd*
/dev/mtdblock*
/dev/block/mtdblock* 		Embedded systems, routers, set-top boxes, and some types of industrial and automotive electronics. These are block devices that represent Memory Technology Devices (MTD) on Linux systems. MTD devices are used for accessing flash memory such as NAND or NOR flash chips.
/dev/mmcblk*
/dev/block/mmcblk* 		Smartphones, tablets, digital cameras, and other portable electronic devices. These are block devices representing MMC (MultiMediaCard) storage devices on Linux systems. MMC devices are commonly used in portable electronic devices such as smartphones, tablets and cameras.
/dev/loop* Virtual disk images, disk encryption applications (e.g., LUKS), software development environments (for testing disk images), and live CD/DVD distributions. This represents loopback devices on Linux systems. These devices allow for mounting of regular files as block devices.
/dev/dm-* Logical Volume Manager (LVM) setups, encrypted volumes (e.g., using LUKS/dm-crypt), and advanced storage solutions such as RAID configurations and storage virtualization. This represents device mapper devices on Linux systems. Each /dev/dm-* device represents a specific mapping or transformation applied to the underlying physical block devices. These mappings can be configured using tools like LVM (Logical Volume Manager) or dmsetup.
/dev/Ubi* Embedded systems, industrial equipment (e.g., PLC, routers and some network switches), and specialized flash-based storage devices, particularly those requiring wear-leveling and error management for NAND flash memory (e.g., Raspberry Pi). This represents UBI (Unsorted Block Images) devices, which are used to manage NAND flash memory in embedded systems.

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.

Detection Name Description
Linux High Frequency Of File Deletion In Boot Folder This analytic is designed to detect a high frequency of file deletion relative to process name and process id /boot/ folder. These events were seen in AcidPour wiper malware where it tries to delete all files in a critical Linux directory.
Linux Deletion Of Cron Jobs This analytic is designed to detect a deletion of cron jobs in a Linux machine. This technique can be related to an attacker, threat actor or malware to disable scheduled cron jobs that might be related to security or to evade some detections.
Linux Deletion of Init Daemon Script This analytic is designed to detect a deletion of init daemon script in a Linux machine. Daemon script that is placed in /etc/init.d/ is a directory that can start and stop some daemon services in Linux machines. An attacker may delete or modify daemon script to impair some security features or act as defense evasion in a compromised Linux machine.
Linux Deletion of SSL Certificate This analytic is designed to detect the deletion of SSL certificates in a Linux machine. Attackers may delete or modify SSL certificates to impair some security features or act as defense evasion in a compromised Linux machine.
Linux Deletion of Services This analytic is designed to detect a deletion of services in a Linux machine. Attackers may delete or modify services to impair some security features or act as defense evasion in a compromised Linux machine.

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