Where did it all start?
Researchers became aware of the activities of the RTM group in December 2015. Since then, phishing emails distributing the trojan have been sent to potential victims with admirable persistence.
From September to December 2018 the RTM group sent out more than 11,000 malicious emails. The cybercriminals, however, are not going to stop there, as evidenced by the new malicious campaigns that we track as part of our ongoing threat intelligence activities.
In this article, I am going to show how to perform forensic analysis of an image of a computer infected with the RTM banking trojan.
Required background
Let’s imagine that we are not aware of the RTM infection on the computer. The only evidence we have is the fact of compromise, which resulted in a theft of funds. This will make the analysis process more interesting and applicable to other cases as well. I would also like to draw your attention to the fact that in this article I will not focus on reverse engineering of the trojan.
So, all we have is a computer drive image in E01 format (Encase Image File Format). For a start, it would be good to know what is inside, at least the operating system, since it is the operating system and its version that determine the presence of certain forensic artefacts that we have to analyse.
1. Let’s use the mmls utility from Brian Carrier’s Sleuth Kit:
Let’s see what we have here. Several NTFS partitions that look like Windows partitions. We need to be sure of that. Let’s try to find registry files, such as SOFTWARE, for example.
2. Let’s use the fls (from Sleuth Kit) and findstr utilities to find the corresponding entry number in the master file table (MFT):
Now we can copy the file we need for further analysis using icat (from Sleuth Kit):
icat -o 718848 E:\RTM.E01 234782 > SOFTWARE
We have a SOFTWARE registry file from which we can extract the most relevant information using Harlan Carvey’s RegRipper, for example. At the moment, we are interested in the contents of the Microsoft\Windows NT\CurrentVersion section:
We now know that the computer in question ran Windows 7 Professional SP1, which means that we know what forensic artefacts we may encounter and which ones we may need.
Where do we begin our search? Let’s recall Jesse Kornblum’s paradox: “Malware can hide, but it must run”. A good start will be to look for potential persistence mechanisms that can be used by the malware to restart after reboot.
Let’s start with simple things: we will take the NTUSER.DAT registry file with the latest modification date from the user directory (C:\Users\%username%\), and extract data from it using RegRipper. If we want to get the record number of the file we need by means of fls and findstr again, we should add the -p parameter for fls — this will allow the utility to display the full paths to the files. Why do we need that? There is an NTUSER.DAT file in each user’s directory, while there is only one SOFTWARE for the entire system, so in this case it is important to get the record number of a particular file. In general, you do not have to stick to the Sleuth Kit at all; there are more convenient tools like FTK Imager, a free tool, which can be used not only to create forensic images, but also to examine their contents.
Let’s start with low-hanging fruits, the so-called run keys:
The partition was last modified on November 7th, and we see that when a user logs in, the apg.exe file is executed from a very suspicious location. Let’s see what else we can find in the b7mg81 directory:
TeamViewer? That is interesting. Let’s take a closer look at apg.exe and use PPEE:
This looks like TeamViewer and is signed as TeamViewer, so does this mean it indeed is TeamViewer? Seems so, but it’s not that simple. Let’s take a look at the import table:
Right, msi.dll — a file we have already seen somewhere. This is still the b7mg81 directory, not C:\Windows\System32. Judging by the file’s size, it has nothing to do with the original msi.dll, so it is clearly DLL Search Order Hijacking. The operating system starts searching for the necessary libraries from the current directory, which means that instead of the legitimate msi.dll, the one located in b7mg81 will be loaded.
Another interesting file is TeamViewer.ini:
Here is anti-forensics: according to the configuration file, our “TeamViewer” did not keep any logs, and was apparently used as a RAT (Remote Access Trojan). Well, not bad. It is time to find out if it ever started at all.
There are quite a lot of artefacts in Windows that can indicate that executable files have been run. Let’s keep working with the registry, this time with the SYSTEM file. To extract data from it, you can use RegRipper again.
We are interested in ControlSet001\Control\Session Manager\AppCompatCache. Here we will find a list of executable files with paths to them, the dates when they were last modified (according to the $STANDARD_INFORMATION attribute), and a flag indicating whether the file was launched or not:
