Introduction
In our ongoing exploration of the enigmatic BumbleBee malware, we’ve previously dissected its delivery techniques , unraveled its malicious behavior , and delved into the ever-evolving nature of its evasion techniques.
Now, in this latest installment, we uncover the secrets hidden within the BumbleBee’s malware configuration, shedding light on the methods it employs to safeguard its operations. Moreover, we’ll take a comprehensive look into the clusters, where we’ll connect the dots between different BumbleBee samples and missions.
Join us as we explore BumbleBee’s operations, revealing the hidden patterns that drive this malware’s malicious activities.
BumbleBee Blog Series – 3
DOWNLOAD THE E-BOOK
Config Extractor
We have identified a number of differences between BumbleBee samples in terms of functionality but also how the config is processed. While some samples use no encryption at all, some use the RC4 algorithm to encrypt the configuration data.
To determine the encryption algorithm, we first had to locate the encrypted data as well as where it is further processed which allowed us to locate one function that looked promising. There are usually a few methods to identify which encryption algorithm a function implements. First, one can try to find magic constants strongly associated with certain encryption algorithms. For example, AES uses a so-called S-box filled with fixed constants to perform substitutions. These constants can easily be used to identify the algorithm. In BumbleBee’s case, no such unique constants could be found. However, one commonly used encryption algorithm by malware, RC4, incidentally also contains no unique constants, making this a likely candidate.
In addition to the approach involving constants, another method is to compare the decompiled function to a list of known encryption algorithms, which in our case showed striking similarities to RC4 (see Figure 1).
Finally, one can confirm the findings by decrypting the encrypted content via RC4 (using the extracted key) and investigating the output, e.g., via CyberChef or similar tools. While this confirmed our findings in this case, this method is of limited value if the malware authors decide to manipulate the encryption algorithm.
Investigating the decrypted configuration, we determined that BumbleBee generally has these configuration fields that we can export (see Figure 2):
An RC4 key, if the config is encrypted
A mission ID which can be freely set by the attacker, e.g., to distinguish different operations
A list of C2 addresses, some of which are decoy addresses
An “Identifier” often set to either 444 or 443, the main purpose of which is still undetermined – there is evidence that this is the port used to filter out the decoy addresses
Read the Ebook: Malware Configurations
Clustering
Based on this information, we tried to identify different samples and missions likely belonging to the same threat actors. For this purpose, we have randomly collected about a hundred BumbleBee samples that were seen for the first time in the wild from March to May 2023, extracted their configuration and plotted the relationship between them in clusters. While some of the samples seemed to be unique, i.e., they had a key and mission ID which were not shared with other samples, most samples had crossovers and shared mostly the same configuration.
During this analysis, we noticed that most samples belong to the same mission (“mc1905”), and even more use the same encryption key. Connected to this cluster are two other missions, “inst” and “mc1904” (see Figure 3). As all three missions share the same encryption key, we believe the same threat actor could be behind all of these samples.
Furthermore, in Figure 4 we have plotted the samples that are unique or decoupled from the biggest cluster. Here, we have identified the missions “mvtm1703” and “0211r” to also likely stem from the same threat actor.
This data reveals that in these three months, likely only one threat actor was dominating the space as most samples used the same encryption key (over 90% of the samples we looked at).
With API access to the VMRay Platform, the extraction of the config can be automatized to allow this kind of clustering and to follow threat actors over some period of time (see here ).
Conclusion
Deep dives into malware families, as demonstrated in this blog post, help us to find better detection methods, proactively add VTI’s to trigger on new malicious behavior and protect our customers before a dangerous malware becomes a threat.
This blog post also demonstrates how half a hundred evasion techniques are not enough to evade our dynamic, behavior-based analysis engine. Rather, we weaponize these efforts against the malware by trying to detect these attempts and revealing the malicious intent. As threat actors are always on the lookout for new methods to deliver their malware, regular updates of the VMRay Platform allow us to always be on track when it comes to new techniques.
References
https://research.checkpoint.com/2022/bumblebee-increasing-its-capacity-and-evolving-its-ttps
https://www.cloudsek.com/blog/technical-analysis-of-bumblebee-malware-loader
https://elis531989.medium.com/the-chronicles-of-bumblebee-the-hook-the-bee-and-the-trickbot-connection-686379311056
IOCs
Hashes
June 2022
August 2022
November 2022
December 2022
January 2023
February 2023
Analysis Report (February 2023)
ISO sample
