Introduction
In this post, we will go through and analyze the TrickBot malware. This family of malware was infamous for many years for its prevalence and effectiveness, often seen in combination with Ryuk and Conti ransomware [001]
Due to the many steps this malware takes to be evasive this post will be split into three different sections, this one where we will look at the series of initial droppers. The next one is where we look at more droppers, the agent, and the persistence mechanism. And finally closing off by looking at one of their “modules” used for Active Directory domain reconnaissance.
The intention behind this series of blog posts is to dive into malware analysis methodology, and hopefully give some insights into how you can look at code to figure out what is happening. And also how this process looks like in practice.
Samples
As you will see at the bottom of this post I unfortunately was unable to find the original malware dropped by the stagers, and in the next posts will therefore use substitute samples, but the main points should be the same
The sample used for this first stage of analysis is a .doc file from Malware bazzar [002].
- 1bmd.doc — 23f98d6ff7329618994ac0f3e2b3a394
As Trickbot is an older malware much analysis has already been done on various samples, this is quite nice for starting out as it means that you can check your work against what has been observed by others [003] [004].
Methodology
As for the structure of this series, I’ll be going through each step of the different phases of execution. Starting with a general overview of the actions performed. For each of the different phases (i.e. programs or scripts used by the malware) we will have a section with Initial triage, followed by static and dynamic analysis where appropriate.
Lastly, I’ll provide a conclusion, present IOCs, and give a list of all references used.
Phishing Doc
Starting off we are going to be taking a look at the initial .doc file which looks like the initial phishing document used to lure victims into running the malware. Notice the .doc extension meaning that it uses the old Microsoft format, which means that it does not need the .docm extension, which is needed in newer versions to allow for VBA macro execution.
We see the sense of urgency used to try to trick a user into getting the macro executed. An interesting note is the use of user action to start code execution, this is likely done to evade detection as almost all EDR/AV till flag files which run code on being opened.
Initial triage
Now that we know that the file is capable of running code and that this will be run through a user action. let's look at what's hiding inside, for this I'll use Olevba from Oletools [005] in order to get an idea of the VBA code used in the file. This tool extracts the VBA code from an office document and also applies its own set of triage rules for the detection of suspicious behaviour. Immediately the tool comes back and shows several alerts for suspicious patterns.
It does not take long looking through the output before we see how the macro executes the next step. Here we also get the name of the file dropped and the method of execution. Additionally, we see mentions of a function that converts from ASCII to hex, this will be relevant in just a moment.
Next, to try to get an idea of what the doc might be doing I run strings to see if anything interesting is in the document, immediately a huge blob of what looks like hex data shows up.
Running this through Cyber Chef to get the ASCII representation immediately proves this suspicious as the first bytes is an MZ header (4D5A — mz) [006].
Doing this again shows what is clearly a PE file, which again would match with the behaviour identified earlier.
Next on the agenda is the extraction of the embedded executable. Let's use strings to extract the file, xxd to decode it, and see if we get a complete binary. And it looks like we were successful.
It is also worth noting here that the code base of the .doc is very large and includes a lot of what looks to be legitimate VBA code, likely done in an effort to hide functionality.
Summary
This first part of the malware is pretty simple, it runs and extracts a binary file which is double HEX encoded. The extracted file is then run using rundll32. The following IOCs were found:
- C:\Users\Public\Documents\1.mstsc
- rundll32 C:\Users\Public\Documents\1.mstsc, dpi360ntW
Since this probably changes for each document a more general IOC can be derived:
- rundll32 C:\\Users\\Public\\Documents\\[a-zA-Z0–9]*.mstsc, [a-zA-Z0–9]*
Now that we have the embedded file extracted let's move on to analysing it and see what it Does.
1.mstsc: Embedded binary
Initial triage
Starting off let's inspect the binary to confirm if it is to be run as a DLL, looking at the NtHeaders we see this.
This can further be confirmed by looking at the exported functions. This matches the distinct name of the function called by the .dco via rundll32.
Next, let's give the strings of the binary a look.
Strings
As with the .doc, we quickly see some interesting strings.
Based purely on the size of the blob this might be another binary.
Static Analysis
Now let's look at the binary itself and see if we can figure out how the strings found previously are used.
Looking at the call order of “sub_10001000” we see that the string location of the big encrypted blob is pushed to the stack. And looking at the function itself it looks an awfully lot like a decryption algorithm.
After the decryption function a called, we get a call to GetTempTathW followed by the string “2.ps1” before CreateFileW and WriteFile. So I'm guessing the program writes “2.ps1” to the temp directory.
Next, the program gets the systems directory together with a CMD command to run PowerShell. A small sleep is then called, potentially for AV/EDR evasion, and then a function is called where CreateProcessW is called, so we can assume that the dropped file is then executed by PowerShell coming from CMD.
Then the program exits. So now what? do we want to create a custom decryptor for the PowerShell script? … Nah, let's just load the file in a debugger and cancel the execution after the file is already written for us!
Dynamic debugging to extract the encrypted file
To load the .dll into a debugger (x96dbg) we can't just point the debugger at the file and click run like we are used to, instead, we have to run it via rundll32. To do this follow the steps outlined in this guide [007] [008].
Next, we run the .dll until the address of the entry point and then place the breakpoint on the entry point of the function.
Then we resume execution until we hit the breakpoint for the exported function.
Since we are just interested in the file created let's just place a breakpoint on CriteFileW/A API call and see if the file is created… and success we get the expected file created at the location we expected.
The file is empty, so we continue execution until the file contents have been decrypted and written to disk.
Summary
The purpose of this executable is simple, it just extracts an embedded file and decrypts it before writing it to disk. the IOCs for this would be the creation and execution of PowerShell files in the users %temp% directory:
- %temp%\\[a-zA-Z0–9]*.ps1
2.ps1: PowerShell dropper
Now let's move to the PowerShell script that was just created. Just quickly giving the file a look through we can see that this is an additional dropper, that uses the PowerShell web client to get a file.
Next, it looks like it might be checking for different servers where the payload might be hosted:
Extracting all the URLs from the file we get the following list:
- httx://91.92.109.142/roben.png
- httx://192.99.255.33/images/roben.png
- httx://185.183.98.15/roben.png
- httx://83.138.53.103/images/roben.png
- httx://172.96.189.216/images/roben.png
Furthermore, we also get the path and file name of the next file to be executed:
checking if this works, I just place breakpoints on all function calls and see what hits. I was not able to get the file from any of the domains.
Since I was unable to find the original executable referenced in the dropper, let's top the analysis here and save the analysis of the assumed main c2 agent for another post.
Summary
The functionality of the script is similar to the ones before it, with the difference that this stage retrieves the file from the internet instead of using an embedded resource. Its IOCs are, file creation and execution:
- %temp%\\[a-zA-Z0–9]*.blob
and network connections to:
- httx://91.92.109.142/roben.png
- httx://192.99.255.33/images/roben.png
- httx://185.183.98.15/roben.png
- httx://83.138.53.103/images/roben.png
- httx://172.96.189.216/images/roben.png
Conclusion
So now that we have seen enough different droppers for the next long while, what did we learn? We learnt that the Trickbot sample studied here uses a bunch of different ways of execution and files in an attempt to stay hidden. All these different droppers and mechanisms of hiding files seem like a clever way to obfuscate intent and make sure that if any part of the chain is caught, the actual malware is not what is getting flagged, rather the disposable droppers will be the ones sacrificed. In the next post, we will be looking at: you guessed it! more droppers! … and the actual meat of the malware the C2 agent and persistence mechanisms.
IOCs
File names & MD5 Hashes
- 1bmd.doc — 23f98d6ff7329618994ac0f3e2b3a394
- C:\\Users\\Public\\Documents\\1.mstsc, dpi360ntW — 89e0b67600d95c99490e4fc992a50510
- %temp%\\2.ps1–767C8910A5A27E1712206E6DEA4FE3D5
- %temp%\\2.blob — N/A
Network
- httx://91.92.109.142/roben.png
- httx://192.99.255.33/images/roben.png
- httx://185.183.98.15/roben.png
- httx://83.138.53.103/images/roben.png
- httx://172.96.189.216/images/roben.png
MITRE
- T1566 — Phishing
- T1059 — Command and Scripting Interpreter
- T1204 — User Execution
- T1218.011 — System Binary Proxy Execution: Rundll32
- T1140 — Deobfuscate/Decode Files or Information
- T1564 — Hide Artifacts
- T1656 — Impersonation
- T1104 — Multi-Stage Channels
References
- [001] — CISA advisory — https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-076a
- [002] — Malware sample — https://bazaar.abuse.ch/sample/8ae73acc01f72c1164324e44045cd74256c3b4be606c0932717a2b593e8c5169/
- [003] — TrickBot malware analysis report — https://www.sentinelone.com/blog/trickbot-technical-analysis-banking-trojan-malware/
- [004] — TrickBot malware analysis report — https://www.securityartwork.es/wp-content/uploads/2017/07/Trickbot-report-S2-Grupo.pdf
- [005] — https://github.com/decalage2/oletools
- [006] — file signatures — https://www.netspi.com/blog/technical-blog/web-application-pentesting/magic-bytes-identifying-common-file-formats-at-a-glance/
- [007] — [Reverse Engineering Tips] — Analyzing a DLL in x64DBG — https://blog.securitybreak.io/reverse-engineering-tip-analyzing-a-dll-in-x64dbg-b3005d516049
- [008] — https://www.youtube.com/watch?v=BN_xtMKbWxU
