New research into the Bumblebee malware loader and the actors using it show that the payloads delivered vary depending on the type of machine on which the malware is running, and that the actors are continuing to modify the malware’s behavior to use new file formats and evasion techniques.
Bumblebee is a relatively new malware loader that first emerged in March 2022 in a kind of beta form and the activity associated with it overlapped with intrusions that led to Conti and Diavol ransomware infections. The loader isn’t specific to one threat group and has been used by several separate groups in the last 18 months, including a group tracked by Google’s Threat Analysis Group as Exotic Lily, as well as the Conti/TrickBot group. The Bumblebee code base has some overlaps with the code of the Ramnit banking trojan and may also have links to the Trickbot code base.
Like many other malware loaders, Bumblebee uses a packer to compress and obfuscate the actual malware binary. Bumblebee uses its own custom packer and the actors have changed the file types in which the actual malware is buried over the last few months.
“The method by which this DLL is delivered seems to be subject to change on the whims of the threat’s adventurous developers: while the prevailing method is to embed the packed DLL directly inside another file (usually an ISO), during a short stint in June the malware’s operators experimented with using VHD files that executed PowerShell downloading and decrypting the packed DLL itself (packed with a very different packer), as documented by Deep Instinct. This trend seems to have died out and now the DLL can be found directly embedded in the 1st-stage file again, whether an ISO or a VHD,” Marc Salinas Fernandez of Check Point Research said in a new analysis of Bumblebee’s behavior.
Once on a new machine, Bumblebee runs some checks to see whether it’s in a sandbox or other analysis environment, and if not, it loads a configuration into the machine’s memory. In the early months of its development, Bumblebee had a feature that seems to have been designed to prevent multiple infected computers in one organization from accessing the C2 server.
“Once a client_id was generated for an infected victim and sent to a command and control server, that command and control server would stop accepting other different client_id codes from that same victim external IP. This means that if several computers in an organization, accessing the internet with the same public IP were infected, the C2 server will only accept the first one infected,” Fernandez said.
“But several weeks ago this feature was abruptly turned off, drastically increasing the number of established connections to infected victims at the expense of… whatever this feature was supposed to achieve (possibly it was indicative of a testing phase for the malware, which has now ended).”
In addition to this change, the Bumblebee actors also have modified the payloads that are delivered to victims. In cases where the loader is installed on a machine that’s part of an Active Directory domain, Bumblebee downloads a payload such as CobaltStrike or Sliver. If the infected machine is not part of a domain, it usually gets a payload such as the Vidar stealer, or a banking trojan.
“For the moment, behavior until the deployment of the 2nd-stage payload is very similar even across different Bumblebee botnets, but further behavior starting with the choice of 2nd-stage payload sharply diverges based on RC4 key used. This behavior can also serve to group activity into different clusters, on top of using the RC4 key itself,” Fernandez said.