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.

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.

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.

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:

Great, our file has been launched at least once. So, we have a "pivot point". We know that on November 7th, TeamViewer appeared on the computer drive. It did not keep logs, and most likely was not visible to the user since instead of the legitimate library it downloaded the one that is located in the same directory as the TeamViewer itself.

It's time to start building a timeline. I think what we can use the Sleuth Kit again. We will start with the fls utility:

fls.exe -m "C:/" -o 718848 -r -z GMT D:\RTM.E01 > bodyfile.txt

Now let's use mactime to convert the obtained file to a timeline:

mactime.pl -d -b bodyfile.txt > timeline.csv

It is very convenient to analyse timelines in Timeline Explorer by Eric Zimmermann. Our timeline will only include file system events. If you want it to include changes to the registry, logs, etc., you can use plaso. I personally use it very rarely, since data processing takes a very long time and the result is often quite redundant.

Let's go back to the timeline. The b7mg81 directory was created on November 7, 2018 at 13:59:37:

Two seconds before that the file 21DA.tmp was created:

If you look for its checksum, on VirusTotal for example, you will get quite interesting results.

It looks like our RAT was unpacked from this file. Let's move on.

The LocalDataNT directory, which has quite interesting files inside, was created even earlier. Let's take a look, at WinPrintSvc.exe, for instance:

Remote Utilities is another remote management tool. Here is another suspicious file created a few seconds earlier:

Let's see its checksum:

Several antivirus products identify it as RemoteAdmin. Apparently, this is the source of Remote Utilities. Let's see if the detected RAT was launched. This time we will use the AmCache.hve registry file from C:\Windows\AppCompat\Programs (RegRipper will help us get data from it in a comprehensible format):

As you can see in the illustration, AmCache helps us get not only the date of the first launch, but also the checksum of the file.

So, we have two RATs, but where did they come from? Good question! If you continue scrolling through the timeline, you will see traces of a rather suspicious directory and file being created:

Despite the strange extension, fnbfdnja.hej has a familiar header:

What will a checksum search on VirusTotal show us? Here it is:

As you can see in the illustration, some antivirus software detects our file quite definitively — we are dealing with RTM. VT can help us a little more. If we look at the "Relations" tab, we will see this:

Looks like we have found the culprit. It is "Документы за октябрь.exe" ["October documents.exe"]. Or maybe not: the name associated with our file is different, although the checksum is the same. Okay, here is another .exe, so we need to look for launch traces again. I personally really like working with the registry, so I will use the already known NTUSER.DAT file and RegRipper again. This time, we will take a look at UserAssist, from which we can get the names of and paths to the files, the dates of their last launch, and the number of times they were launched. The file "Документы за октябрь.exe" is not visible, but another file is:

C:\Users\%username%\Desktop\Документы среда.exe

Great! This seems to be what we need. There is a small problem, however, — there is no such file in the proper location. Let us go back to the timeline. Here is what happens after the file fnbfdnja.hej is created:

The files in the Temp directory may belong to RTM, but they are not the ones we are interested in. We are interested in the files $R6K21RQ.exe and $I6K21RQ.exe. This is what the files placed in the Recycle Bin look like: the first one contains the actual data, while the second one contains metadata. If we look at the contents of $I6K21RQ.exe, we will immediately see the path to the file we are looking for — «Документы среда.exe".

It is time to see how VirusTotal will identify it by its checksum:

We see a signature we already know — and it's RTM. As it turned out, the checksum of our file coincided with the checksum of "Документы за октябрь.exe". What's more, VirusTotal knows a few more files with the same checksum:

It would be good to get some network indicators of compromise. We do not have a memory dump, nor do we have a network traffic dump, so what do we use? A paging file! But how do we find a needle in a haystack? VirusTotal will help us again, this time with the "Behavior" tab:

Looks like a C&C, doesn't it? Let's see if there is anything similar in our paging file (pagefile.sys). Of course, there is:

So, we have confirmed that our file interacted with 185.141.61[.]246. Let's try to find more network indicators. One of the RATs was TeamViewer, so we will try to find something similar to its ID. To do this, you can use regular expressions, for example.

Perfect! We have another network indicator — 195.123.219[.]87. Of course, paging files are suitable not only for searching for network indicators. If we go back to the "Behavior" tab on VirusTotal, we will see that our file creates tasks in the scheduler. If we search for the string "fnbfdnja.hej", here is what we will find:

The created task launches fnbfdnja.hej via rundll32.exe.

Well, it's time to wrap this up. Let's find out where the file "Документы среда.exe" file came from. We already know that it is RTM, and since it is RTM, the most likely vector of infection is a phishing email. In this case, the victim used Microsoft Outlook, so we found the .ost file with mail data in its usual location, and in it — the exact phishing email we have been looking for:

On a final note, let us check one more interesting artifact. If we go back to the NTUSER.DAT file and look at the value of the Shell parameter in Software\MicrosoftNT\CurrentVersion\Winlogon, here is what we will see instead of the usual "explorer.exe":

This means that instead of starting Explorer after the user logs in, the system will shut down and finish its work, just like I am finishing this article now.