This article was published on the 10th of November 2021.
Anubis and Cerberus are the first to families to be added to the framework. This article will provide in-depth information on the C2 communication of these two families, and what behaviour was excluded from their implementation in m3.
Table of contents
Introduction
The implementation of these families was not at random. Aside from having code available to look at, the families are currently active. To give insight into the activity of these families, I contacted ThreatFabric and Avast. Both were kind enough to provide data related to the amount of unique samples that were observed in 2020 and the first half of 2021.
Several notes have to be made on the sample count and the related companies. Firstly, this is not meant as a comparison between these companies in any way. Secondly, the amount of unique samples that have been observed is not the most accurate metric. It does not provide insight into the effectiveness of one or more of these families, nor does it provide insight into the amount and sizes of the campaigns within the sample set. The only purpose of these metrics here, is to showcase the activity of these families in the wild.
Anubis
Both Avast and ThreatFabric saw roughly 14,000 unique Anubis samples in 2020, where the amount of samples is roughly evenly spread across all four quarters of 2020. The first half of 2021, ThreatFabric observed roughly 8,000 unique bots, compared to 2,000 from Avast’s point of view. This shows that the activity of the bot, despite being several years old, is roughly stable, making it a useful family to embed within the emulator framework.
Cerberus
When talking about Cerberus, the story gets a bit more complex. Its source code was first offered for sale, as Since the source code has been leaked, as can be read in a report by the BleepingComputer on the 27th of July 2020. The source code then leaked, which lead to the inevitable to happen: forks of the bot were created. In September 2020, ThreadFabric wrote about Alien, followed by another Cerberus fork dubbed ERMAC, covered in September 2021.
The figures from Avast do not differentiate between Cerberus and its forks, whereas the numbers from ThreatFabric do. In 2020, Avast saw roughly 22,000 unique samples of Cerberus and its derivatives, unlike the nearly 5,400 unique Cerberus samples that ThreatFabric saw. In the first half of 2021, Avast saw roughly 13,500 samples of Cerberus or its forks, compared to the 3,600 Cerberus samples that ThreatFabric saw. The difference here is likely due to the activity of the Alien family.
Over the past year and a half year, the Cerberus family and its derivatives have shown continuous activity. This makes Cerberus a suitable second family to be included in the first release. The forks can be added based on Cerberus’ implementation in m3 if one wishes to do so.
C2 communication patterns
Some notes on the the communication with the C2 from both families, as there is some overlap, but there are certainly some major differences as well. Firstly, both families solemnly use HTTP POST requests to interact with the C2 server. Additionally, both families use RC-4 encryption. To aid in the RC-4 encryption, both families use several helper functions, which are the same for both families.
A notable difference is the fact that Anubis sends requests to different endpoints on the C2, depending on what it is doing. Cerberus, however, uses a single endpoint to send all requests to. Depending on the command in the body of the POST request, the request is handled differently.
Both families handle internal commands rather differently, although that might not be clear from the implementations in m3. The main reason for this, is that the structure has been simplified to more easily fit into m3’s format. Android specific parts have been removed, as they serve no purpose within the emulation framework, meaning only the data related operations remain.
Excluded behaviour
Behaviour that has been excluded from the implemented families can be brought down to four sections: sending fake personal identifying information, uploading files, generating fake keystrokes, and a (fake) SOCKS proxy instance. The reason for this, is the difficulty in creating fake data that does not impact anyone at random, not even by chance. As such, these methods have not been included. Whenever possible, skeleton code is possible for those who find a way to safely implement these features.
Conclusion
The implementation of two families within m3 should provide quite some sample code that can be used to add more families to the framework. Additionally, one can use m3 to emulate bots for these families, meaning that that the framework is ready to be used and extended from the moment it is released!
To contact me, you can e-mail me at [info][at][maxkersten][dot][nl], send me a PM on Reddit, or DM me on Twitter @Libranalysis.