Note, incident handlers do not necessarily need to go very deep into malware analysis. It is enough to be able to extract IoCs fast in order to be able to respond to an incident quickly and effectively.
WARNING! Be very careful when you play with real malware. Ensure that you have a safe setup that is completely separated from any networks and systems that are outside the scope of the tests. Also ensure that you have patched your virtualization platform. New sandbox escape vulnerabilities are discovered frequently.
Initial analysis
In my lab I have Flare VM, which is a customized, Windows-based security distribution. It is especially useful for malware analysis and incident response. If you are setting up an environment for malware analysis, I would recommend you to go with Flare VM. To get Flare VM running, you need a Windows virtual machine. Microsoft provides a Windows 10 image for developers that you can use for this purpose. After the Flare VM installation is completed remember to take a snapshot so that you can return to the clean install when needed.Note that the Flare VM installation can take hours.
Once you have the environment setup, you can download the trickster practice malware from this link. Then remove all network connections to isolate the virtual machine from the Internet and your host machine.
Strings
First, let's check the strings on trickster.exe. We will do that with a program called FLOSS (FireEye Labs Obfuscated String Solver). It automatically detects, extracts, and decodes obfuscated strings in Windows Portable Executable files. FLOSS is installed on Flare VM by default. Open cmd.exe and execute the following command:floss trickster.exe > tricster_strings.txtRead the strings with the following command (or... use notepad):
type trickster_strings.txt | moreWe notice that there are not many readable strings available. This observation suggests that the file is encrypted or otherwise obfuscated and that FLOSS was not able to deobfuscate all the things. That will make static analysis hard. Therefore, we will do dynamic analysis. In other words, we are going to infect our FlareVM with the malware.
Creating a baseline with Autoruns
Before running the malware, let's run Autoruns. It is a startup monitor from system internals that gathers comprehensive information of auto-starting locations to let you know which programs in your system are configured to run automatically. Autoruns gathers information for programs and drivers in your startup folder, and Run, RunOnce, and other Registry keys. It also has a handy "Hide Signed Microsoft Entries" option, which helps you to zoom in on third-party auto-starting images that have been configured to start automatically. As malware will usually setup itself to start automatically, Autoruns is a good tool for detecting such malware initiated changes in your system.Start Autoruns from (administrator) cmd.exe by typing "autoruns". After you have started Autoruns and it has collected required information, it will state "ready" in the bottom of the process window. This information is the baseline of the programs setup to start automatically in your clean system. We will soon compare it to the infected setup. Save the information into Autoruns file into the desktop.
Next, run trickster.exe as admin and let it infect the machine. Once it has ran, go back to Autoruns. Hit refresh and wait for it to complete. Then navigate to the file options and and choose compare. Choose the baseline file created just before to see what has changes after running the malware.
We see that trickster has created a new scheduled task in Task Scheduler.
 |
| Comparing the baseline to the current state after running trickster.exe. |
Investigating the scheduled task
Let's open task scheduler to see what the task does.In task scheduler under actions of a task called "services update," one can see that the scheduled task will run a process usjdltufs.exe under C:\Users\IEUser\AppData\Roaming\winapp\ (or %AppData%\winapp\).
 |
| Actions for scheduled task created by Trickster. |
Note.
See this list for recognized environment variables on Windows. They are used to identify folders that applications use frequently but may not have the same name or location on every computer.
If you want to see where a specific environment variable points in your system, open cmd.exe and echo that particular environment variable:
echo %AppData%
We also notice that this process will be ran every three minutes. This seems like behavior that a beacon would execute. Under this suspicion we should investigate possible network traffic generated by the usjdltufs.exe process.
But first, let's use Floss to check if we can find any nice strings from the usjdltufs.exe. Unfortunately, like trickster.exe, usjdltufs.exe also seems to be encrypted/obfuscated. The strings do not reveal much.
Note.
Encrypting code is easy to do and it will make the malware analysis harder. However, encryption might increase the chances of the file being caught with different automated detection tools. Features of a packed/encrypted files include: a small number of imported functions, a high entropy level, or suspicious section header characteristics. Legitimate programs are rarely encrypted/obfuscated. Therefore, sometimes it might be beneficial for malware creators to leave the file unencrypted.
CreateFile events and files associated with the malware
We know that usjdltufs.exe is located in the folder %AppData%\Roaming\winapp. We should check this folder to see what other files are potentially created by Trickster. In this case, there are not many files because the second stage was never loaded. This is a practice malware and it does not really contact a real CnC channel. In real life scenario the files created by a malware could be used as IoCs. See the below screenshot for CreateFile events monitored for usjdltufs.exe by Process Monitor. Note that the "CreateFile" event presented by Process Monitor can mean an attempt to open an existing file or to create a completely new file. You need to look at the Detail column to deduce what the intention was.In below screenshot, among other CreateFile events, we can see Trickster trying to open scvhost.exe in C:\Users\IEUser\AppData\Roaming\winapp\. This is very suspicious. Svchost.exe is a Windows processs that should be located in C:\Windows\System32\ folder.
 |
| Procmon file system activity events for usjdltufs.exe. |
In real life incident response scenario it might be useful to gather some OSINT and Google for the names of those files/folders to see if someone else has made an analysis of the malware you are investigating.
Network based analysis
If this program is a beacon as we have guessed, we should be able to see some network traffic originating from it. Let's do some further analysis on the potential network traffic of the program to verify whether this is true or not.
Unfortunately Trickster will not initiate CnC communication if there is no Internet connection available. Trickster is a de-weaponized practice malware created for education purposes, but it is based on a real malware called Trickbot. Trickbot conducts different checks to evade malware analysis. Those checks are still present in Trickster, and my lab did not pass the tests because of my network configuration. Hence, I had to enable Internet connection for the Flare VM.
Wireshark and Process Monitor
If your Flare VM has a firewall and AV turned on, turn them off first. We will do the network analysis on multiple levels. We will use Procmon to follow the process inside the VM. Simultaneously we will setup Wireshark on the Flare VM to have a peek inside the actual network packets that the malware sends out.Open Wireshark and Procmon. Procmon will immediately start logging everything that happens on the VM. Filter Procmon for only the usjdltufs.exe process. Go to Wireshark, choose the right network interface and press the blue shark fin on the upper left corner to start logging network traffic.
Set the time display format on Wireshark to be the same as on Process Monitor (Time of day). This will allow you to follow if the events correlate. In other words, do you see suspicious network traffic on Wireshark at the same time as you see the usjdltufs.exe process start on Process Monitor?
Once the two monitoring applications are setup, run Trickster as administrator. Wait for a few minutes for the beaconing to start. Once you see usjdltufs.exe running on Process Monitor, you should soon see the connections on Wireshark, too. Before investigating further, you can stop both monitoring applications from collecting more information to save computer resouces.
Here are some screenshots to show what you should be able to see.
 |
| Trickster beaconing started immediately after the scheduled task ran usjdltufs.exe. |
 |
| Beaconing packet and Procmon correlation |
A bit something about using IDA and OllyDbg
Restore a clean snapshot of the flare VM. Then let's see what we can find out with OllyDbg and IDA. IDA is an interactive, programmable, extendible, multi-processor disassembler and debugger. OllyDbg is a debugger, especially useful on binary code analysis when source code is unavailable.Note.
Disassembler is a software that transforms machine code into human readable assembly language. Debuggers allow users to view and change the running state of a program. Additionally, there are decompilers that take a binary program file as input and output the same program expressed in a structured higher-level language.IDA is the industry de-facto standard tool for malware analysis. The pro version license is expensive, but there is a free version available that has limited functionality. That IDA Free is already installed on the FlareVM. Let's open the malware with IDA Free.
Open IDA and drag and drop usjdltufs.exe onto IDA. Choose PE file, which is the file type for trickster. After the file loads, on the left-hand side in the IDA view-A you can see the memory visualization and assembly code of the malware. This is the best guess IDA was able to create based on decompiling usjdltufs.exe.
The fact that the memory visualization bar within the IDA GUI View-A found only a little encoded/executable data suggests that the program is packed. Usually normal unpacked executables have several blue sections with readable data. See comparison of the IDAs memory visualization of the packed original image and that of the image dumped from memory in screenshots further below.
IDA has a lot of functionalities that are outside the scope of this article. Now we are only going to take a peek into what functions Trickster imports. On IDA, change to the imports tabs. I briefly explained what imported functions are in my previous article. See screenshot further below for functions imported by usjdltufs.exe. There seems to be 45 imports in total.
The imports are different types of functions the program (presumably) calls at some point during its execution. From these functions we can deduce for example that Trickster opens and closes registry keys, and that it can create files and cmdline arguments. By scrolling through imported functions we can deduce something about the functionality of a program.
Let's see what we can deduce using OllyDbg.
Open the usjdltufs.exe with OllyDbg. Like with IDA, you will see the assembly code of the PE file as a best "guess" that OllyDbg is able create by decompiling and running it step by step.
Malware often tries to prevent debuggers from running it to stop reverse engineers from analyzing them. Let's see if this is the case with usjdltufs.exe. Play the program by pressing the little play icon on the top bar. We can see that it runs very quickly and nothing really seems to happen. This most likely means that the malware has detected that it is being ran in a debugger and stopped execution.
Creating a clean hash database and dumping the process from memory
The way to go around this is to dump the process from memory and then analyze it. Let's try that with trickster.exe. This works because a program (if obfuscated) has to deobfuscate itself before it can run. To do dump the process from memory we will use a program called Process Dump. It is not included by default in FlareVM, so you have to download it through that link. Process Dump is ran from the command line.First, let's create a clean hash database. It works as a comprehensive good baseline that can be compared to an infected machine to see what has changed in the system. Open cmd.exe as an administrator, navigate to the folder where you have the Process Dump executable, and type in the below command.
pd64.exe -db gen
This will calculate a hash and store it in a database for all files under %WINDIR%, %HOMEPATH%, C:\Program Files\, C:\Program Files (x86)\, and for all modules in all running processes. My FlareVM calculated hashes for 13 198 files and modules in total.
Modules are executable files or DLLs. Each process consists of one or more modules.
After Process Dump has finished creating the hash database (it can take 5-10 minutes), we can go for Trickster. Type in the following command (note that you have to have db64.exe and trickster.exe in the same location), but do not execute it yet!
pd64.exe -p trickster.exe
Before running the command, we will have to start Trickster as administrator. After starting Trickster, we will quickly change into the cmd window where we have the Process Dump command waiting and execute it. Trickster wont run too long, so this is why you have to be quick about it. This command will dump the trickster program straight from memory unpacked so we can analyze it better. On my VM it was saved on the same folder as "trickster_exe_PID1c5c_trickster.exe_400000_x86.exe".
Opening the dumped process with IDA
Let's open trickster_exe_PID1c5c_trickster.exe_400000_x86.exe with IDA to see what we can find and to compare original image to the one dumped from memory. There are at least two new functions that were not present last time; Sleep and GetTickCount. See below screenshots for comparison of the two imports and the latter one for comparison of the logical flow of code. |
| Imports from the original image on the left and imports from the same image dumped from memory on the right. |
 |
| Program flow of the original image on the left and from the same image dumped from memory on the right. |
Note that the Trickster that was dumped from memory contains less imports than the original one. This is because the image that gets dumped from memory only contains content from the running process and does not necessarily reflect the original state of the binary file at rest on disk*. Notice also that IDA can make a much "richer" guess about the program flow using the image that was dumped from memory.
Double click the Sleep import and IDA will show where the function is executed in the code. See below screenshot.
 |
| View from IDA. Sleep function in action as seen in trickster.exe which was dumped from memory. |
In the above screenshot you can see that the value 1388h is pushed into the stack before Sleep is called. 1388 is hexadecimal representation of 5000. And as is stated in the screenshot, that is a value in milliseconds, which is equal to 5 seconds. And it is the amount of time the process will sleep.
The program uses the GetTickCount function to keep track of time when it is sleeping. It does this to give time for some of the conducted actions to finish before continuing to the next step. It will first launch itself, then wait, create the folder winapp, then wait, copy usjdltufs.exe in there, then wait, run usjdltufs.exe, then wait, and so on.
This is just an example of what kind of things you can find out doing reverse engineering. It is all there in the assembly code.
References and further reading
https://www.udemy.com/malware-analysis/https://malwarechallenges.com/2017/08/18/trickster-exe/
https://docs.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables
http://split-code.com/processdump.html
https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns
https://www.cisecurity.org/white-papers/security-primer-trickbot/
https://reverseengineering.stackexchange.com/questions/4635/whats-the-difference-between-a-disassembler-debugger-and-decompiler
https://www.hex-rays.com/products/ida/overview.shtml
http://www.ollydbg.de/
https://social.technet.microsoft.com/Forums/en-US/f648d4bf-7bbc-4f17-9f01-c81ea2be1ae7/procmons-createfile-interpretation?forum=procmon
https://docs.microsoft.com/en-us/windows/desktop/psapi/module-information
*The IDA Pro Book, 2nd edition
https://stackoverflow.com/questions/4584089/what-is-the-function-of-the-push-pop-instructions-used-on-registers-in-x86-ass
https://www.fireeye.com/blog/threat-research/2016/06/automatically-extracting-obfuscated-strings.html
https://dl.packetstormsecurity.net/papers/virus/malware-reverse-part-1.pdf
