Emotet Spam Push IceID Banking Trojan - Part 3 [ICEID Banking trojan Hooking Process]

In this last part I decided not to analyzed again the Emotet malware since I already did it last time :). see this post "Emotet Analysis".
And also  IceID Banking Trojan is not a new malware, I will just focus on the interesting hooking trick it use to decompress its code, inject and execute its code.

so let's start!!!

sha1: bd6a05ba4b1d3e2a871a43b1bf0fe6d4ad82fba8
sha256: 3a39f8e54b67df24588649974e5535f1f061facfc46a85cc374004277ada1bce

same as other malware, this file is also packed. So by using debugger to unpacked in manually I manage to get the actual code.

API Harvesting...

The first thing it will do is to harvest the API it needs in hooking and injection technique. It will locate the image base of the ntdll.dll in PEB then call a function that was resposible in parsing the 8 API it needs.

the function contain 4 parameters :
 ParseExportAndApiHasher(unsigned int ntdll_ImageBase, int apihash_table, unsigned int apihash_count, int buffer_api)

fig. 1 - the harvest api function

The API hashing algorithm it used was not so complex, it only used the ROR "rotate right" to generate hash of each API and compare it to its API hash table.

fig. 2 - the hashing algorithm

by using my python script in my previous post that extract the export table "resolving-api-hash-using-ida-python" and with a python script that simulate the hashing algorithm, I manage to check what API it tries to locate in ntdll.dll export table.

fig. 3 - hasher function in python

The API's it tries to find are related to the hooking and injection process it will execute.

RtlExitUserProcess
NtProtectVirtualMemory
LdrLoadDll
NtWriteVirtualMemory
NtAllocateVirtualMemory
LdrGetProcedureAddress
NtCreateUserProcess
RtlDecompressBuffer

below is the hex-ray code view how it setting up the API hooking.

• at first it allocate heapmemory to place the string "svchost.exe"
• then call its hooking function where it will hook the NtCreateProcess API. The function contain 3 parameter that are shown below.
• then call NtCreateProcess function to trigger the hook code.

 

Behind the Hooking Function...

as you get in to the Hooking function of this malware you can see the common pattern of API.

•  save the original permission and then change the protection on a region of committed pages in the virtual address space of the calling process.
• save the number of original bytes of the API function you want to hook so you can return to the  actual execution of the API after the malicious hook function  is executed.
• after the API execution, change again the protection permission to read/write to bring back the original bytes of API procedure.
• then bring back the original protection permission. 

 Undocument API

 This malware used undocumented API to change the protection permission of specific part of NtCreateProcessA procedure. The said API has the format below.

Public Declare Function NtProtectVirtualMemory _
               Lib "ntdll.dll" (ByVal ProcessHandle As Long, _
                                ByVal BaseAddress As Long, _
                                ByVal RegionSize As Long, _
                                ByVal NewProtect As Long, _
                                ByVal OldProtect As Long) As Long

so we can say that the malware change the protection of first 5 bytes of the NtCreateProcess API procedure to  execute, read-only, or read/write access to the committed region of pages. see the table in msdn.

fig. 4 - the hooking function

 Then it save the first 2 bytes of the NtCreateProcess API to return it afterwards after the hook function is executed. Then modified  it with jump instruction "0xE9" with the computed delta offset to jump on.

fig. 5 - the original 5 bytes of the NtCreateProcess

fig. 6 - the hooked NtCreateprocess

It is interesting to see how it manually computed the delta offset for the 0xE9 "JUMP" Instruction which is common during the virus era where it compute the delta offset of its virus code within the infected file. :)

IceID compute this offset by subtracting the hook function VA = 0x4011DF  - NtCreateProcess API VA = 0x77A4090C. why subtract? because the hook jump was from the higher address to lower address. Ex. 0x4011DF - 0x77A4090C = 0x889C08D3 - 5 (the size of hook jump mnemonic) = 0x889C08CE.  After hooking it will call again the NtWriteVirtualMemory to change the protection to 0x20 which is execute or read-only access to the committed region of pages.

fig. 7 - computing the jump address

as the hooked API was called it will redirected to the hooked function that will return the original value of the hooked API then decompress the IceID banking trojan code.

fig. 8 - return the original bytes

Then it will create a suspended process  "SVCHOST.EXE", decompressed its code and then inject it to that suspended process to execute.

fig. 9 - the create process and the decompressed code

fig. 10 - injection code

conclusion:
we can see how malware attacker keeps improving their infection chain to bypass AV/Security detection, how malware keeps on evolving and combine the old and new technique to infect and persist to the infected machine and make the static/dynamic analysis time consuming and more difficult.

back to previous analysis

Emotet Spam Push IceID Banking Trojan - Part 1 [Spam & Network Traffic] 

Emotet Spam Push IceID Banking Trojan - Part 2 [Macro & PowerShell]