Register(ing) activity related to documents

Two last posts concerned hiding traces of malicious activity in the environment and attempts to confuse analysts. This time we will focus on traces that allow us to determine what the user or the attacker was doing. Forensic analysis can have two main purposes. In cases most often associated with threat intelligence, we will try to detect the activities of attackers conducting remote operations after gaining access to the device over the network. However, we are after all at counterintelligence.pl, and an equally important aspect of counterintelligence activity is the analysis of the activity of users who have authorized access to the environment. This related to so-calledinsider threat', i.e. the threats resulting from using the position in the organization for one's own purposes, such as industrial espionage. And in this context, we will look at more subtle traces. The Windows registry will help us analyze activities related to interactions with documents.

There are many sources of information about what the user has been doing, including live monitoring, or even with the access provided by the EDR solutions. However, we will focus on a typical case where the content of a secured system is analyzed without any special tools. So Windows artifacts remain. And one of the richest artifacts is the system registry. I already mentioned the structure of the registry in the anti-forensics post, now we can focus on specific keys and values.

Since we are trying to uncover the actions of an attacker, the main source for our analysis will be keys contained in files specific to the user, not the computer. Specifically, we'll deal with NTUSER.DAT, which is in the user's directory by default.

While the SAM, SOFTWARE, SYSTEM and SECURITY keys store information about the device configuration, individual user settings are stored in NTUSER.DAT. This file allows the operating system to maintain the configuration between subsequent restarts of the computer, as well as better cooperation with the user. The keys contain data on recent activities, which means that the system "learns" the most frequently used functionalities.

It will help us in the analysis of entries again Registry Explorer, which has a number of built-in functionalities that facilitate looking into the registry. If we use a disk image, we can open the NTUSER.DAT file, but for a change we will use the function of reading keys from the live system:

We select the file of our suspect and after a while the data will be loaded:

Above the table with the listed keys and subkeys, you will find two useful tools - a search engine and the Available bookmarks tab. The latter element is particularly interesting, as we will find there shortcuts to the most frequently used registry items in analysis, such as WordWheelQuery or RecentDocs. This function therefore significantly speeds up the initial analysis. Now let's move on to the individual registry entries and what information it can determine on the basis of them. Important note - because the most popular currently operating system is Windows 10, we will this version to conduct the analysis.

Since we want to focus on espionage and data theft, let's first look at file search traces. One of the most popular tools in this regard is the search engine built into Explorer and located in the upper right corner of the explorer window:

As we can see in the attached picture, Windows saves the history of our searches, and this history is our first artifact. In the key Software\Microsoft\Windows\CurrentVersion\Explorer\WordWheelQuery we will find the history entries:

Every Windows user has also come across the characteristic explorer window used by many programs to open and save files:

Information about the history of files opened and saved in this way is stored by Windows in the Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidMRU key. If we look at its structure in Registry Explorer, we will see that the key contains entries responsible for individual file types:

The exception is the key marked with "*". In it we will find the last twenty files regardless of their extension. As we can see in the attached image, in the case of my analysis, Registry Explorer in the Absolute Path column did not extract the filename, but only the folder path. Then we need to look at the details of a specific entry:

Alternatively, we can also look directly at the contents of the entries in the keys responsible for specific file types. This view is not as friendly as the data in the previous window, but it also allows you to determine the files that the user was interested in:

When we know what the user was looking for in the system and what documents he was interested in, let's go to the recently opened documents, which are normally saved in the Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDoc key. By default, Registry Explorer will show us this view, listing the latest entries:

However, this is a kind of processed version of the entries, which can speed up the analysis, but you need to understand why it looks like this and not otherwise - and why the last file opening column is not completely filled. As in the case of ComDlg32 and OpenSavePidMRU, if we expand the key, we will find there items responsible for individual file types. Since we found invoice.docx at the top of the list, let's see what information we can find in the key responsible for this extension.

If we compare the available timestamps, we discover that the last time the file was opened is actually the last time it was written to the key. Therefore, the last open time will be available for the last file of that type. Registry Explorer itself calls the column "Extension Last Opened". It should also be noted that since this time results from the time of the last write, it will be affected by registry manipulations completely unrelated to opening files - e.g. if the registry is manually modified. For Office, an additional source of information will be the File MRU keys contained in Software\Microsoft\[package version]\[program]\File MRU, as in our example here:

Office 2021 is installed on the analyzed system, which translates into a specific key syntax. If we were dealing with the Office 365 package, the key would also contain the user account ID starting with "LiveID_".

Speaking of documents, an interesting artifact is also the position of the cursor. When using the Office package, we have probably come across the fact that the system helpfully suggests where we last finished working with a document. Clicking on the balloon next to the scroll bar will allow you to return to this place. The register also records this information. In the key "Software\Microsoft\[package version]\[program]\Reading Locations" we will find a list of files, and the value of Position:

By analyzing the user's activity and having access to documents that the suspect would steal, we can use this knowledge by downloading the file and manually setting the value in the registry. In this way, we can potentially determine which part of the document the perpetrator was interested in.

The registry can give us a lot of information about how we interact with documents. By analyzing the history of searches or opening and saving files, we can determine what files the user already knew about, what he was looking for, what files he opened, and even where in the document he finished his work. From the perspective of determining the intentions and reproducing the actions of the suspect, this is an extremely valuable set of information. Cases that do not involve technical means of hacking, such as RATs, rootkits and keyloggers, can often be more demanding from the analyst's point of view. Without clear technical artifacts such as installed malware or an attempt to escalate privileges, it is especially important to understand the course of events and the goals of the attacker. Therefore, understanding how the system learns about our activity when trying to speed up our work will definitely help in our DFIR struggles.