The Dark Side of Bumblebee Malware Loader
Deep Instinct recently prevented a targeted Bumblebee malware attack in one of our clients’ environments. The attack, which was detected and prevented before execution, involved an obfuscated PowerShell script, a .VHD file (a type of disk image file similar to .ISO), a DLL, and spear phishing correspondence.
Currently, the relevant IoCs (indicators of compromise) are not detected by most security vendors. This blog will provide a detailed review of these IoCs and provide technical details of the stages of the full Bumblebee malware attack.
Spear Phishing and Delivery
Phishing attacks have become threat actors’ tool of choice for malware delivery. The concept is quite simple: an attacker crafts a dropper and attaches it to an email with a compelling message meant to fool the target into opening the file. However, greater awareness and training on how to spot and avoid these attacks is leading threat actors to employ more sophisticated means to launch spear phishing attacks.
The most successful spear phishing campaigns rely on deception to gain a potential victim’s trust – often including personal details about the recipient in the phishing note or sending the harmful email from a domain that is very similar to one that the recipient trusts. Threat actors also commonly impersonate close friends and colleagues to trick their targets into opening compromised messages.
Deep Instinct prevented an infection that started with a clever spear phishing attack where the malicious actor pretended to be someone from a well-known organization, using a domain with an almost identical name, impersonating an employee, and using a highly relevant subject line to trick the target into opening the note.
To further establish trust, the attacker did not include any attachments or requests to download files from a remote location in their first email – they only introduced themselves as the person they were impersonating and used the promise of a new business opportunity to increase their odds of getting a response.
After the initial contact had been established and “trust” earned, the threat actor invited the recipient to a meeting with them. Files were sent to be reviewed before the meeting, and the recipient was informed that another email with a link to the file sharing platform “Smash” would also be sent.
The attacker used a domain “hognose1” registered with porkbun.com, with Postfix smtpd.
The “Smash” link was provided in a separate email leading to a .VHD file. The file contained an .LNK (shortcut file), which executes a hidden PowerShell script that resides in the disk image file as well.
The malicious VHD contains a shortcut file which runs a hidden PowerShell script when executed.
Following Microsoft’s default disablement of Office Macro and requiring a few more steps to enable it, the combination of a disk image file (.ISO/.VHD, etc.) and shortcut file has been gaining in popularity as a “replacement” to Office Macros in the threat landscape.
Price Quote for PowerShell Loader
“quoutefile.ps1” - 1st Stage PowerShell loader
Once executed by the .LNK file, “quoutefile.ps1” will hide the open PowerShell window and continue running. This is likely a measure to avoid using the “-windowstyle hidden” PowerShell command line parameter, which can lead to an increased chance of detection.
An interesting point of note: the code employs light, but effective, obfuscation intended to break up suspicious strings and evade static scanning.
Having hidden the active PowerShell window, the code continues to de-obfuscate a series of more than 100 “elem” variables which contain Gzip compressed data streams by replacing the first character in the stream with the character “H” and forming a Gzip stream header by using “insert” and “remove” instead of the much more common “replace” method; the valid Gzip stream is then appended to an array.
This is another example of how cybercriminals use simple and very effective measures to evade static scanning.
The code then iterates through the array of Gzip compressed streams, decompresses them, and forms the 2nd stage code block which will then be executed by “Invoke-Expression.”
2nd Stage PowerShell loader
The 2nd stage of the PowerShell loader is composed of a very large, very well written (even commented) code block which loads an embedded 64-bit .DLL to memory.
This stage also continues the theme of simple, effective obfuscation intended to evade static analysis.
The loader validates the embedded file and performs multiple checks to ensure the file is loaded properly on the executing system.
Finally, the loader sleeps for five seconds and calls its main function in order to load the payload .DLL to memory.
Note the “replacement trick” used here to conceal the executable MZ header; similar in fashion to the Gzip stream “obfuscation” used in the 1st stage.
Link to Bumblebee Malware
The final DLL is a 64-bit Bumblebee payload.
It is protected by what appears to be a unique private crypter that is present in all Bumblebee binaries. The crypter uses an export function named “setPath:”
Even before unpacking the sample (simply by looking at the strings of the file) it is clear that no major changes are made.
The “stolen” open-source code for the anti-vm is still present:
The code is a huge collection of various techniques used to identify if a program is executed in a virtual machine or using emulation and if debuggers and sandboxes indicators are present in the running environment.
There are checks for processes of known malware analysis and debugging tools as well as processes related to virtualization.
Specific registry keys are queried to identify whether the system is virtual. In addition, there are checks for DLL and SYS files and specific folders that will exist only in a virtual machine.
The MAC address is also checked as virtual network cards can be easily identified by the name of their virtualization vendor.
Various WMI queries are done for system information, such as fan information.
A full, detailed overview of Bumblebee malware can be found here.
Link to the Threat Actor
The observed attack chain is consistent with EXOTIC LILY activity.
The attackers registered a visually similar domain, using a lowercase “L” instead of a lowercase “I” which spoofed a legitimate U.S.-based cybersecurity company.
The attackers created an email box impersonating an employee of the company and sent business proposal leads.
The mails are written in proper English, including an email signature which looks very similar to the signature used by the company. The domain in the email signature is changed to the fake domain created by the attackers.
Although it might be coincidental, the attackers chose to send the mails around the time of Black Hat USA; this might be because many sales teams are out of office and attend the conference and we speculate that they may have less security measures outside the office and are constantly networking, making it more realistic that a business proposal email would be sent, received, and read during the show.
One notable change in EXOTIC LILY’s activity is the addition of the “Smash” file transfer platform to deliver Bumblebee.
As noted by Google’s TAG, “EXOTIC LILY seems to operate as a separate entity, focusing on acquiring initial access through email campaigns, with follow-up activities that include deployment of Conti and Diavol ransomware, which are performed by a different set of actors.”
IBM found connections and code similarities between Bumblebee, Ramnit, and Trickbot malware which seem to be developed by the same group that developed the Conti ransomware.
Deep Instinct Prevention of Bumblebee Attack
While Deep Instinct prevented the attack pre-execution the detection rate of the PowerShell payload was zero on VT when first seen, and even a few days after only three more generic detections were added.
The below prevention notification proves once again that a signature-based detection is not effective against new or modified attack flows.