IcedId
IcedID Malware Analysis
Overview:
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.
SHA256: 33cc3816f98fa22354559711326a5ce1352d819c180be4328a72618d20a78632
Basic Analysis:
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
support@amcert.net
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.
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 sub_1800015D0 and sub_1800010D0.
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 Kernel32 inside 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
Basic Analysis:
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.
Advanced Analysis:
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 StartAddress
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 WinHttpOpenRequest with GET verb.
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 GetProcessHeap and RtAllocateHEap then it will write some data on it, the first data is Cookie: __gads=380132461.
after searching about __gads I found that this is a type of cookie that is used by Google for ads.
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 GetTickCount64
Then add the return value to the heap.
Then malware will call a function that will import zwquerysysteminformation from NTDLL
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 __gad cookie.*
Inside this function, we will see that the malware imports RtlGetVersion
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 GetNativeSystemInfo
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 [GetComputerNameEX, GetUserNameA]
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 GetUserNameA and 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.
Conclusion
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.
IOCs:
Loader sha256: 33cc3816f98fa22354559711326a5ce1352d819c180be4328a72618d20a78632
First dropped binary: 9ff5c9ce0d1536ce8b043b10758453e3349a82cc31195ca57250a272e65b4da4
Second dropped binary: b3841b994bbbd7474406f299b8998fcccf2def964f22fb979b922ef7d308415d
C2: revedanstvy.bid