Backpedalling emotet Dropper Banking Trojan Ramnit.

My friend @Arkbird_SOLG provided us the sample of emotet dropper and we had reverse it.

Emotet is the banking trojan [ malware ] lurking on the computers around the internet since 2014. It’s been behind the most hacks , covert malware espionage campaigns happens around the world for last few years. It was firstly attributed to being the part of the Russian APT group.

As we been discussion from the our friend , it was concluded that emotet domains remains for the few hours and after the samples being captured in the honeypots and goes in the hands of security researchers the Emotet domains goes down.

Static Analysis & Dynamic Analysis

Fingerprint of sample: Hash value

Other hash’s : SHA1 and SHA256.

Strings : interesting sequence of characters.

Strings present in emotet sample.

Static Analysis: Advanced

Tool: Ghidra

Entry Function: firstly if the arg2 satisfies the condition as true current process
Process ID is being extracted then after directory is being created and as moving further the mutex object is being created and destroyed after that the ownership of the mutex object is being taken away as acc. to the abandon_string _arg only if the two given conditions is being satisfied and if not then the else statement exec. for which the thread is being created then after the handle is being closed with the hObject arg and before closing of if stmt the val 1 is passed in the “store_editor_of_critical_section” then after if arg2 is val is equal equal zero “store_editor_of_critical_section “ is being assigned to store the “critical_section_editor(a,b)” function.

Here’s the code’s of all function along with their function call graph.

Entry Function:

Code of entry function.
Emotet Ramnit dropper full call-graph of Entry Function.

Directory Creator Function:

Code of directory_creator function.

born_&_death_of_mutex_object Function:

Code & functional call graph of born_&_death_of_mutex_object.

critical_section_editor Function:

Code & Functional call graph of critical_section_editor.

placeroflogicbombinheap_by_entering_critical_section Function:

Code of placeroflogicbombinheap_by_entering_critical_section function.
graph of placeroflogicbombinheap_by_entering_critical_section function.

malicious_logic_bomb_inserter Function:

Code of malicious_logic_bomb_inserter function.
Graph of malicious_logic_bomb_inserter function.

Dynamic Analysis: Basic

Tool: RegdllView & RegEdit & VirusTotal & ProcessHacker

VT Scan came up with as the “banking trojan” results.
Dynamic Analysis using RegdllView and RegEdit.

Basically here are few registry files that are being used as the malicious intent by emotet. Whereas below you can easily see the some malicious .dll file as well as the privileges used by emotet.

.dll used in the banking dropper ramnit[ malw. ] .
Process hacker shows the “preview.exe” being executed in memory.

Dynamic Analysis: Advanced

Tool: Immunity Dbg

Here’s the modules being loaded as the execution of emotet occurs in the memory.

dynamic linked library(.dll) used for loading the emotet loader in the memory.

Firstly let’s focus on what happens when the cryptbase[.]dll is being loaded in the memory. As the execution of emotet happens , it loads the cryptbase.dll which is basically the dll used by software installed on Windows so that the software runs properly in memory, but as here it is being used for the loading malicious initial loader in the memory along with the obfuscated code into the memory. Here’s are the names of functions being imported by cryptbase[.]dll . As it can be easily seen that modules that’s being loaded in the memory are the linked to the Windows Core API [ Application Programming Interface ].

loading of the Win API hooking by the Cryptbase.dll.

In the initial execution, changes are being crafted to occur in the critical section like deletion, creation although the information about the Current process with its process-id ,thread-id, last error,process-heap,Tick-Count, SystemTimeAsFileTime, process address are being gathered by entering into the critical section using WIN core API hooking technique and by taking control of Device I/O Control then after the Critical Section is being left by calling the LeaveCriticalSection function.

modules imported by cryptbase.dll.

After that the ntdll is being imported which is being used for the loading the fake I/O Driver into the memory which is the form of the software of bytes of binary being transfer as the heap & as we can see that ntdll.memcpy and ntdll.memset is being loaded into the memory where the ntdll is the entry point to load the Windows driver into the memory. As we see the executable in the hexdump it shows that firstly the ntdll[.]dll is being loaded in the memory then after the calls for different functions is being made for allocating heap for the fake driver.

hexdump of memory showing the information being fetched after cryptbase.dll exec. .

Similarly, here’s the imports and exports of next SspiCli.dll.

SspiCli.dll imports and exports.
text and hexdump view of SspiCli.dll.

After the exec. of this .dll the exec. of payload is being loaded into the memory.

malicious payload exec.

sechost.dll carried out the malicious activities with encrypted network traffic
communication with the C2 server from the infected victimized client side.

imports and exports of svghost.dll .
malicious activities by sechost.dll.

Network traffic Analysis:

Tools: Wireshark & Spiderfoot

Wireshark capturing shows C2 communications.
Spiderfoot showing the C2 domain communications.

IOC’s:

That’s all for today!

Honey. Malware Analyst. I write blogs related to threat intelligence , malware analysis, APTs , network intrusions and incident responding.