Pagefile.sys Pagefile Secrets: Useful Artifacts for the Computer Forensic Scientist

An unpleasant incident occurred in one large financial institution: attackers entered the network and “vacuum cleaned” all critical information - they copied and then sent the data to their remote resource. Group-IB forensic experts called for help only six months after the events described…. By that time, some of the workstations and servers had already been taken out of service, and the traces of the attackers' actions were destroyed due to their use of specialized software and due to incorrect logging. However, a Windows paging file was found on one of the servers involved in the incident, from which experts obtained critical information about the incident.



In this article, Pavel Zevakhin, Group-IB Forensic Science Lab, discusses what data can be found in Windows swap files during forensic research.

Part 1. What pagefile.sys is hiding

So pagefile.sys is the paging file of the Windows operating system. When there is not enough RAM, Windows reserves a certain space on the hard disk and uses it to increase its capabilities. In other words, it unloads part of the data from RAM to the pagefile.sys file. Very often, the information needed by the researcher remains only in the paging file.



Uploading to the paging file occurs page by page, in 4 KB blocks, so data can occupy both a contiguous area in the paging file or be in different parts of it. This means that in most cases the information found in this file will be retrieved with loss of integrity.



The size of pagefile.sys in the file system is set by the operating system by default, but the user can always disable the paging file or change its maximum size. The standard location for the file is at the root of the system partition, but it can be located on any other logical drive, depending on where the user placed it. This fact must be remembered.



Before we dive into extracting pagefile.sys, we need to understand what the file is from a filesystem perspective. To do this, we will use the AccessData FTK Imager software:





It can be seen that this is a hidden system file that is not easy to copy.



How do I get this file then? This can be done in several ways:

• , FTK Imager KAPE
  
  
  
  
• — .

Do not forget that the pagefile.sys files can be located in Volume Shadow Copies and on other logical drives. True, there are cases when the user himself sets the shadow copying rules and excludes copying the paging file (there is a HKEY_LOCAL_MACHINE \ SYSTEM \ ControlSet001 \ Control \ BackupRestore \ FilesNotToSnapshot branch in the system registry , where files that will be excluded from the shadow copy are specified).



In the image below, you can see how the amount of detected data changes in the current paging file (in the image - the leftmost one) and paging files that were retrieved from the same drive from shadow copies created at different times.

An important point to keep in mind: Starting with build 10525, Windows 10 uses paging file compression. When memory is low, the system shrinks unused memory resources in each process, allowing more applications to remain active at the same time. To decompress such a file, you must use specialized software.

For example, you can use Maxim Sukhanov's winmem_decompress utility for decompression :





This is useful when a search in the original paging file did not return any results or the required data was compressed.



So, with the pagefile.sys file in our hands, we can start examining it. And here it is necessary to highlight two situations: the first - when we know what to look for, and the second - when we do not know. In the first case, these can be fragments of files, traces of the work of one or another software, some kind of user activity. For such a search, the hexadecimal editor X-Ways WinHEX (or any other) is usually used . In the second case, you will have to rely on specialized software, for example, MAGNET AXIOM , Belkasoft Evidence Center , strings utility (it can be considered the main and most frequently used), softwarePhotorec (signature recovery software), in some cases apply yara rules (assuming you have configured large files to scan) - or simply view the file manually.



What can be found in pagefile.sys, and why are we focusing on the paging file? It's simple: this is data partially unloaded from RAM, that is, processes, files and other artifacts - what was actively and functioned in the OS. This can be part of the Internet history and IP address, information about the launch of some files or the files themselves, fragments of images and texts, information about network requests of previously functioning software, traces of malware in the form of keystroke logs, system files, etc. OS logs and much more.

Let's go to the fields

It's time to move directly to real cases and research. So, what's useful in a Windows swap file from a digital forensics perspective?



In one of the cases, an image of a drive infected with various malware was examined, with the help of which cybercriminals stole money from an organization's account.



To give a complete answer to what happened and how, the forensic scientist needs to establish the starting point of infection, the tools used by the attackers and the sequence of actions. During the study, not all traces of the malware were found. And this is where pagefile.sys was parsed. As we already know, there you can find pages from the process memory, unloaded from RAM to the paging file, which can sometimes be restored, for example, using the Photorec software using the signature method, as was done in this case.

: (), . , , , , - , .

Above is an example of files (Photorec assigned filenames based on offsets from the start of the paging file) uploaded during this study. We see that these are executable, graphic, text and other files. Then everything is simple: we analyze them based on the necessary criteria and tasks.



In this particular case, dll files containing malicious code were recovered from the paging file. Below is an example of their detections on VirusTotal (the search was carried out by the checksum of the files):





During the analysis, the address of the remote server with which these files could interact was established. Using the hexadecimal editor X-Ways WinHEX, lines containing the addresses of the remote server were found in the examined pagefile.sys. This suggests that the detected files were functioning in the OS and actively interacting with their remote server. And here are the detections of the VirusTotal service for December 2018:







Thus, in this case, thanks to the information found in pagefile.sys, we have established the entire infection chain.

What else?

There are sometimes unique cases where, in addition to other traces, base64 encoded screenshots can be found in the swap file. For example, the banking Trojan Buhtrap creates such when sent.



In this particular case, the beginning of the file was / 9j / 4AAQSkZJRgABAQEAYABgAAD / . This is the base64 encoded header of the jpeg file (part of the image is shown):





The above snippet was copied, decoded and added jpg extension to it. We were lucky, and the detected screenshot contained a full snapshot of the active desktop of the accounting computer with open software "1C: Accounting", which displayed the company's financial balance and other important data. Other detected encoded images were incomplete (broken) due to the way information was stored in the paging file.



Another example. During one of the incidents, traces of the Cobalt Strike framework were found (typical lines in the swap file - SMB mode, status_448, ReflectiveLoader):







And then you can try to unload the modules. In the image above, these are keylogger.dll and screenshot.dll, but there may be others.



Move on. The mimikatz module, which is part of Cobalt Strike and is often used by cybercriminals, is a tool that implements the functionality of the Windows Credentials Editor and allows you to extract the authentication data of a logged in user in clear text. It was in the swap file that traces of its functioning were found, namely the following character strings:

• sekurlsa :: logonPasswords - extract logins and passwords of an account
• token :: elevate - elevate access rights to SYSTEM or search for a domain administrator token
• lsadump :: sam - Get SysKey to decrypt entries from SAM registry file
• log Result.txt - the file where the results of the software are recorded (do not forget to look for this file in the file system):
  
  
  
  

The next example is traces of the functioning of the banking Trojan Ranbyus, which consists of many modules. In one study, a paging file that was in a shadow copy (VSS) found strings generated by an add-on that extended the functionality of the Ranbyus software. The lines contained, among other things, the entered user authentication data (login and password) in the "client-bank" system. And as an example, a part of a network request, including information about the management server, which was found in the pagefile.sys file:





In fact, it is quite common to see examples of POST requests by malware to its C&C servers, as well as the responses of these servers to requests. Below are such cases on the example of interaction between the Buhtrap software and its control server:





Now let's remember the case with which we started this post. In a large organization with many servers and workstations, an incident occurred during which attackers entered the network, took over the credentials of one of the domain controller administrators, and then moved across the network using legitimate software. They copied critical information and then sent that data to a remote location. At the time of the response, more than half a year had passed, some workstations and servers had already been taken out of operation, and the traces of the attackers' actions were destroyed "thanks" to their use of specialized software and due to incorrect logging.



During the response process, we went to the server running Windows Server 2012 that was involved in the incident. System log files have been overwritten more than once, and free disk space has been overwritten. But there was a swap file! Due to the long operation of the server without rebooting and the large size of the paging file, it retains traces of the launch of the cybercriminals' software and scripts, which at the time of the study were no longer in the file system without the possibility of recovery. Information about directories and files (paths and names) that were created, copied and subsequently deleted by intruders, the IP addresses of the organization's workstations from which the data was copied, and other important information have also been preserved.



Interestingly, the automated analysis using various forensic software did not give complete results, there were no specific search criteria, so the experts resorted to manual analysis of the paging file using the X-Ways WinHEX hexadecimal editor.



Below are some examples of what the experts found:









Information about using the pcsp.exe and ADExplorer.exe utilities (both dates and paths are present).



Further - information about the use of the vbs-script (in the image - the beginning and end).

It is noteworthy that the credentials (login and password) of one of the domain controller administrators that were previously compromised are indicated:







As a result, almost all critical information about the incident was found in the paging file of one of the servers. The attackers' tools and some of their actions in the corporate network have been installed.



And in conclusion, of course, it is worth mentioning other artifacts, such as data about visits to Internet sites (sometimes you can find information about the use of e-mail boxes), information about files and directories:







You can also find information such as the computer name and serial number of the volume where the paging file was located:





As well as information from Prefetch files and, of course, Windows system logs.



So, pagefile.sys can actually contain a large number of different artifacts that can help in the analysis. This is why you should never ignore paging file exploration. Even if you have all the data you need, examine pagefile.sys anyway. Practice shows that there may be something missing and important.