In one large financial organization there was an unpleasant incident: intruders penetrated the network and “vacuumed” all critical information – copied and then sent the data to their remote resource. By that time, some workstations and servers had already been decommissioned, and traces of the cybercriminals’ actions had been destroyed due to their use of specialized software and incorrect logging. However, on one of the servers involved in the incident, a Windows swap file was found, from which experts received critical information about the incident.
What are pagefile.sys hiding?
So, pagefile.sys is a swap file of the Windows operating system. If there is a shortage of RAM, Windows reserves a certain amount of hard disk space and uses it to increase its capabilities. In other words, it unloads some data from the RAM into the pagefile.sys file. Very often, the information required for the researcher remains only in the paging file.
The paging file is unloaded in blocks of 4 KB, so the data can occupy a continuous 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 extracted with a loss of integrity.
The pagefile.sys size in the file system is set by default by the operating system, but the user can always turn off the paging file or change its maximum size. The default location of the file is at the root of the system partition, but it can also be located on any other logical disk, depending on where the user has placed it. It is necessary to remember this fact.
Before we start extracting pagefile.sys, we need to understand what the file is from the point of view of the file system. To do this, we will use the AccessData FTK Imager software:
|Read Only||False||Group SID||S-1-5-18|
You can see that this is a hidden system file which is not so easy to copy.
Then how do I get this file? There are several ways to do this:
(1) If you work with an active operating system, we use FTK Imager or KAPE software by Eric Zimmerman to extract it.
2) If there is a digital copy of the drive or the file itself, we just copy the file or work with it directly.
Don’t forget that pagefile.sys files can be located in the Volume Shadow Copy and other logical drives. However, there are cases when the rules of the shadow copy are set by the user himself and exclude swap file copying (in the system registry there is a branch HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FilesNotToSnapshot, which specifies the files to be excluded from the shadow copy).
In the image below, you can see how the amount of data found in the current swap file (the leftmost one in the image) and the swap files that were extracted from the same drive from shadow copies created at different times changes.
An important point to keep in mind is that starting with the 10525 build of Windows 10, paging file compression is used. If memory is insufficient, the system compresses unused memory resources in each process, allowing more applications to remain active at the same time. To decompress such a file, you need to use specialized software.
For example, you can use the winmem_decompress utility for decompression.
This will be useful when the search in the original swap file did not give the results or the necessary data was in a compressed form.
So, when we have the pagefile.sys file in our hands, we can start looking into it. And there are two situations to highlight: the first when we know what to look for, and the second when we don’t.
In the first case, it may be fragments of files, traces of some software operation, some 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, such as Magnet Axiom, Belkasoft Evidence Center, strings utility (it can be considered the main and most frequently used), Photorec software (recovery software that uses the signature method), in some cases, apply yara-rules (provided that you configure scanning large files) – or just view the file manually.
And what can be found in the pagefile.sys file, and why are we focusing on the swap file? It’s simple: it’s data partially unloaded from RAM, i.e. processes, files and other artifacts – something that was active and functioning in the OS. It can be a part of the Internet history and IP addresses, information about the launch of some files or the files themselves, fragments of images and texts, information about network queries of previously functioning software, traces of malware in the form of keystroke logs, system files and OS logs, and much more.
How do hackers and fraudsters use it?
It is time to move directly to real cases and research. So, what can you find useful in a Windows swap file in terms of digital forensics?
One of the cases examined an image of a drive infected with various malware, through which the attackers stole money from an organization’s account.
In order to provide a full answer to what happened and how, the forensics officer needs to establish the starting point of the infection, the tools used by the cybercriminals, and the sequence of actions. Not all traces of malware functioning were found during the research. And here pagefile.sys was analyzed. As we already know, there you can find pages from process memory unloaded from RAM into the paging file, which can sometimes be recovered, for example, with the help of Photorec software using the signature method, as was done in this case.
The following should be noted: since the paging file contains processes (files) already unloaded from RAM, their addressing will be different from that of the original files. In addition, they can be heavily fragmented, so it is often impossible to run such an executable file, and all other files, as a rule, will have damage to the internal structure due to fragmentation, because the signature recovery itself can not find all the file fragments and arrange them in the correct order.
Above is an example of files (Photorec has named the files based on the offset from the beginning of the paging file) that were uploaded during this study. We can see that these are executable, graphic, text, and other files. The next step is simple: we analyze them based on the necessary criteria and tasks.
In a particular case, dll files with malicious code were recovered from a paging file. Below is an example of their detectors on VirusTotal (the search was performed by the checksum of files):
During the analysis, the address of the remote server with which these files could interact was set. Using the hexadecimal X-Ways WinHEX editor in the investigated pagefile.sys, strings containing the addresses of the remote server were detected. This indicates that the detected files were functioning in the OS and were actively interacting with their remote server. And here are the detectors of VirusTotal service for December 2018:
Thus, in this case, thanks to the information found in pagefile.sys, we have established the whole chain of infection.
Trojans and spyware programs
There are sometimes unique cases when you can find screen shots encoded into base64 in a paging file, among other traces. For example, the Buhtrap bank trojan creates these when sent.
In a particular case, the beginning of the file was as follows: /9j/4AAQSkZJRgAQEAYABgAAD/. This is the header of the jpeg file encoded in base64 (part of the image is represented):
The above fragment was copied, decoded and added to it the extension jpg. We were lucky, and the detected screenshot contained a full picture of the active desktop of the accounting computer with “1C: Accounting” open software, which displayed the financial balance of the company and other important data. Other encoded images were incomplete (broken) due to the peculiarities of information storage in the paging file.
Another example. In one of the incidents, traces of the Cobalt Strike framework were found (typical strings in the swap file are SMB mode, status_448, ReflectiveLoader):
And later you can try to unload the modules. In the image above it is keylogger.dll and screenshot.dll, but there may be others.
Let’s move on. Included in Cobalt Strike and often used by attackers, the mimicric module is a tool that implements the functionality of the Windows Credentials Editor and allows you to extract the authentication data of a logged user in the system in clear view. It is in the swap file that traces of its functioning were found, namely the following character strings:
- sekurlsa::logonPasswords – extract account logins and passwords;
- token::elevate – increase access rights to System or search for domain administrator token;
- lsadump::sam – get SysKey to decrypt records from SAM registry file;
- log Result.txt is a file where the results of software operation are recorded (don’t forget to search this file in the file system).
The next example is traces of the Ranbyus banking trojan, which consists of many modules. In the course of one study, a paging file that was in the shadow copy (VSS) found strings formed by an additional module that extends the functionality of the Ranbyus software.
The strings contained, among other things, the entered user authentication data (login and password) in the “client-bank” system. And as an example – part of the network request, including information about the management server, which was found in the file pagefile.sys:
In fact, quite often you can find examples of POST malware requests to their management servers, as well as the answers of these servers to requests. Below you can find such cases on the example of interaction between software and its management server:
Now let’s remember about the case from which we started this post. In a large organization with many servers and workstations there was an incident during which the attackers entered the network, took possession of the credentials of one of the domain controller administrators and then moved around the network using legitimate software. They copied critical information and then sent this data to a remote resource.
At the time of the response, more than six months had passed, some workstations and servers had already been decommissioned, and traces of the attackers’ actions were destroyed “due to” their use of specialized software and incorrect logging.
In the process of response, we came to a server with Windows Server 2012 operating system, which participated in the incident. The system log files had already been overwritten more than once and the free disk space had been erased. But there was a paging file! Thanks to the server’s long service life without rebooting and the large volume of the paging file, there were traces of malicious software and scripts running in it, which at the time of the survey were already absent in the file system without the possibility of recovery.
Information about the directories and files (paths and names) that were created, copied and subsequently deleted by the attackers, IP addresses of the organization’s workstations from which the data was copied, and other important information were also preserved.
Interestingly, automated analysis using various forensic software did not give full results, there were no specific search criteria, so experts resorted to manual analysis of the paging file using the hexadecimal editor X-Ways WinHEX.
Below are a few examples of what the experts have found:
Information about the use of pcsp.exe and ADExplorer.exe utilities (there are both dates and paths).
Next is information about using the vbs-script (in the image, the beginning and the end).
It is noteworthy that the credentials (login and password) of one of the domain controller administrators were previously compromised:
As a result, almost all critical information about the incident was found in the swap file of one of the servers. The attackers’ tools and part of their actions in the organization’s network were installed.
And in conclusion, of course, it is worth mentioning other artifacts, such as data about visiting Internet sites (sometimes you can find information about the use of electronic mailboxes), information about files and directories. You can also find information such as the computer name and the serial number of the volume where the paging file was located:
And also information from Prefetch files and, of course, Windows system logs.
So, pagefile.sys can really contain a lot of different artifacts that can help in the analysis. That’s why you should never ignore a paging file study. Even if you have all the data you need, explore pagefile.sys anyway. Practice shows that there may be something missing and important there.