Pouring Acid Rain

By Max Kersten · April 30, 2024

In two recent major geopolitical conflicts, in Ukraine and in Israel, wipers - malware used to destroy access to files and commonly used to halt telecom operations - were used to destroy digital infrastructure. Their ongoing shows that wipers have their place in a nation’s cyber arsenal, are here to stay and not a one-off tactic. Reports on the latest wipers have been making the rounds from SentinelOne regarding AcidRain and AcidPour, as well as Ruben Santamarta’s confirmation of the impact of AcidRain on Viasat KA-SAT devices.

While AcidRain predates AcidPour by more than two years, the two wipers look alike in more than just their behavior. This blog will provide background information on wipers in general, explain the inner workings of both Acid wipers, compare the capabilities of both wipers, and discuss potential attribution

Background information

The date on which the AcidRain attack occurred coincides with the start of kinetic activities in the Russo-Ukrainian conflict, where wipers were likely used to gain a battlefield advantage by disrupting satellite communications, bricking the aforementioned Viasat KA-SAT modems. These satellite-based modems allow one to move around while maintaining an internet connection, regardless of the presence (and/or condition) of cell phone towers.

The trend of using wipers within international conflicts is not new, with ample examples going back years. In 2017, we saw both WannaCry and NotPetya, wipers disguised as ransomware with no intention to be used as such, target Ukraine. Going back to 2012, the Shamoon wiper wreaked havoc on Saudi Arabia’s Aramco.

Notable for all three wipers is the ability to spread, where the malware infected other systems in the network. WannaCry and NotPetya used the EternalBlue exploit, which originated from the Vault7 leak, allowing them to spread like wildfire on networks with unpatched machines. Shamoon copied itself to other machines and shares where possible, confining the spreading within the targeted network, rather than impacting companies on a global scale.

Looking back at more recent history, wiper usage has increased, especially when linked to activism and armed conflicts. In early 2022, there was an uptick of wipers used on targets within Ukraine. As noted in our Wipermania blog from November 2022, the WhisperGate and Hermetic wipers focused on that area as well, albeit prior to AcidRain. Post AcidRain, there were numerous wipers that followed: IsaacWiper, CaddyWiper I, DoubleZero, Industroyer2, Shred wipers,CaddyWiper II, RansomBoggs, SwiftSlicer, CaddyWiper III, ZeroWipe, and BidSwipe.

These wipers, written in a multitude of programming languages with different styles and targets, indicate the loss of data and loss of system uptime is a target during conflicts, even if that were to mean covert access would be burned by destroying the targeted systems.

Even more recently, wipers have been used several times in Israel, since the 7th of October 2023, which marked the start of Israel’s military extensive response to Hamas. In late October 2023, Security Joes and ESET discovered two versions of the BiBi wiper (the name is a reference to Israel’s prime minister Benjamin Netanyahu), after which the MultiLayer, PartialWasher, and BFG Agonizer wipers were discovered by Palo Alto Networks’ Unit42, also targeting Israel. In February 2024, Intezer’s Nicole Fishbein discoveredthe SameCoin wiper, about which HarfangLab published an extensive analysis.

Note that the lack of wiper malware which aims to target devices within Gaza is likely due to prioritization. Once a conflict becomes fully kinetic, defending IT infrastructure against wipers becomes of secondary importance. From the other perspective, destroying cell towers and similar infrastructure causes downtime in communication on the battlefield without the need for malware. Alternatively, disconnecting an area from the internet and/or electricity results in the same, albeit in a reversible manner.

AcidRain

AcidRain was first submitted to VirusTotal on the 15th of March 2022, after which numerous AV, EDR, and XDR suites detected it, including Trellix’ products.

To avoid repeating existing research, a high level overview of the AcidRain follows, along with some interesting decompiled code excerpts to illustrate the most important points. Below, the wiper’s flowchart is given, highlighting the taken steps.

While some of the steps require no further explanation, such as the print statement at the beginning, it is clear that the wiping process within the wiper requires more details. The check to see if the process is running with root privilege, along with the subsequent call to wipe non-system directories, is shown below.

The “getuid” (short for “get user ID”) call returns the real user ID of the calling process, which is the wiper. If this is not equal to 0, which is generally the root user’s ID, it calls the wipe function.

Directly after that, the execution continues by calling several functions in a row, each of which has different targets to wipe. If the current user is the root user, the non-system directories (and files therein) are then deleted. This is the same function as the one mentioned above, indicating that the deletion of these directories is certain, but the moment depends on the user which executes the binary.

The affected directories are listed in the table below, along with a brief description of the directory’s purpose.

Once the wiping is complete, the device is rebooted.

AcidPour

AcidPour was first submitted to VirusTotal on the 16th of March 2024, after which numerous AV, EDR, and XDR suites detected it, including Trellix’ products. Much like AcidRain’s section, this section will provide a high level overview of the AcidPour wiper, along with some examples and interesting tidbits. The flowchart below showcases the wiper’s execution flow.

One of the new capabilities is the wiper’s ability to overwrite itself. Usually, self deletion of malware is done to avoid the sample being found during the incident response and subsequently being analyzed. On Linux based systems, files which are in-use can be overwritten, contrary to Windows. In the image below, the link to “/proc/self/exe” is read, which links to the binary of the current executable.

It then obtains a file descriptor to said binary, as can be seen on line 40 in the image below. It then creates a buffer, where each entry into the array is an increment of the previous value, with 1023 being the highest value. This buffer is then iteratively written over the original binary.

The second addition to the wiper is the delay prior to the start of the wiping. The duration, in seconds, of this delay can be specified via the first command-line interface argument. If no such argument is provided, a delay of 613 seconds is applied. The image below shows the relevant decompiled code from the wiper.

The third addition is the recursive wiping of “/boot”. The decompiled code at line 24 in the image below contains the call to read the given directory’s content. Lines 52 and 55 contain checks with regards to the specific path. If it is a regular file (“DT_REG”) or a symbolic link (“DT_LNK”), the file is wiped. If it is a directory (“DT_DIR”), the recursive wipe function is called with the newly discovered directory as its argument, thus traversing all directories within each directory, starting at the provided directory. At last, the directory is removed once it is empty. Lastly, the unlink function is called to remove the specific file. Note that “buffer” is a copy of the provided input path, which is copied prior to the code shown in the figure.

Much like AcidRain, AcidPour wipes devices. Aside from the affected directories mentioned at AcidRain, two more directories, explained below, have been added.

The device is rebooted once the wiping activity completes.

Code comparison

When overlapping the flowcharts of AcidRain and AcidPour, as can be seen in the image below, a striking resemblance in the heuristics of both wipers can be observed. Heuristic similarity does not necessarily result in re-use and/or overlap of code, and even if that were to be the case, the overlap could come from benign libraries.

Library code

The two wipers both use code which exists in uClibc. The uClibc-ng (next generation) library is built on uClibc, and thus overlaps. The goal here is not to dive into the difference between these two libraries, but rather that the Acid-wipers used either of these libraries, which explains some of the used code constructs, such as the forking, creation of a new session, and the redirection of the program’s standard in- and outputs. These are all part of the library’s code within the daemon function. The image below shows the uClibc source code, and the decompiled code from the AcidRain and AcidWiper respectively in a side-by-side comparison. Note that due to compiler optimization, the daemon function’s content is inlined within the caller, which is the main function within each Acid-wiper.

Another example is the sleep function, called in AcidPour’s main function, which uses select to monitor non-existing (NULL) file descriptors, and thus wait for a given period of time. Other researchers have noted that this technique is uncommon. And while it is indeed uncommon, the uClibc library uses this exact code on non-BSD, non-POXIS98, and non-realtime builds. The image below shows the uClibc sleep function’s source code and relevant decompiled AcidPour code respectively.

Note that the microseconds (“tv_usec”) field is not used in the decompiled code, and the value passed to the function is in seconds, rather than microseconds. This could be done with the help of constant folding and propagation, a compiler optimisation technique where the actual value of variables is precalculated, leaving the compiler to only output the optimized code. As such, the program’s execution is not slowed down by redundant calculations without impacting the code’s behavior.

Aside from the source code overlap, several FunctionID libraries from Mich on GitHub match with functions within the Acid-wipers, as can be seen in the strncpy excerpt below. The GitHub page shows the inclusion of uClibc binaries for a variety of architectures.

Wiper related code overlap

Recognizing the library code makes the analysis easier, and provides a link between two files, but said link is not conclusive. The overlap in heuristics, when removing the uClibc aspects, is best shown in a flowchart, as can be seen below.

The first aspect which is characterizing the Acid-wipers, is the data that is used to overwrite files with. The AcidRain wiper uses a buffer with descending values, whereas AcidPour uses ascending values. The buffer size in both wipers is 256 kilobytes (0x40000 bytes), the initialization for both can be seen below. Note that the self overwrite function in AcidPour also uses an ascending buffer, as described before.

The main functions of both wipers also look similar, but due to their brevity and rather simple nature, it is difficult to draw meaningful conclusions from them. A section of the code in both functions is related to the inlining of uClibc’s daemon function. Other than that, the printing of a message, the call to several functions to wipe directories, and the call to reboot the device, can easily be recreated without source code access, especially when using the same library code.

However, the wiping methods which are called, do share sufficient logic to state that the author of AcidPour either had access to AcidRain’s source code, or that the author simply recreated AcidRain’s logic. The input/output control (IOCTL) wiping method (which SentinelOne noted overlapped with the third stage ‘dstr’ wiper, part of the VPNFilter malware family) employs a similar wiping method but does differ when looked at in more detail. Note that VPNFilter’s ‘dstr’ also uses uClibc.

The OpenWRT project, a Linux operating system for embedded devices, contains code to erase Memory Technology Devices (MTDs), using mtd_info_user and erase_info_user structures. The specific wipe functions within AcidRain, AcidPour, and VPNFilter’s ‘dstr’ all use these structures in a similar manner, as can be seen in the respective side-by-side comparison in the image below.

The used IOCTL calls return these structures in the output argument, meaning that the usage of these structures does not necessarily indicate code overlap with one another, nor with the OpenWRT codebase.

The two Acid wipers have an identical way of wiping code, using the same logic and loops internally. As such, it is likely that the Acid wipers are based on the same codebase, or made by someone with the intention to copy AcidRain when writing AcidPour. The VPNFilter stage uses different logic, indicating that the used source code is likely different, or an older version, compared to AcidRain.

The other wiper related functions show similar overlap, but not all of them are as ‘picturesque’ as the example taken, making their explanation a tedious process. The above serves as an illustration of reused code within the Acid wipers.

Conclusion

There is no conclusive evidence to state that the Acid wipers are based on the same source code, but given the same dependencies, as well as the similar looking code, we state with medium confidence that AcidPour uses AcidRain’s source code as a basis. The modifications allow the wiper to be used in a more versatile manner, as the possible number of systems that it could affect greatly increased.

While the Acid-wipers have been targeting Ukrainian-based entities, we do not attribute it to a specific group. Based on the targeted geographic area, and the critical sectors of publicly reported victims, we attribute these attacks to a pro-Russian actor.

Code overlap comparisons rarely lead to definitive conclusions, given that it is possible to recreate malware based on reversing efforts. The fact that one would have to put in a lot of effort to do so, does not make it impossible, merely unlikely. The (alleged) likeliness can be utilized by an attacker, be it to shroud themselves in smoke and mirrors and throw researchers off their course, or to ensure analysts jump to premature conclusions.