Bumblebee Malware Analysis - Part 1 - Bumblebee Dropper

We have to see basic details to determine further details, we check DIE and see this executable’s type is DLL and there is no packer DIE detected. But this is not enough data to fully cover this DLL’s basic details, entropy is not spoken yet.

We check entropy of this executable, we clearly see that this is packed. But DIE does not show which packer was used, so we can think that 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”. As their name we can guess what they do, but we have to see what they do.

We keep gathering information as we can find, we check PEstudio and helps us with the flags and indicators. PEstudio says: “These strings look suspicious, according to my database these strings are grouped in these operations. As I marked in indicator section, you should consider these too.”

Gathering Information

We have a few ideas where we should look for further details. We assume this DLL will decrypt the content which is probably 2999 byte sized string (there are suspicius large strings and looks like they are some kinda code) with own exported functions. So for now, IDA will help us to see what is going on. We have to understand unpacking mechanism.

Static Analysis with collected info

On the top horizontal bar of IDA, a large section marked with olive color which means unexplored bytes.

---

Tip: During the analysis, you should disable file’s ASLR to match the addresses in IDA. A basic Powershell command works.

Set-Processmitigation -Name name.exe -Disable ForceRelocateImages

You can also disable ASLR with CFF Explorer.

File > Nt Header > Optional Header > Find DllCharacteristics > Uncheck “DLL can move”

---

DllEntryPoint functions looks empty, but other functions do something so we will use these functions. So we redirect our execution flow to one of the working export functions, for this case, we will choose “SetPath”.

In IDA, we go to exports section and copy the address of required export function. Then we will need a debugger to test it, so we will use x64dbg and modify the RIP value with copied address.

• First after open with x64dbg you should run to step into DllEntryPoint function.
• Then edit RIP value to coppied address of “SetPath”
• Press OK and we are in SetPath function

Minimize x64dbg because we go deep into the functions of SetPath and the other function IternalJob in IDA. When we follow SetPath function we see this function returns “sub_180004AA0(4262133883i64)”.

We shouldn’t forget that the crypter is an inconvenient binary to inspect, we can gather a few helpful information by looking at it. So we have to identify known functions and try to make some guesses based on experiences. There is no easy win, we have to scrape every single information we can gather and look at the complete actions.

Some investigeting from top to end “sub_1800021DO” and “sub_1800029BC” memory took my attention.

“sub_1800021DO” is the first understandable function because this function will allocate virtual memory using HeapAlloc, we know what this function do so we can rename this function and some variable name changes belongs to this function. This function allocates virtual memory for (probably) another function to write decrypted data into the newly allocated memory.

HeapAlloc: “allocates a block of memory from a heap. The allocated memory is not movable.” - Microsoft

DECLSPEC_ALLOCATOR LPVOID HeapAlloc( [in] HANDLE hHeap, [in] DWORD dwFlags, [in] SIZE_T dwBytes );

“sub_1800029BC” gets an embedded content and writes it into the newly allocated memory.

Then, the function sub_180002FF4 will be executed to do the following:

1. Allocate new virtual memory using the same sub_1800021D0 function.
2. Manipulate the content from the first allocated buffer and write the output into the newly allocated memory

Next function is “sub_180004180”, this function will do the following:

1. It executes function “sub_180001670” that will allocate multiple virtual memories using the already mentioned sub_1800021D0 which I renamed as “func_allocate_memory”.

1. Call the function named “sub_180003CE4” that will use the virtual memory that was allocated in “sub_180002FF4” (short reminder: this function allocated a new memory and rewrite them with manipulation to new memory), do additional manipulations, and eventually writes an unpacked MZ into the last allocated buffer from the function “sub_180001670”, this buffer kept on a2.

We got something here, program makes multiple manipulations, decrypt own encrypted data and stores it in buffer. We can check buffer and see what is in there. So we need to open x64dbg here and execute the program till this process to catch decrypted executable. Do not forget the check this box and copy this functions address from hex view.

Here we changed RIP value to desired loop structures’ address and we will debug these processes and watch them with ProcessHacker. We want to see exact buffer while executing loop structure, as you can remember DLL loader writes the new executable to buffer and we want to see what is inside of this executable.Now we will interrupt with ProcessHacker while DLL loader writes the buffer.

1. Set RIP “0000000180004174”
2. Add breakpoint to “0000000180003FCB” and run
3. Right-click on ds:[rdx+rcx] which will contains decripted payload and select follow in Dump
4. Disable breakpoint because there will execute a loop and write it to buffer, we will wait till it ends. So before pop and return instructions we should add a breakpoint and see the exact buffer. So we will add a breakpoint before pop operations
5. Look at the dump and see the payload
6. We want to save this so with help of ProcessHacker we will check the buffer and extract these and save it.