RSA Netwitness Endpoint (NWE) offers various ways to alert the analyst of potentially malicious activity. Typically, we recommend that an analyst look at the IIOCs daily, and investigate and categorize (whitelist/graylist/blacklist) any hits on IIOC Level 0 and Level 1.
When an IIOC highlights a suspicious file or event, the next investigative step is to look at the endpoint where the IIOC hit, and investigate everything related to the module and/or event. Depending on the type of IIOC, the analyst can get answers related to the file/event in any or all of the following categories of data:
- Scan data
- Behavioral Tracking Events
- Network Events
If we focus on a Windows endpoint, regardless of whether it is part of an investigation or a standalone infected system, we always complement the analysis of data that has been automatically collected by the agent, with an analysis of the endpoint's Master File Table (MFT). There are very good reasons to always analyze the MFT in these situations. Let me list the main reason here:
- The automatically collected data (scan, behavioral, network) is always a subset of all the actual events that happen on the endpoint. Namely, the agent collects process, file, and registry related events but with some limitations. For example, while the agent records file events, it is focused on executable files rather than all file events. So, looking at the MFT around the time of the event will enable the analyst to discover and collect additional artifacts related to an incident, such as, non-executable files related to an incident. These non-executable files can be anything, from the output of some tool the attacker executed (such as a password dumper) to archive files related to data theft activity, to configuration files for a Trojan, etc.
Let us first describe some key concepts related to the MFT so that you can get the best value out of your analysis of it.
What is the MFT?
In general, when you partition and format a drive in Windows, you will likely format it with the New Technology File System (NTFS). The MFT keeps track of all the files that exist in the NTFS volume, including the MFT file itself. The MFT is a file that is actually named $MFT in the NTFS, and the very first entry inside this file is a record about the $MFT file itself. Just so that you are aware, on average, a MFT file is around 200MB. If you open a $MFT file using a hex editor, you can see the beginning of each MFT record marked by the word "FILE":
The MFT keeps track of various information about the files on the file system, such as filename, size, timestamps, file permissions, as well as where the actual data of the file exists on the volume. The MFT does not contain the data of the file (unless the file is a few bytes small < 512 bytes), but instead it contains metadata about each file and directory on the volume. Perhaps the easiest way to understand the MFT is to think of a library that uses index cards to keep track of all the books in it. The MFT is like the box containing these index cards, where each index card tells you the title of the book and where to find a particular book in the library. The index card is not the book, it just contains information about the book.
The library analogy is also useful to describe a few other concepts regarding the MFT. In this imaginary library, the index cards are never discarded, but rather reused. So, when the library wants to remove a book from its records, it would just mark the index card related to the book as available to contain the information about some new book. Notice that in this situation the index card still contains the old information, and the book is still sitting on a shelf in the library. This situation remains true, until the information in the index card is overwritten by the information of a new book. What we are describing here is the process of a file deletion in Windows (and we are not talking about the Recycle Bin here but actual file deletions). Namely, when a file is deleted in Windows, the MFT record for that file is marked as available to be overwritten by some other new file that will be created in the future. So, deleting a file does not mean deleting its information, or the actual data of the file. Windows just does not show the user files marked as deleted in the MFT. The data may still be there though, and depending on how busy the system is, i.e. how many files are created/deleted, you have a good chance of recovering a deleted file if you get to it before it is overwritten.
When NWE parses the MFT, it shows you both regular MFT records, and those that have been marked as Deleted. The deleted records can also be grouped by themselves (more on this later). However, NWE does not do file recovery, meaning it will not get you the data of a deleted file. It will only show you the information that exists in the MFT of that deleted file. In order to recover a deleted file, you will need to use other forensic tools on the actual endpoint, or an image of the drive, to recover the data of the deleted file. NWE is able to retrieve any other file referenced in the MFT that is not marked as deleted.
MFT Timestamps
Another very important concept about the MFT is related to file timestamps. The MFT contains 8 timestamps in it for each file (a folder is also considered as a file in the MFT) on the endpoint. These 8 timestamps are contained within two attributes named $Standard_Information ($SI) and $Filename_Information ($FN). So, each of these attributes contains these time stamps:
$SI Timestamps $FN Timestamps
- Created - Created
- Modified - Modified
- Accessed - Accessed
- MFT Entry Modified - MFT Entry Modified
Whenever you look at the properties of a file using explorer.exe, you see the first three $SI timestamps. Here is an example of looking at the properties of a file named kernel32.dll:
So, you may wonder what is the MFT Entry Modified time, and what is the purpose of the other equivalent timestamps under the $FN Attribute. The MFT Entry Modified is a timestamp that keeps track of when changes are made to the MFT record itself. Think of it as when the library index card is updated, Windows keeps track of those updates through this MFT Entry Modified timestamp. Windows does not show this timestamp through explorer.exe or any other native Windows tools because this timestamp is not relevant to the typical user.
Typically, when we talk about a file, in our mind we think of it based on its name. However, the name of a file is just one property of a file. This distinction is important as we talk about the $FN timestamps. Whenever a file is created so is its filename, because in order to create a file you have to specify a name. However, Windows creates two sets of timestamps associated with a file object. You can think of the $SI timestamps as associated with the file object itself, and of the $FN timestamps as associated with the filename of the file object.
The reason why we are talking about all these timestamps is because during the analysis of a MFT, time is critical in identifying relevant events. You want to ensure that you are sorting the files based on a reliable timestamp. When it comes to the fidelity of the timestamps, the $FN timestamps are your friend. It is trivial to change the $SI timestamps (Created, Modified, Accessed). In fact, Windows has API functions that allow you to do that. So, many attackers code their droppers to manipulate the $SI timestamps of their files, so that if you are a typical user using explorer.exe to view the properties of a file, you will be tricked into believing that the file was created much further in the past then in reality (attackers typically backdate files). So, during our analysis of the MFT we sort files by their $FN Created Time or the $FN MFT Entry Modified time, since these would likely have the exact timestamp of when the file was created on disk. There are various situations when a file is renamed, moved on same volume, moved to a different volume, etc. that affect these 8 timestamps in various ways depending on the Windows operating system. We will not cover these here as it will require a blog on its own. For more details on these situation there are various write ups online.
How To Request and Open the MFT
- Since a Windows endpoint may have multiple NTFS volumes it means that each volume (or partition, or drive letter) will have its own MFT. So, if the endpoint has multiple drive letters C:, D:, E:, etc, each of them will have its own MFT. In NWE you can request the MFT by right-clicking the endpoint's machine icon, Forensics > Request MFT.
- NWE will request the Default Drive, which means it will request the MFT from the volume where Windows is installed (typically C:). However, here you can request the MFT of any drive letter from the drop down.
- You may wonder how do you know in advance how many volumes exist on the endpoint. This information is available to the analyst under the More Info tab:
- Once you request the MFT, it will show up within a few seconds under the Downloaded tab. This is where you should also open the MFT. In order to open the MFT, you should right click on the MFT and select Download and Open MFT. NWE will then ask you where you want to save the MFT file itself. It is a good practice to have a folder named Analysis, under which you can create subfolders for each endpoint you are investigating. Under this subfolder you can save all the artifacts related to this endpoint, including the MFT.
Sample MFT Analysis
When you open the MFT using the method described above, NWE will automatically associate the MFT with the endpoint that it came from. NWE will assume the MFT belongs to the C: volume. If this is not the case you can change the drive letter as shown below:
As you can see on the left side you can select various folders under the root of C:, look at only files that are marked as deleted in the MFT, or look at All Files. Generally, we want to look at all files to get a global view of everything and start our analysis with whatever file brought us to this system. Sometimes, it is not necessarily a particular file but an event in time. In this case we can then start our analysis by looking at files at that particular time.
Before we look at an example, let us also talk about what columns you should have in front of you to ensure you can be successful in your analysis. We recommend that you have at least the following columns exposed (hiding the rest if you wish) in this order from left to right.
- Filename
- Size
- Creation Time $FN (you should also sort the files by this column)
- Creation Time $SI (this is for comparison purposes to $FN)
- Modification Time $SI (you want the $SI modification time because the $FN timestamps are only good for creation times, not subsequent modifications to the content of the file)
- Full Path
- MFT Update Time $SI
- MFT Update Time $FN (sometimes the $FN timestamp maybe backdated, so this timestamp can be used instead)
You can expose additional columns if you wish, but these should be in this order to maximize the effectiveness of your analysis. In order to select/deselect which columns you wish to see, you can right-click on the column:
Let us now go over an example of why you need to MFT. We start the analysis by reviewing the IIOCs, which as we mentioned, should be something that is done daily. We notice that a suspicious file is identified under the "Autorun unsigned Winsock LSP" IIOC as shown below:
We see two files with the same name listed here uixzeue.dll, which means even though they have the same name, they have different hash values. Let us pull the MFT for this system and see what else occurred on this system that we would not see in Behavioral Tracking for reasons that will be explained below. When we open the MFT, we select All Files on the left pane, and make sure we sort by $FN Creation Time column. A system can have over 100,000 files in it, so to quickly get to the one we are interested in, we can search (CTRL-F) for the file name as shown below:
As we can see in the example above, whatever the attacker used to drop these DLLs on this endpoint, it time stomped the $SI timestamps by backdating them. If we were to sort and perform our analysis on the $SI Creation Time we would be way off of any relevant events about this malware. The $FN Creation Time shows the true time the file was created (born) on this endpoint. After identifying the file of interest we can then clear the search field to again view all files, but NWE will keep the focus on these two files. When you perform analysis on the MFT, the idea is to look at any files Created and/or Modified around the time of interest. What we notice is that a few microseconds before the DLLs showed up, two .fon files were created.
NWE will have not recorded anything related to these .FON files because they are just binary files. In fact they are the bulk of the malicious code, but its content is encrypted. The job of the DLL after it is loaded is to open the .FON file, decrypt it, and load its code in memory. The malicious code and the C2 information is all encrypted inside these .FON files. By the way, these are not FONT files in any way. They are just stored in the \fonts folder and have the .fon extension just to blend in with the other file extensions in that folder.
So, as you can see every time you are chasing a malicious file down you should always also look at the endpoint's MFT to ensure that you have discovered all related artifacts associated with the malicious event.
Happy Hunting!
1 Comment
