IcedID Malware Analysis
IcedID (AKA BokBot) is a relatively new strain of malware first discovered in 2017 that is classified as a banking trojan and remote access trojan (RAT). It is considered to have capabilities comparable to other sophisticated banking Trojans such as Zeus, Gozi, and Dridex.
The first thing I’m going to do is to upload this binary to
DIE to know the file type and other initial information.
The first thing to be noticed is that binary is a driver and from the entropy check, we can say that this binary is not packed.
The second thing I’m going to do is to extract the strings from this binary and search for suspicious ones from the output of
FLOSS I didn’t get any suspicious strings unless some domain names we can watch if the malware will use it or not.
http://crl.comodoca.com/AAACertificateServices.crl04 http://ocsp.comodoca.com http://crl.sectigo.com/SectigoPublicCodeSigningRootR46.crl0 http://crt.sectigo.com/SectigoPublicCodeSigningRootR46.p7c0 http://ocsp.sectigo.com https://sectigo.com/CPS0 http://crl.sectigo.com/SectigoPublicCodeSigningCAR36.crl0y http://crt.sectigo.com/SectigoPublicCodeSigningCAR36.crt0# http://ocsp.sectigo.com email@example.com
I think these domains are legitimate but we trust nothing.
We can also run this binary under
CAPA to get more information about its techniques before digging into the details and we can get these capabilities.
From this point, because this binary is not executable we can move to advanced analysis.
So, if we load the binary into IDA, the first function we will face is
DriveEntry and this function doesn’t perform anything.
If we see the imports we will find some APIs from Kernel32 and all of them are called from
DllRegisterServer and also 2 functions
If we look at
sub_1800015D0 we will see a lot of calculations that seem to construct something.
and also there are calculations inside
sub_1800010D0 there is a nested call to
sub_1800020A0 which also seems to construct something.
So, we can load the binary into the debugger to see what is happening.
So, in the debugger, we will set the origin to
DllRegisterServer and start the debugging from it.
We will enter
sub_1800015D0 and we will see that there is a nested call, put a breakpoint on it and run the sample. We will find that
rcx contains a string
AcquireSRWLockExclusive and this is an API from Kernel32 also if we run it again we will get
ActivateActCtx which is also an API from Kernel32.
So we can remove this breakpoint and set one on the
ret and we will get
RCX. So, this function seems to dynamically load Kernel32 DLL.
Return to DllRegisterServer we will see that the binary will jump over all APIs we found in IDA, but also will jump over
sub_1800010D0 so we will go to this function and set the origin inside on it to see what the calculations inside it will do.
Inside this function, we will see that there are 4 nested calls, so, put breakpoints on those calls and debug each one.
the first function is called
7FFD0FA51370 inside this function we will see a lot of calculations and calling to function in
r10 and after running the function we will see that this function is
VirtualAlloc if we run the function until
ret we will see that the memory that located by
VirtualAlloc will hold a binary.
So we have a second-stage binary, let’s dump it and continue the debugging.
The second function in
sub_1800010D0 similar to the first one also performs calculations and then calls a function inside
r10 which is
VirtualAlloc and also dropped a binary.
So, now we have two dropped binaries and I will analyze those binaries.
First dropped binary
The first thing is to load the binary into
DIE to know the type of the binary and DIE told us that this binary is DLL
Then we can get the strings inside it to see if there are some interesting things or not.
1- Network APIs WinHttpSetStatusCallback WinHttpOpen WinHttpCloseHandle WinHttpConnect WinHttpReadData WinHttpQueryDataAvailable WinHttpSetOption WinHttpOpenRequest WinHttpSendRequest WinHttpReceiveResponse WinHttpQueryHeaders WinHttpQueryOption 2- Dealing with processes and files APIs ExitProcess CreateThread CreateFileA WriteFile 3- System enumeration APIs GetTickCount64 GetComputerNameExW LookupAccountNameW GetUserNameA ZwQuerySystemInformation GetAdaptersInfo GetNativeSystemInfo 4- Dealing with memory APIs VirtualAlloc VirtualProtect HeapAlloc HeapReAlloc HeapFree 5- Path c:\ProgramData\ 0123456789ABCDEF 6- Network IOCs Cookie: __gads= %s%u POST ; _gat= ; _u= o; _gid= ; _ga= aws.amazon.com Cookie: _s=
A lot of interesting things inside strings that can help us with the analysis.
Then we can run
CAPA on it to know more about its functionalities.
CAPA’s output matches the functions that strings indicate it.
After loading the DLL into IDA-64, IDA will get the DllEntryPoint which doesn’t have anything unless creating a thread for the block of code called
And inside this function, there is a single call to
sub_180002434, there are a lot of things inside this function.
First, the code will get into a loop of sleep.
Then the function will use
wsprintfA a lot of time and this function is used to write formatted data to the specified buffer. So, the malware will write data may be to file as we see in strings but let’s dive deeply.
After that, the malware will call a lot of functions:
[sub_1800011FC, sub_18000153C, sub_180002C08, sub_180001EEC, sub_18000272C, sub_180001FD0, sub_180002A1C, ]
So, let’s see what is inside these functions one by one.
sub_1800011FC: Inside this function, we will see that there are calculations with
XOR operation so, this function may be a decoding routine.
so, let’s debug it.
Inside the debugger, we can follow
[rcx+rdx+40] in the dump and see the construction of the data.
revedanstvy.bid: May be a domain name or something else. The first function is done let’s see what is inside the second function.
sub_18000153C: The first we will see in this function is the Amazon domain name
It’s confusing to see the legal domain name in malware code followed by functions related to network connection
When debugging this function there is a strange thing, the malware will call
WinHttpOpen without any parameters. Which will cause an Access Violation Error.
I tried to understand why the malware does this, but I don’t know maybe it’s anti-debugging especially since this API comes after the legal Amazon domain name, but we can set the origin after this call to bypass the error and continue to examine the code carefully.
After that, the malware will call
WinHttpSetStatusCallback which sets up a callback function that WinHTTP can call as progress is made during an operation. and also this function call will cause an Access Violation Error.
Then the malware will call
WinHttpConnect to connect with the Amazon domain, then call
I think this function is for tricking the analyst, so, let’s see the next function.
sub_180002C08: The first thing we will see inside this function is that the malware will allocate memory space on the heap using
RtAllocateHEap then it will write some data on it, the first data is
after searching about
__gads I found that this is a type of cookie that is used by
So, maybe the malware uses this to bypass firewall detection of mal traffic, but I still don’t know about the number that comes after it.
Then the malware will call a function that calls
Then add the return value to the heap.
Then malware will call a function that will import
This function returns information about the running processes, loaded modules and opened handles and I’ll put an article that documents it in the References section below.
Then the malware will call this but with strange parameters.
If we see the documentation of
NtQuerySystemInformation which may be similar, in MDSN we will see the parameters of this function.
So, the second and third parameters are assigned to zero and the first parameter which is
SystemInformationClass is assigned to 5 so the malware will get information about Systeminformation according to this article
and the last parameter which is
ReturnLength is a pointer to a location where the function writes the actual size of the information requested.
When I executed the function, it returned
STATUS_INFO_LENGTH_MISMATCH and according to this code, the malware will not write any data on the heap. I think this happened because getting this information requires Admin priveledges
After restarting the debugger to run as admin, I found a strange thing, the malware will get data from the heap from different locations, if we follow the location we will see that above this data there are system processes like
[svchost.exe services.exe, winlogon.exe, fontdrvhost.exe]
I think in this function, the malware will enumerate the process on the system to inject code inside one of them but I didn’t find any code injection routine inside it, we can keep debugging.
After returning from this function the malware will also call a function with and pass a parameter to it on
RCX, this parameter is a pointer to data collected by the malware with the
Inside this function, we will see that the malware imports
And this function will set the version to 10 because my machine is Windows10
Then inside the function, the malware will call a function that will import
The return from this function will tell the attacker that the machine is 64-bit.
Then the malware will perform nested calls but we will find a function that contains
CPUID instruction which gets processor identification and feature information.
The final data got from this function is :
Then the malware will call a function which will call some functions to get more information about the victim machine like
The last function inside this function will call
GetAdapterInfo to retrieve adapter information for the local computer.
For some reason, some errors are occurring on my machine while calling
GetAdapterInfo the debugger shutdown and I couldn’t complete debugging, but by looking at the rest of the code we will see that the malware will use Network APIs again and we can easily figure out that this call is to send the gathered data to the attacker.
We will continue the analysis without debugging and try to figure out what will happen after the communication.
If we open the code of the next function will see that the malware will create a folder on
C:\ProgramData and then create a file within this folder and write some data which got from the C2 server and maybe it will be a mal content
Second dropped binary:
I performed basic analysis on this binary and I found that it’s very similar to the first binary so we can ignore it.
So, we now have a big picture of what this malware does.
First, there is a binary file that will drop two DLLs into the system, then firstly The DLLs will perform legal traffic to
aws.amazon.com to trick the firewall then it will resolve the domain of the attacker, after that the malware will gather information about the machine and user and embedded this information into cookies to make them legal with converting the ASCII information like the computer name into numeric representation to be more like legal, then it will send all of this information to the C2 server and get content from this server and write this content into a file.
Loader sha256: 33cc3816f98fa22354559711326a5ce1352d819c180be4328a72618d20a78632 First dropped binary: 9ff5c9ce0d1536ce8b043b10758453e3349a82cc31195ca57250a272e65b4da4 Second dropped binary: b3841b994bbbd7474406f299b8998fcccf2def964f22fb979b922ef7d308415d C2: revedanstvy.bid