TrickBot Analysis and Forensics | By Siddharth Sharma

TrickBot Analysis and Forensics

This blog is about the analysis of a recent trickbot variant uploaded on malware traffic. The sample was having a trickbot server which was reported recently, also having a unique feature that is UAC bypass using CMSTLUA COM interface. The sample had EMOTET malware signatures as well, which I found during its injection activity.In this post we will do:

1.Dynamic Analysis

2.Static Analysis

3.Memory Forensics

Dynamic Analysis

The sample wasn’t packed and neither it had AntiVM or anti-debug functionality. So, simply I ran that to observe its activity at process level like injection or spawning new process, what I found was it first it injects itself in explorer.exe and then it creates another process by the same name with elevated privileges. Following are the screenshots of observation:

Using dllhost.exe to execute via COM and Privilege escalation:

Spawns the new process with elevated privileges.

Downloads pwgrab32 tool (Appdata folder) which is generally used to grab the sensitive credentials stored in the system:

On checking properties and strings of the process I found:

That’s clear it targets stored browser credentials.

Also, when I looked for network connections, I found one IP address which belonged to a trickbot server:

Below is the same IP being reported in mid April 2020.

Static Analysis

Trickbot as we know has been there since long, and this modular banking trojan, with time, comes with new features and new techniques are being used by adversaries in an updated variant, in this case while doing advanced static and dynamic analysis, I found following features:

Starting with looking the sample in IDA, found some resource related WinAPIs:

Checked to see what was there in the resource section of this malware:

It seemed to be encrypted so switched to IDA again to see if there is any loop or decryption mechanism being used:

Found nothing and no VirtualAlloc but one thing was here to note that GetCurrentProcess WinAPI was used with memcpy where I guess it copies the code at a certain allocated buffer, so decided to look it in more deep using x64dbg.

Started with putting breakpoints on resource APIs:

As we can see above, its clear that the malware injects the code which is there in its rsrc section.

Going further, to view its activity at deeper level, decided to put a breakpoint at GetCurrentProcess, a point to note here is according to its MSDN, it has no parameters, so looking at its return value that is by following EAX in dump would give an idea what it tries to do:

As we saw in dynamic analysis, it first looks for explorer.exe as shown above.

Finally, we got some clue that it uses Microsoft Cryptographic Service Provider to decrypt the contents of its resource in the memory, moreover when it was checked in detail, i found RSA. For this point I decided to look this activity via memory forensics (later in the post) that what the code was responsible for.

While analysis, after the decryption step, when the break point was hit I observed that it used certain kind of interface as shown below:

This is actually UAC bypass using CMSTPLUA COM interface, a code snippet shows this below:

Above pop up shows that the malware is trying to run again as a new process, we saw in dynamic analysis I guess with elevated privileges.

Above pic shows it creates a new process, on observation I found that the process which was created initially, vanishes.

Memory Forensics

Basically, I took two dumps, one after 30 seconds and another after a minute or so, following were the observations and differences:

For dump1, when I checked for malicious processes, as expected found two processes of this malware (highlighted above), first one having PPID 276(explorer.exe).

For dump2, I found one malicious process that is as said above, initial process vanishes.

Then I used malfind to see if there is any code injection, found some code being injected into the running malicious process of dump1.

Moreover, in the dump1, there was a code injection in explorer.exe process as well.

After this, on checking the network activities using netscan:

For dump1, there was no network connection that means no connection initially by the malware.

But for dump2, as can be seen above, found the connection with the IP address belonging to Trickbot server.

Following shows the comparison of the privileges of both the dumps:

Less privileges as we can see above,

But for new process that is dump2, we have a lot of privileges enabled:

Moreover, when I dumped the injected code running in the new elevated process, then uploaded that on Virus total and interestingly found EMOTET signatures as shown:

This was the analysis of this new variant of trickbot, supposedly, the encrypted code in the resource section of the malware was responsible for privilege escalation purpose which we saw was done using dllhost via COM interface then after that the malware connects to the trickbot server and starts its malicious activity using pwgrab tool after grabbing it from the server.

Behaviour graph: