IcedID aka #Bokbot Analysis with Ghidra.
By: Dawid Golak
Tags: Ghidra, Debugging, Reverse Engineering, Malware Analysis, X32dbg

The first stage, or how to unpack IcedID?

If we want to unpack this file ourselves, then we can look at the OA Labs video tutorial, which is available there or follow the instruction below.

Briefly to unpack this sample:

Set breakpoint on VirtualAlloc method

2. Launch sample and wait for the debugger to stop on this method, and then look at the allocated memory address (the address is returned by VirtualAlloc $EAX).

Once we have this address, set a breakpoint on the initial bytes of the address and wait until the program write data to this address.

3. As we can see at this point, the initial bytes of the allocated memory area begin with 4D 5A (MZ). It means that there is the second stage of the sample.

4. We save the memory to a file and and now we have a copy of the second stage to analyze.

The second stage

After unpacking the file and then previewing the generated pseudocode in #Ghidra, we can see the following flow.

In line №15, the argument from parameter “-q=” is retrieved.

If this parameter is not present, the code beginning on line 17 is started.Further parameters are checked.

Why does he do it ?

The process under debugger, creates the a new process which is not debugged. It is one of the way to escape from the debugger.

We have several options to debug the new process.

Ps. For instance I looked at what parameters it is run “CreateProcessA” and again execute the malware with the additional option under the debugger.

“C:\Users\admin\AppData\Local\Temp\5.exe” -q=[int]”

for example:

“C:\Users\admin\AppData\Local\Temp\5.exe” -q=412588568”

Once these argument checks have passed the next interested function to analyze is FUN_004011be().

This function contains a simple decryption algorithm, that begins at address 004011d5. Here there is a loop, which gets value from the address [00403000+ESI].

Then the bitwise shift operation is performed to the right. Then the lower bits of $EAX register is downloaded. The value of the AL register indicates the element number from the second data set “0123456789ABCDEF”

In the next step, the value from the address [00403000 + ESI] is taken again and the “AND” operation is performed.

AND EAX,0xf, the retrieved is lower bits of $EAX register

The AL register value indicates the element number from the second data set “0123456789ABCDEF”

This algorithm has been replicated in python below.

key=file(‘data3.txt’).read()

tab=file(‘data2.txt’).read()

ind = 0

res = []

p=””

for i in key:

first_poz = ord(i)>>4

second_poz = ord(i)&0xf

res.append(tab[first_poz])

res.append(tab[second_poz])

ind+=1

if ind > 1107: # while (uVar5 < 0x454);

break

for i in res:

p=p+i

print(p)

An example of the output is shown below.

Using the debugger we can verify the output from our script.

Afterwards, the “q” parameter is generated.

The next step is to run the process again with the parameters that were checked in the above conditions (-q=[int]). In the second start of the process, after passing the conditions, we come to the function.

create_self_process_with_additional_params() (org. FUN_0040124a()), which launches a new process of svchost.exe

Anti-debugging, or GetNativeSystemInfo.

Before the creation of the svchost process the malware uses an anti-debugging method. Malware uses a known method to this end called “GetNativeSystemInfo” (User32.dll).

The method is called in a function FUN_00401706(), which is called in FUN_004015a9()

According to the documentation MSDN we can obtain SYSTEM_INFO structure

The code shows that the returned value is compared with 0x9 which means the comparison of the processor architecture.

PROCESSOR_ARCHITECTURE_AMD64x64 (AMD or Intel) = 9

Once the malware executes the svchost process it injects a final stage of itself into the process. I will cover this technique and continue out analysis in Part Two.