In one large financial organization, an unpleasant incident occurred: attackers penetrated the network and "vacuumed" all critical information-they copied and then sent data to their remote resource. Group-IB criminologists were called to help only six months after the events described. By that time, some of the workstations and servers had already been taken out of operation, 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 received critical information about the incident.
Part 1. What is being hidden pagefile.sys
So, pagefile.sys -this is the paging file of the Windows operating system. If you run out of RAM, Windows reserves a certain amount of hard disk space and uses it to increase its capabilities. In other words, it uploads part of the data from RAM to a file pagefile.sys. Very often, the information needed for the researcher remains only in the paging file.
Uploading to the paging file takes place on a page-by-page basis, in blocks of 4 KB, so data can occupy either a continuous area in the paging file, or be located in different parts of it. This means that in most cases, the information found in this file will be extracted with loss of integrity.
Size pagefile.sys in the file system, the default value is set by the operating system, but the user can always disable the paging file or change its maximum size. The standard file location is at the root of the system partition, but it can also be located on any other logical disk, depending on where the user placed it. We must remember this fact.
Before we start extracting pagefile.sys, you need to understand what this file is from the point of view of the file system. To do this, use The accessdata FTK Imager SOFTWARE:
You can see that this is a hidden system file that is not so easy to copy.
Then how do I get this file? There are several ways to do this:
If you are working with an active operating system, then we use the FTK Imager or KAPE SOFTWARE to extract it Eric Zimmerman
In the image below, you can see how the amount of detected data changes in the current paging file (the leftmost one in the image) and paging files that were extracted from the same drive from shadow copies created at different times.
An important point to keep in mind: starting with build 10525 of Windows 10, paging file compression is used. When memory is low, 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 must use specialized SOFTWARE.
For example, you can use the winmem_decompress utility for decompression Maxim Sukhanova:
This will be useful when the search in the original paging file did not yield results, or the necessary data was in compressed form.
So, when the file pagefile.sys we have it in our hands, so we can start exploring it. And here we need to distinguish two situations: the first is when we know what to look for, and the second is when we don't know. In the first case, it can be fragments of files, traces of the work of a particular SOFTWARE, or some user activity. For such a search, the x-Ways hexadecimal editor 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, the strings utility (it can be considered the main and most frequently used one), Photorec SOFTWARE (Recovery SOFTWARE that uses the signature method), in some cases apply yara rules (if you set up scanning large files) or simply view the file manually.
What can I find in the file pagefile.sys and why do we focus on the paging file? It's simple: this is data that is partially unloaded from RAM, i.e. processes, files, and other artifacts that were active and functioning in the OS. This can be part of the Internet history and IP addresses, information about the launch of some files or 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 and OS logs, and much more.
Let's go to the fields
It's time to move directly to real cases and research. So, what is useful to find in the Windows paging file from the point of view of digital forensics?
In one of the cases, an image of a drive infected with various malicious SOFTWARE was studied, with the help of which attackers stole money from the organization's account.
To give a complete answer about what happened and how, the criminologist needs to establish the initial point of infection, the tools used by the attackers, and the sequence of actions. The study did not find all traces of malware functioning. And here was analyzed pagefile.sys. As we already know, there you can find pages from the process memory that are 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.
Note the following:: since the paging file contains processes (files) that have already been unloaded from RAM, their addressing will differ from that of the original files. In addition, they can be highly fragmented, so it is often impossible to run such an executable file, and all other files, as a rule, will have internal structure damage due to fragmentation, because signature recovery cannot find all the fragments of the file itself and arrange them in the correct order.
Above is an example of the files (Photorec assigned names to the files based on the offset relative to the beginning of the paging file) that were uploaded during this study. We can see that these are executable, image, 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 restored from the paging file. Below is an example of their detection on VirusTotal (the search was performed using the checksum of files):
During the analysis, the address of the remote server that these files could interact with was set. Using the x-Ways WinHEX hexadecimal editor in the test file pagefile.sys strings containing addresses of the remote server were detected. This means that the detected files functioned in the OS and actively interacted with their remote server. And here are the VirusTotal service detectors for December 2018:
Thus, in this case, due to the data found in pagefile.sys based on this information, we have established the entire infection chain.
And what else?
There are sometimes unique cases where you can find base64-encoded screenshots in the paging file, among other traces. For example, the Buhtrap banking Trojan creates such messages when sending them.
In the specific case, the beginning of the file was /9j/4AAQSkZJRgABAQEAYABgAAD/. This is the header of the JPEG file, encoded in base64 (part of the image is represented):
The above fragment was copied, decoded, and the jpg extension was added to it. We were lucky, and the discovered screenshot contained a full snapshot of the active desktop of the accounting computer with the open 1C: Accounting SOFTWARE, which displayed the financial balance of the enterprise and other important data. Other detected encoded images were incomplete (broken) due to the storage of information in the paging file.
Another example. During one of the incidents, traces of the Cobalt Strike framework were found (characteristic lines in the paging file-SMB mode, status_448, ReflectiveLoader):
And then you can try to unload the modules. In the image above, this is keylogger.dll and screenshot.dll, but there may be others.
Let's move on. The mimikatz module included in Cobalt Strike and often used by attackers is a tool that implements the functionality of the Windows Credentials Editor and allows you to extract the authentication data of a user logged in to the system in clear text. It was in the paging file that traces of its functioning were found, namely the following character lines::
The following example shows traces of the banking Trojan Ranbyus, which consists of many modules. In one study, a paging file that was located in a shadow copy (VSS) was found to contain strings generated by an additional module that extends the functionality of the Ranbyus SOFTWARE. The lines contained, among other things, the user's entered authentication data (login and password) in the client-Bank system. And as an example part of a network request, including information about the management server that was detected in the file pagefile.sys:
In fact, it is quite common to see examples of malware POST requests to its management servers, as well as responses from these servers to requests. The following examples show how Buhtrap software interacts with its management server:
Now let's remember the case that we started this post with. In a large organization with multiple servers and workstations, an incident occurred in which attackers broke into the network, took over 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 it to a remote resource. At the time of the response, more than six months had passed, some workstations and servers had already been taken out of operation, and traces of the attackers ' actions were destroyed "due" to their use of specialized SOFTWARE and due to incorrect logging.
During the response process, we accessed the Windows Server 2012 server that was involved in the incident. System log files have already been overwritten more than once, and free disk space has been erased. But there was a paging file! Due to the long operation of the server without rebooting and the large volume of the paging file, it still contains traces of malicious SOFTWARE and scripts that were already missing from the file system without recovery at the time of the study. Information about directories and files (paths and names) that were created, copied, and subsequently deleted by intruders, as well as the IP addresses of the organization's workstations from which the data was copied, and other important information were also saved.
Interestingly, automated analysis using various forensic SOFTWARE did not give complete results, there were no specific search criteria, so the specialists 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 utilities pcsp.exe and ADExplorer.exe (both dates and paths are present).
Then information about using the vbs script (the image shows the beginning and end).
It is noteworthy that the credentials (username and password) of one of the domain controller administrators that were previously compromised are specified:
As a result, almost all critical information about the incident was found in the paging file of one of the servers. Malicious tools and some of their actions in the organization's network are installed.
And finally, of course, it is worth mentioning other artifacts, such as data about visiting Internet sites (sometimes you can find information about using email mailboxes), 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 indeed, it can contain a large number of different artifacts that can help in the analysis. This is why you should never ignore paging file research. Even if you have all the necessary data still explore pagefile.sys. Practice shows that there may be something missing and important.
Part 1. What is being hidden pagefile.sys
So, pagefile.sys -this is the paging file of the Windows operating system. If you run out of RAM, Windows reserves a certain amount of hard disk space and uses it to increase its capabilities. In other words, it uploads part of the data from RAM to a file pagefile.sys. Very often, the information needed for the researcher remains only in the paging file.
Uploading to the paging file takes place on a page-by-page basis, in blocks of 4 KB, so data can occupy either a continuous area in the paging file, or be located in different parts of it. This means that in most cases, the information found in this file will be extracted with loss of integrity.
Size pagefile.sys in the file system, the default value is set by the operating system, but the user can always disable the paging file or change its maximum size. The standard file location is at the root of the system partition, but it can also be located on any other logical disk, depending on where the user placed it. We must remember this fact.
Before we start extracting pagefile.sys, you need to understand what this file is from the point of view of the file system. To do this, use The accessdata FTK Imager SOFTWARE:
You can see that this is a hidden system file that is not so easy to copy.
Then how do I get this file? There are several ways to do this:
If you are working with an active operating system, then we use the FTK Imager or KAPE SOFTWARE to extract it Eric Zimmerman
- if there is a digital copy of the drive or the file itself just copy the file or work with it directly.
In the image below, you can see how the amount of detected data changes in the current paging file (the leftmost one in the image) and paging files that were extracted from the same drive from shadow copies created at different times.
An important point to keep in mind: starting with build 10525 of Windows 10, paging file compression is used. When memory is low, 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 must use specialized SOFTWARE.
For example, you can use the winmem_decompress utility for decompression Maxim Sukhanova:
This will be useful when the search in the original paging file did not yield results, or the necessary data was in compressed form.
So, when the file pagefile.sys we have it in our hands, so we can start exploring it. And here we need to distinguish two situations: the first is when we know what to look for, and the second is when we don't know. In the first case, it can be fragments of files, traces of the work of a particular SOFTWARE, or some user activity. For such a search, the x-Ways hexadecimal editor 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, the strings utility (it can be considered the main and most frequently used one), Photorec SOFTWARE (Recovery SOFTWARE that uses the signature method), in some cases apply yara rules (if you set up scanning large files) or simply view the file manually.
What can I find in the file pagefile.sys and why do we focus on the paging file? It's simple: this is data that is partially unloaded from RAM, i.e. processes, files, and other artifacts that were active and functioning in the OS. This can be part of the Internet history and IP addresses, information about the launch of some files or 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 and OS logs, and much more.
Let's go to the fields
It's time to move directly to real cases and research. So, what is useful to find in the Windows paging file from the point of view of digital forensics?
In one of the cases, an image of a drive infected with various malicious SOFTWARE was studied, with the help of which attackers stole money from the organization's account.
To give a complete answer about what happened and how, the criminologist needs to establish the initial point of infection, the tools used by the attackers, and the sequence of actions. The study did not find all traces of malware functioning. And here was analyzed pagefile.sys. As we already know, there you can find pages from the process memory that are 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.
Note the following:: since the paging file contains processes (files) that have already been unloaded from RAM, their addressing will differ from that of the original files. In addition, they can be highly fragmented, so it is often impossible to run such an executable file, and all other files, as a rule, will have internal structure damage due to fragmentation, because signature recovery cannot find all the fragments of the file itself and arrange them in the correct order.
Above is an example of the files (Photorec assigned names to the files based on the offset relative to the beginning of the paging file) that were uploaded during this study. We can see that these are executable, image, 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 restored from the paging file. Below is an example of their detection on VirusTotal (the search was performed using the checksum of files):
During the analysis, the address of the remote server that these files could interact with was set. Using the x-Ways WinHEX hexadecimal editor in the test file pagefile.sys strings containing addresses of the remote server were detected. This means that the detected files functioned in the OS and actively interacted with their remote server. And here are the VirusTotal service detectors for December 2018:
Thus, in this case, due to the data found in pagefile.sys based on this information, we have established the entire infection chain.
And what else?
There are sometimes unique cases where you can find base64-encoded screenshots in the paging file, among other traces. For example, the Buhtrap banking Trojan creates such messages when sending them.
In the specific case, the beginning of the file was /9j/4AAQSkZJRgABAQEAYABgAAD/. This is the header of the JPEG file, encoded in base64 (part of the image is represented):
The above fragment was copied, decoded, and the jpg extension was added to it. We were lucky, and the discovered screenshot contained a full snapshot of the active desktop of the accounting computer with the open 1C: Accounting SOFTWARE, which displayed the financial balance of the enterprise and other important data. Other detected encoded images were incomplete (broken) due to the storage of information in the paging file.
Another example. During one of the incidents, traces of the Cobalt Strike framework were found (characteristic lines in the paging file-SMB mode, status_448, ReflectiveLoader):
And then you can try to unload the modules. In the image above, this is keylogger.dll and screenshot.dll, but there may be others.
Let's move on. The mimikatz module included in Cobalt Strike and often used by attackers is a tool that implements the functionality of the Windows Credentials Editor and allows you to extract the authentication data of a user logged in to the system in clear text. It was in the paging file that traces of its functioning were found, namely the following character lines::
- sekurlsa: logonPasswords-retrieving account usernames and passwords
- token: elevate-upgrade access rights to SYSTEM or search for a domain administrator token
- lsadump: sam-getting a SysKey to decrypt entries from the Sam registry file
- log Result.txt - a file where the results of SOFTWARE work are recorded (do not forget to search for this file in the file system):
The following example shows traces of the banking Trojan Ranbyus, which consists of many modules. In one study, a paging file that was located in a shadow copy (VSS) was found to contain strings generated by an additional module that extends the functionality of the Ranbyus SOFTWARE. The lines contained, among other things, the user's entered authentication data (login and password) in the client-Bank system. And as an example part of a network request, including information about the management server that was detected in the file pagefile.sys:
In fact, it is quite common to see examples of malware POST requests to its management servers, as well as responses from these servers to requests. The following examples show how Buhtrap software interacts with its management server:
Now let's remember the case that we started this post with. In a large organization with multiple servers and workstations, an incident occurred in which attackers broke into the network, took over 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 it to a remote resource. At the time of the response, more than six months had passed, some workstations and servers had already been taken out of operation, and traces of the attackers ' actions were destroyed "due" to their use of specialized SOFTWARE and due to incorrect logging.
During the response process, we accessed the Windows Server 2012 server that was involved in the incident. System log files have already been overwritten more than once, and free disk space has been erased. But there was a paging file! Due to the long operation of the server without rebooting and the large volume of the paging file, it still contains traces of malicious SOFTWARE and scripts that were already missing from the file system without recovery at the time of the study. Information about directories and files (paths and names) that were created, copied, and subsequently deleted by intruders, as well as the IP addresses of the organization's workstations from which the data was copied, and other important information were also saved.
Interestingly, automated analysis using various forensic SOFTWARE did not give complete results, there were no specific search criteria, so the specialists 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 utilities pcsp.exe and ADExplorer.exe (both dates and paths are present).
Then information about using the vbs script (the image shows the beginning and end).
It is noteworthy that the credentials (username and password) of one of the domain controller administrators that were previously compromised are specified:
As a result, almost all critical information about the incident was found in the paging file of one of the servers. Malicious tools and some of their actions in the organization's network are installed.
And finally, of course, it is worth mentioning other artifacts, such as data about visiting Internet sites (sometimes you can find information about using email mailboxes), 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 indeed, it can contain a large number of different artifacts that can help in the analysis. This is why you should never ignore paging file research. Even if you have all the necessary data still explore pagefile.sys. Practice shows that there may be something missing and important.
