Zombieware: Malware That Never Dies...

At UnpacMe, we have observed an ongoing trend where new submissions contain legacy malware. This has created challenges as we hunt for new samples and analyze trends. After some internal discussion and analysis of our data sources, we decided to create a new classification to track these samples: Zombieware. This new classification makes it easier to cluster samples, and can be used to quickly identify and ignore Zombieware labelled files when investigating emerging threats.

Identifying a Zombie

We define Zombieware as malware that meets two criteria: it has been abandoned by its operators, and despite being abandoned, new replications of the malware continue to appear in the wild. Zombieware samples are often self-replicating types of malware, such as file infectors and worms, but the classification is not limited to these types of malware. In many cases, automated analysis processes are the source of file replication, such as files dumped from sandboxes.

Though these samples lack operator control and intent, and their distribution is incidental and not driven by coordinated campaigns, some Zombieware may still pose a threat, particularly in the case of zombie ransomware. The Zombieware classification denotes the lack of intent behind the malware, not the threat level, and Zombieware should not be ignored. However, given that these samples are neither actively distributed nor controlled by an operator, they generally hold low intelligence value. Proper classification of these samples allows teams to allocate their resources more effectively, focusing on analyzing and hunting active threats.

A notable example of Zombieware is AlApple, a DDoS worm first observed in 2006, designed to target an Estonian insurance company and ISP with DDoS attacks. The creator of this malware was found guilty and incarcerated in 2010. Despite being nearly 20 years old, we continue to see hundreds of AlApple samples, underscoring the persistent nature of such malware.

Impact – Twice The Bite

The main impact of Zombieware is wasted time and bandwidth, both empty CPU cycles processing dead samples, and analyst time spent running down samples that have long since been inactive. It effectively adds rusty needles to the already complex task of identifying relevant threats within an ever-growing haystack.

Depending on your role – whether in Incident Response (IR), Cyber Threat Intelligence (CTI), security operations, or threat research – the way you utilize IOC and sample feeds may vary, but noise from Zombieware is a common drain on resources across all roles.

Trending Misattribution

For CTI analysts and researchers Zombieware can also greatly affect trend analysis. When a malware sample becomes infected and subsequently generates copies of itself, it can artificially inflate the perceived prevalence of the original malware sample. This can cause the appearance of a spike in activity where none actually exists.

An example of Zombieware creating an artificial spike in activity occurred last year in early 2023 when a polymorphic worm was misattributed as a targeted espionage tool dubbed SoulSearcher. Within a few days over half a million new variants of the worm had been tagged with SoulSearcher as sandboxes executed the polymorphic worm and uploaded the resulting copies of the malware to public malware repositories.

Training on Zombies

Secondary issues also emerge when researchers unknowingly use sample sets that include Zombieware for model training and automated YARA rule generation. It is not uncommon for a single Zombieware sample to be infected by multiple file infectors, and sometimes the same infector, multiple times. These files can skew classification and distort results, leading to inaccuracies.

Many file infectors will simply replace the existing executable code and append the old code to the PE file as an overlay or an additional section. When attempting static classification, or automated YARA generation, the classifier may be asserting on string sequences within the original appended data. However, once the file is executed the file infector code is run leading to inconsistent results and inaccurate baselines.

An example of this Zombieware phenomenon where multiple malware families inhabit the same file is demonstrated by this AsyncRAT sample that has been infected with the Neshta file infector.

Where Are They Coming From?

As previously mentioned, many Zombieware samples can be traced back to dynamic analysis systems that produce modified versions of the sample under analysis. This is especially true for worms and file infectors, which tend to generate additional infected files during analysis.

Machines Feeding Machines

This issue can be particularly pronounced when samples harvested from a sandbox are then uploaded to public malware repositories where they are then downloaded and executed in another sandbox restarting the cycle. This process can lead to what is effectively a 'sandbox centipede' of samples, continuously multiplying as they are passed between sandboxes and creating an ever growing volume of Zombieware.

A surface level view of these high sample numbers might appear impressive – we processed over a million samples this month – but on closer inspection these figures often have little actual value. Moreover, for the reasons previously discussed, these high sample volumes may in fact be slowing down technical and analytical processes while increasing required storage and analysis costs. In these cases identifying samples that have been infected within a file infector and short circuiting reanalysis is highly recommended.

Natural Propagation

Dynamic analysis is not the only source of these samples. According to a recent presentation by Ladislav Zezula at BSides Prague 2024, a significant number of infected systems are likely located in developing regions, where a high number of users continue to run legacy operating systems without modern protections. Since many malware families classified as Zombieware were developed over a decade ago, they often target legacy peer-to-peer (P2P) clients and employ lures for obsolete software, such as 'Windows XP Full Downloader.exe' further limiting their distribution.

Legacy Malware vs. Zombieware

Part of our criteria for classifying a family as Zombieware is that it is no longer actively distributed and operated. This can make it difficult to classify some legacy families that are being repurposed by threat actors.

A recent example of this is the Blackmoon (KRBanker) that was first discovered a decade ago in 2014. Although many of the samples are almost certainly legacy samples, late last year it was reported that Blackmoon was repurposed and targeting companies in the USA and Canada. Although the majority of Blackmoon malware samples are unlikely to be actively distributed, reports of the malware being actively repurposed suggest it does not fit the Zombieware classification.

Another example is Sality, first discovered in 2003. Despite being over 20 years old, there are indications that the operator continues to maintain control and update the malware. In cases such as these, where there is uncertainty about the active nature of the malware, we adopt a conservative approach and maintain a non-Zombieware classification.

How We Handle Zombieware

Our initial approach to Zombieware was to pre-filter these samples on our collection systems to minimize noise during sample processing. However, in practice, this quickly revealed two significant issues:

• Although these samples are not actively distributed, there are scenarios where they could inadvertently be introduced into an environment. For instance, USBs used to update systems in an OT network, which often operate on legacy software and may lack controls.
• There are too many variants to accurately filter samples with a high level of confidence. As a result, we risk mistakenly filtering out samples that are truly active or misidentified.

To address these challenges, we decided to create the 'Zombieware' classification for families that meet our criteria. This classification allows us to modify how we process Zombieware tagged samples. We can still provide relevant IOCs and files while minimizing the impact and noise to analysts and researchers. The following table highlights the differences in processing between Zombieware classified samples and those classified as malicious or unknown.

The table above outlines how Zombieware samples are processed compared to other categories of malware and unclassified samples. The primary distinction for Zombieware is limited enrichment — these samples undergo partial processing in our enrichment pipeline and are not included in our SourceIntel collection efforts, which gather additional data from command-and-control (C2) infrastructure. Additionally, Zombieware samples are excluded from the Yara Live Hunt.

Users can still hunt Zombieware samples using TotalRecall and Search, with most search prefixes available for Zombieware samples. Zombieware samples are included in both our file and IOC feeds. However, they are tagged so users can better control how they are processed on their side.

We have found this to be a good balance between reducing noise and getting live malware to analysts, while continuing to provide IOCs and samples to users who need them.

Conclusion

In conclusion, Zombieware primarily impacts organizations by consuming time and wasting valuable resources. One notable source of Zombieware is systems performing dynamic analysis, which often inadvertently feed Zombieware output into file and malware feeds. To mitigate this, we recommend implementing additional checks to limit the generation of new copies of these files.

We believe in many cases that these samples can be deprioritized for analysis and with better labelling we can empower analysts to focus more effectively on analyzing active and new emerging threats.

Happy Hunting!