The chronicles of Bumblebee: The Hook, the Bee, and the Trickbot connection
In late March 2022, a new malware dubbed “Bumblebee” was discovered, and reported to be distributed in phishing campaigns containing ISO files which eventually drop DLL files that contained the Bumblebee malware itself..
This malware deployment technique is not new, and several other malware has already been observed using it, most notably: BazarLoader, and IcedID. Also, similar to the aforementioned malware, Bumblebee too was observed delivering the Cobalt-Strike framework.
From a threat research perspective, what makes this malware interesting is the fact that it was associated with the Conti ransomware group as one of the group's threat loaders.
In the past, the traditional loaders of Conti were Trickbot, Bazarloader, and Emotet, so it was quite intriguing to inspect this malware closely.
In this article, I will present a code analysis of the Bumblebee malware, obviously, due to the malware's large size I will not cover everything, and will focus on the parts that I think are the most interesting in terms of capabilities.
Also, one of my favorite topics in malware research is the ways of malware to avoid detection, so I will put more emphasis on this subject as well.
Lastly, I divided the entire article into three parts, the table of contents is the following:
- PART 1: The hook- unpacking the bumblebee’s crypter
- Unpacking mechanism
- Enters the hook
- Executing the code
- Bumblebee dropper high-level summary
- PART 2: The bee- Investing the bumblebee’s payload
- Stolen anti-analysis code
- Searching for processes
- Searching registry keys
- Searching file paths
- Executing processes
- The little ones inside the flask: hiding additional DLLs
- PART 3: The Trickbot connection- Investigating the hooking DLL
- Check for existing hooks
- Setting the hooks
- First hooks: Disable exceptions
- Second hooks: Further code execution
- The Trickbot hooking engine
- Static differences and code evolution
- Additional similarities
- Customize flattened RC4
- RapportGP.dll high-level summary
The Hook: Unpacking the bumblebee’s crypter
The initial dropper of Bumblebee is a 64bit file, with relatively high entropy which indicates a possibly obfuscated \ encrypted content that will be decrypted in runtime.
The DLL itself contains two export functions: InternalJob and SetPath. Also, the file’s internal name appears to be “lodqcbw041xd9.dll”.
Once we enter the loader’s main function, we see that it is unique, and does not look like any common crypters that can be found in Conti’s loaders (such as Emotet or Bazarloader).
As we open the loader in IDA, we see that the majority of the PE in the IDA navigator has the olive color which means unexplored bytes. This is common when there is some content in the PE that needs to be decrypted during runtime.
Tip: During my analysis, I disabled the file’s ASLR to match the addresses in IDA and Xdbg, this is super helpful and saves a lot of time.
To do so, open the file in CFF explorer, and then:
- Click Optional Header
- Go to DllCharacteristics
- Remove the V from “DLL can move”
Next, we can see that the DllEntryPoint is an empty export function, so we will want to redirect our execution flow to one of the working export functions, for this case, we will choose “SetPath”.
To redirect the flow, do the following:
- In IDA \ PE-Bear, copy the address of the required export function
- In Xdbg, right click on RIP
- Click on “Modify Value”
- Paste the address of the export function
After clicking OK we will find ourselves at the beginning of the export function. This trick can be used in any other malware the executed via designated export function
From a reverse engineer perspective, the crypter is an inconvenient binary to inspect, and there are not many “quick wins” we can gather just by looking at it, however, this crypter is unique in today's landscape so I will focus on the areas I found are the most interesting.
First, the crypter will start with a traditional unpacking activity, in the function sub_180003490 there are two other functions:
- sub_1800021D0 - which will allocate virtual memory using HeapAlloc (this function will happen multiple times during the crypter unpacking)
- sub_1800029BC - Which gets an embedded content and writes it into the newly allocated memory
Then, the function sub_180002FF4 will be executed to do the following:
- Allocate new virtual memory using the same sub_1800021D0 function.
- Manipulate the content from the first allocated buffer and write the output into the newly allocated memory
The next step will be the function sub_180004180, this function will do the following:
- It executes a function named sub_180001670 that will allocate multiple virtual memories using the already mentioned sub_1800021D0.
- Call the function named sub_180003CE that will use the virtual memory that was allocated in sub_180002FF4, do additional manipulations, and eventually writes an unpacked MZ into the last allocated buffer from the function sub_180001670.
When looking statically in the function sub_180003CE, the loop that will write the unpacked file will be the following:
And when observing dynamically, it will look like the following:
In the end, we get an allocated memory with Read-Write permissions with an unpacked payload inside.
Until now, everything that is observed are things that are pretty much common in other loaders \ crypters, however, we still have two unsolved questions:
- The code section of the payload does not have Execute permission, so it cant run.
- What makes this loader special?
Enters the hook
The loader will enter a function called sub_180001000, this function will create inline hooks that will ignite the chain of events that will lead to the code execution.
As we enter, we notice something interesting, the loader assign functions to a memory address, then it will call another function named sub_100025EC.
This function will do the following:
- Get Ntdll handle with LoadLibrary
- Get the address of NtOpenFile
- Get the address of NtCreateSection
- Get the address of NtMapViewOfSection
- Return the data
To observe it dynamically, we can just go to the debugger and step over the functions themselves.
After exiting sub_100025EC, our attention will go to a function named sub_1800037C4. This function will be responsible to install a hook in the aforementioned NT functions.
It will do it in the following way:
- Call VirtualProtect to change the protection of the area it wants to write into to be writeable
- Call sub_180002978 that will take as arguments:
1. The function to write into
2. The content it wants to write
3. The size
- Call VirtualProtect to change the protection again to not be writeable
Eventually, this activity will occur inside a loop to install the hooks in each of the NT functions. The hook that will be installed will be the functions that have been assigned to memory addresses at the beginning of the larger function.
- sub_180001D4 for NtMapViewOfSection
- sub_1800023D4 for NtOpenFile
- sub_1800041EC for NtCreateSection
If we wanted to observe the changes dynamically we have two options, the first one is to just observe it in the debugger by step over sub_180002978
Another option is to use the took Hollow hunter with the “/hooks” as an argument. Then, we will have a .tag file from the hooked DLL (if found of course)
And when we open this file with a text editor we could see the indication of who are the hooked function, and where the hook itself lies.
To summarize the hooking procedure, it will look like this:
Executing the code
After we finish setting the hooks, we will head to the function sub_1800013A0
This function will attempt to execute the DLL “GdiPlus.dll” using the API call LoadLibrary, with SetPath as an export function.
Q: Why does the malware even want to use GdiPlus.dll?
A: It doesn't.
Q: So why the need to load it?
A: Because it is not loaded (wait what?!)
The malware will attempt to use some (and unique) custom unpacking:
- When LoadLibrary loads a DLL file, it uses internally the hooked NT function as part of its internal activity.
- The malware chooses a DLL that is not loaded yet.
- NtOpenFile will get a file handle of GdiPlus.dll
- NtCreateSection will create a section for the file handle of GdiPlus.dll
However, here is when things become tricky, when the LoadLibrary will try to use MapViewOfSection to map the GdiPlus.dll section, the hook function of MapViewOfSection (sub_180001D4C) will do the following:
- It will use CreateSection to create a new section with READ-WRITE-EXECUTE permissions, without any file handle to associate it with.
- It will write the unpacked malicious content into this section
- It returns NTSTATUS_SUCCESS to the LoadLibrary so it will seem to it as if GdiPlus.dll was mapped successfully.
The result will be an unpacked bumblebee malware that resides in the RWX section and is associated with GdiPlus.dll. Interestingly, the GdiPlus.dll is considered a relocated DLL in Process hacker.
Bumblebee dropper high lever summary
If we want to look at all the dropper unpacking mechanism steps in a high-level overview and summarize them into three steps, it will look like this:
The bee: Investigating the bumblebee’s payload
The unpacked malware is a large 64-bit file with quite high entropy.
This file appears to be the core component of the Bumblebee malware. It features many traditional capabilities we would expect from malware, such as internet communication, file manipulation, collecting user information, cryptography libraries, etc.
In my article I will not cover this file as much because of scoping decisions, however, some interesting code parts to mention are:
Stolen anti-analysis code
As with many malware, Bumblebee also has anti-analysis tricks, however, the majority of them are grouped in one large function. Also, During my observation, I notice that additional anti-analysis checks have been added as time goes by, which indicates a quick evolving malware or that the authors are still in the “testing the waters” phase.
In addition, this entire anti-analysis function code is taken from the GitHub page of the “al-khaser project”. For good measure, I will show some examples.
Searching for processes
The malware will search for multiple tools that are being used for dynamic and static malware analysis tools. The malware will iterate through the processes using CreateToolHelp32Snapshot.
As said, this code is the exact code found in the al-khaser project.
The malware also attempts to detect any kind of virtualization environment with the detection of their processes, it varies from Vmware to Vbox processes.
Searching registry keys
The malware will attempt to search for designated registry keys that indicate any kind of virtual environment from multiple products.
Searching file paths
The malware will search for file paths that can indicate any kind of virtual environment.
At this point, it will be useless to continue writing the anti-analysis capabilities, so for those who want to see all, please visit the al-khaser project GitHub page.
Among the malware, capabilities are to execute Rundll.exe to run the DLL with the InternalJob as an export function using Wscript.
Also, the malware can use PowerShell to perform further activities
The little ones inside the flask
One of the most interesting things about the Bumblebee core component is the fact that it contains two DLL files inside of him.
Both of these files have the same internal name RapportGP.dll (which is also used by the security company Trusteer)
The two DLL files are completely identical except for the fact that one of them is 32-bit and the other is 64-bit.
PART 3: The shadow of Trickbot- Investigating the hooking DLL
In the last part, I will investigate the RapportGP.dll, as said, there are two versions: 32\64 bit, and for my analysis, I will focus only on the 32 bit.
The main concept behind RapportGP.dll is hooking, and the entire module’s mechanism is supporting this activity.
Check for existing hooks
One of the first activities of the module occurs in a function named “sub_100060C0”, in general, this function will be responsible to check if there is any hooked function from a list of pre-determined functions.
Inside sub_100060C0, the chain of events that leads to this is the following:
- A handle to Ntdll.dll, Kernel32.dll, Kernelbase.dll, Advapi32.dll obtained
- The requested DLL’s path obtained
- A call to the function sub_100059B0 was made to get a copy of NtProtectVirtualMemory that stored in the allocated memory
- The arguments are sent to another function named sub_10005B90
The functions it wants to check are:
In sub_10005B90, the module path of the requested DLL file will be mapped to memory and will be sent to an additional function named “sub_10005D40” that will deal with the actual checking.
As for the checks themselves, it is quite simple:
- The malware iterate through the export functions of the legitimate DLL file that was mapped to memory by the process when it loads.
- The malware will check if the name is one of the function names it wants to check
- Once found, the malware calls sub_10001040 that checks for hooks evidence in the DLL that was mapped by the process loader
- The malware will do the same for the DLL that was mapped by the malware itself (in sub_10005B90).
- If no hooks are found, it will continue to iterate
And if there is an indication of hooks, the malware does the following
- Get information about the original function
- It will change the protection
- Check if it's writable
- Write the content of the mapped function to the original function. In this way, it restores it to the state it should be if there are no hooks.
If we wanted to observe this activity dynamically, all we need to do is to change the bytes from the beginning of one of the functions the malware wants to check. For example, let's take NtCreateFile.
- Original function at 775222C0
- The function that mapped by the malware at 02E022C0
When looking in the dump, we can see that their code is exactly the same
Let's change the first byte of the original to have an E9 opcode (jump)
Now, if we will try to debug dynamically, we will be able to get to the last part of the code.
After stepping over memset, we can see that the E9 byte no longer exists and the original function returned to its normal state.
At a very high level, the process eventually looks like this:
Setting the hooks
After checking that there are no other hooks, the malware turns to set its own hooks. The malware will have two kinds of hooks for different purposes.
First hooks: Disable Exceptions
The malware will set a hook on the function RaiseFailFastException which is located in kernel32.dll and api-ms-win-core-errorhandling-l1–1–2.dll.
The function that will be triggered will be empty, therefore no exception will be triggered.
Second hooks: Further code execution
The malware will use the same technique the bumblebee loader did. It will first get the addresses of the function ZwMapViewOfSection, ZwOpenSection, ZwCreateSection, ZwOpenFile, ZwClose, and LdrLoadDll.
And similar to the Bumblebee’s loader, it will first set the hook, and then will call LdrLoadDll which is the lower lever equivalent of LoadLibrary to load the module “wups.dll”, which will trigger the chain of events we already discussed in the Bumblebee loader part.
The Trickbot hooking engine
Although both hooks are doing completely different things, the hooks’ installation mechanism is the same. Interestingly, this mechanism is also the same as the web-inject module of Trickbot.
As with many ex-bankers that use hooking such as Panda, Trickbot, and Qbot, their hooking code is based on the Zeus leak, however, each of them has its flavor and changes and Trickbot is no different.
In the Trickbot web-inject hooking mechanism, which has already been documented, when creating the inline hooking “trampoline” there is the following evasion technique:
- Trickbot writes 35 bytes of NOPS (0x90)
- Add the traditional function prologue
- Write the jump to the targeted function at the end of the NOPS
As we debug Bumblebee, we notice it uses the same unique evasion as well (adjusted for the API calls it wants to hook). So for example when hooking the ZwMapViewOfSection, which instantiates a Syscall, it will look like this.
And when targeting the user-mode functions RaiseFailFastException, it will look exactly like in Trickbot.
Static differences and code evolution
When inspecting the entire code flow graph of the hook installation function, we can see a striking similarity between Bumblebee’s RapportGP.dll and Trickbot’s web-inject module.
Interestingly, although the actual functionality is the same, we might think that statically everything is the same, even the sub-functions inside the hooking installation function. Funny enough, this is not the case.
As mentioned above, in the hooking installation function, one function is responsible for doing checks and return size (Please see the image above).
- In Trickbot its sub_10001650
- In Bumblebee its sub_10002870
However, when inspecting their code and code flow statically, this is how they both look like
Obviously, in Bumblebee, the authors have decided to use Control-flow-flattening to obfuscate the entire flow of the function. For those of you who are not familiar with this obfuscation technique, I strongly recommend the following video.
In addition, inside each of these functions (sub_10001650 in Trickbot, sub_10002870 in Bumblebee) there are 3 functions (one of them is memset), and the Control-flow-flattening concept continues in Bumblebee inside them as well.
For example, here are another two functions that act the same dynamically:
When observing the two functions in Bindiff flow graphs, we could see some similarities.
In both modules, there are other functions that are not completely identical by code, however, they serve the same functionality.
Before entering the hooking functions, both Trickbot and Bumblebee attempt to use LoadLibrary and get the address of the function it wants to hook.
The difference is that in Trickbot it explicitly writes “Kernel32.dll” and in Bumblebee it gets the DLL’s name from the caller function.
The call for the hooking activity looks very similar as well
Outside the hooking, the Bumblebee’s hooking module starts with getting the process handle and eventually duplicating a thread handle, whereas, the Trickbot’s module starts with getting the process handle and duplicating the token. Again, the same objective, in a different way.
Customize flattened RC4
Another interesting activity lies inside the hooked ZwMapViewOfSection function. The hook appears to use a customize RC4 obfuscated with the Control-flow-flattening technique.
RapportGP.dll High-level summary
When trying to summarize the entire file behavior, it eventually is the following:
The bumblebee malware is a very interesting piece of code, and to perform their objectives, the authors show a high level of creativity and innovation.
The interesting similarities between the Bumblebee hooking DLL and the Trickbot’s web-inject DLL raise questions and speculations.
On one hand, the similarities are not strong enough to deduce that the authors of Bumblebee and Trickbot are the same, on the other hand, it is not far-fetched to assume that the authors of Bumblebee have the source code of the Trickbot’s web-inject module.
In any case, the authors took an already proven and working code and evolve it to be less detectable to AV products, and challenging to security researchers.
Trickbot web-inject module: 0785D0C5600D9C096B75CC4465BE79D456F60594