In the footsteps of RTM. Forensic investigation of a computer infected with a banking trojan

Quite a lot was written about the RTM banking Trojan attacks on accountants and financial directors, including Group-IB experts , but in the public field there has not yet been a single case study of RTM-infected devices. To correct this injustice, Oleg Skulkin , one of the Group-IB's leading computer forensics specialists, gave a detailed account of how to conduct a forensic investigation of a computer infected with a banking trojan as part of an incident response / investigation.

How it all began

Researchers learned about the activities of the RTM criminal group in December 2015. Since then, phishing e-mails that distribute this Trojan, fall into the electronic mailboxes of potential victims with enviable consistency.
')
As you already know, from September to December, the RTM group sent out over 11,000 malicious emails. Cybercriminals do not intend to stop at what has been accomplished, as evidenced by all the new mailings that we record both on sensors that protect our clients and in the framework of collecting data on current threats.

In this article I will tell you how to conduct a forensic investigation, or simply forsensiku, of the image of a computer drive infected with a RTM banking trojan.

Necessary introductory

Imagine that we do not know about infecting a computer with RTM, but we have only the fact of compromise, which resulted in the theft of money - this will make building the research process more interesting and also make it applicable to other cases. I also want to draw attention to the fact that in this article I will not dwell on the reverse engineering of the Trojan: firstly, this is not the competence of the criminologist, secondly, my colleague, Semyon Rogachev, wrote about this in detail in Habré .

So, all that we have is an image of a computer drive in the “E01” format (Encase Image File Format). For a start, it would be nice to know what's inside. At a minimum, the operating system, because it is from her and her version, of course, depends on the presence of certain forensic artifacts that we have to investigate.

1. Use the mmls utility from the Brian Carrier’s Sleuth Kit package:



What do we have? Multiple NTFS partitions similar to Windows. We need to make sure - we will try to find registry files, for example, SOFTWARE.

2. Use the fls (the Sleuth Kit) and findstr utilities to find out the corresponding record number in the main file table (MFT):



Great, now we can copy the file we need for further analysis using icat (the Sleuth Kit):

icat -o 718848 E: \ RTM.E01 234782> SOFTWARE

So, we have the registry file SOFTWARE, extract the most significant information from which we can, for example, with the help of RegRipper Harlan Carvey. At the moment, we are interested in the contents of the Microsoft \ Windows NT \ CurrentVersion section:



Now we know that the computer under investigation was running Windows 7 Professional with SP1, and therefore we know what forensic artifacts we may encounter and which ones we may need.

Where to start our search? Recall the Jesse Kornblum paradox: "Malware can hide, but it must run." A good start could be a search for potential pinning mechanisms in the system that allow malware to restart after restarting the computer.

Let's start with a simple one: take the registry file NTUSER.DAT from the user's directory (C: \ Users \% username% \) with the latest modification date and extract data from it using the same RegRipper. If we again want to get the record number of the file we need with the help of fls and findstr, then we need to add the –p parameter for fls - this will allow the utility to output the full paths to the files. Why do you need it? The fact is that the NTUSER.DAT file is in the directory for each user, and SOFTWARE is one for the entire system, so in this case it is important to get the record number of a specific file. In general, it is not necessary to use the Sleuth Kit, there are more convenient tools, for example, FTK Imager - a free AccessData development tool that can be used not only to create forensic copies, but also to study their contents:



Let's start with low-hanging fruits, the so-called “run keys” :



So what do we have? The partition was last modified on November 7th, and we see that when a user logs in, the apg.exe file is launched from a non-standard location. Let's see what else can be found in the b7mg81 directory:



TeamViewer? Interesting. Let's take a closer look at apg.exe - let's use PPEE :



Looks like a teamviewer, signed up as a teamviewer, does that mean teamviewer? It looks like it. But it's not that simple. Let's look at the import table:



So, msi.dll, somewhere we have already seen this file, and this is not C: \ Windows \ System32, but the same b7mg81 directory. Judging by the size, it has nothing to do with the original msi.dll, which means it’s available - Search Search DLL Hijacking : the operating system starts searching for the required libraries from the current directory, which means that the legitimate msi.dll will be loaded in b7mg81.

Another interesting file is TeamViewer.ini :


And here is the counter-forensic: judging by the configuration file, our teamViewer did not keep logs, and, apparently, was used as a RAT. Well, not bad. It's time to find out if it started at all.

There are a lot of artifacts in Windows that indicate the launch of executable files. Let's continue to work with the registry, this time with the SYSTEM file . In order 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, dates of the last modification (according to the $ STANDARD_INFORMATION attribute), as well as a flag indicating whether the file was launched or not:



Great, our file was run at least once. So, we have a certain “pivot point”, we know that on November 7, TeamViewer appeared on the computer's drive, which did not keep journals, and most likely was not visible to the user, because instead of the legitimate library, it loaded the one that is with it in one directory.

It's time to start building a timeline. I think enough of what can be built with the help of the Sleuth Kit. Let's start with the fls utility already known to us:

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

Now use mactime to convert the resulting file to the timeline:

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

Timelines are very convenient to analyze in Eric Zimmerman's Timeline Explorer . Our timeline will only include file system events. If you want it to include changes in the registry, journals, etc., you can use plaso. Personally, I use it extremely rarely, since data processing takes a lot of time, and the result is often quite redundant.

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


And two seconds before this, the file 21DA.tmp is created:


If we look for its checksum, for example, on VirusTotal, then we will get quite interesting results:



Obviously, our RAT was unpacked from this file. Go ahead:


Even earlier, the LocalDataNT directory is created with quite interesting files inside. Take, for example, WinPrintSvc.exe:


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


Check his checksum:


Several anti-virus products will detect it as “ RemoteAdmin ” at once. Apparently, he is the source of Remote Utilities. Check if the detected RAT was launched. This time we will use the AmCache.hve registry file from C: \ Windows \ AppCompat \ Programs (the same RegRipper will allow us to get data from it in a digestible form):


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

So, we have two RATs, but where did they come from? Good question! If you still scroll timeline, then we will see traces of creating a rather suspicious directory and file:


Despite the strange extension, fnbfdnja.hej has its usual title:


What will the search by checksum on VirusTotal show us? Here's what:


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


It seems that we have found the culprit of the celebration - this is “Documents for October.exe”. Or maybe not, the name associated with our file is different, even though the checksum is the same. So, again .exe, which means we need to look for traces of the launch again. Personally, I really love working with the registry, so again I will use the help of the already known NTUSER.DAT file and RegRipper. This time we will take a look at UserAssist - from it we will get the names and paths to the files, the dates of their last launch, as well as the number of these launches. The file “Documents for October.exe” is not visible, but another file is visible:

C: \ Users \% username% \ Desktop \ Documents environment.exe

Great, this looks like what we need. True, there is a small problem - there is no file in the right place. Let's go back to the timeline. After creating the fnbfdnja.hej file, this is what happens:


The files in the Temp directory probably belong to RTM, but we are not interested in them. We are interested in the $ R6K21RQ.exe and $ I6K21RQ.exe files. This is exactly what the files placed in the “Trash” look like - the first one contains the data itself, the second - the metadata. If we look at the contents of $ I6K21RQ.exe, we immediately see the path to the desired file - “Documents environment.exe”.

It's time to take a look at what VT will offer for its checksum:


We see already familiar to us detekty - "RTM". As it turned out, the checksum of our file coincided with the checksum "Documents for October.exe". Moreover, VT knows several more files with the same checksum:


It would be nice to get some network indicators of compromise. We have no memory dump, network traffic dump too, what to do? Swap file! But how to find a needle in a haystack? And here VT will also help us a little, this time the “Behavior” tab:


It looks like C2, right? Let's see if there is anything like this in our paging file (pagefile.sys). Of course, there are:


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


Great, we have another network indicator - 195.123.219 [.] 87. Of course, paging files are not only suitable for searching for network indicators. If we return to the “Behavior” tab on VT, we will see that our file creates tasks in the scheduler. If we look for the string “fnbfdnja.hej”, we will find this:


Created task and runs fnbfdnja.hej through rundll32.exe.

Well, it's time to round out. It's time to determine where all the same file "Documents Environment.exe" came from. We already know that this is RTM, and since this is RTM, then the most likely infection vector is a phishing email. In this case, the victim used Microsoft Outlook, so we found the OST file with the mail in the usual place, and in it - the same phishing email:


However, I want to end our post not on this, but on another interesting artifact. If we go back to the NTUSER.DAT file and look at the value of the "Shell" parameter in the Software \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon section, then instead of the usual "explorer.exe" we will see this:


This means that after the user logs in, instead of launching the "Explorer", the system will be shut down, and with it the article will be completed.