Chapter 6: Alternative Sources of Volatile Memory

In previous chapters, we have talked about the importance of memory dumps as a source of useful data for forensic investigations. We've looked at many different tools for analysis, discussed techniques for user activity examination, and discussed techniques for detecting traces of malicious software. However, the subject of Windows operating system memory forensics is not over yet.

We mentioned at the very beginning that there are alternative sources of memory that might contain similar information in addition to the main memory itself. If for some reason you were unable to create a full memory dump or its analysis failed, you can always turn to these sources: hibernation file, pagefile, swapfile, and crash dumps. This is what we will talk about in this chapter.

The chapter will explain how to access alternative sources of volatile data, which tools to use to analyze it, and, of course, which techniques to use to retrieve certain information.

The following topics will be covered in this chapter:

• Investigating hibernation files
• Examining pagefiles and swapfiles
• Analyzing crash dumps

Investigating hibernation files

The first alternative source we will look at is a hibernation file. There is a reason we are starting here, as a hibernation file is a compressed copy of Random Access Memory (RAM). This copy is created when the computer goes into hibernation mode when it is enabled. It is a power-saving mode of the operating system that allows the contents of the memory to be saved to nonvolatile memory in a hiberfil.sys file before powering off. This is the main difference between sleep mode and hibernation mode because the power supply is completely cut off when hibernation is used.

Because a hibernation file is a copy of RAM at the time the computer goes into power-saving mode, it can contain files that the user was working with, even if those files are no longer present on disk at the time when the hibernation file is taken for analysis. This source may therefore play an important role in forensic investigation, so how do we obtain this file?

Acquiring a hibernation file

A completed hibernation file is usually located under the root directory; however, this file is protected by the system and is hidden by default. If you are working with a live machine and a hibernation file has already been created, you can use imaging tools and copy the file to removable media.

You can use the well-known Forensic Toolkit Imager (FTK Imager) for this purpose. Run it on the target host and click File -> Add Evidence Item…, as illustrated in the following screenshot:

Figure 6.1 – FTK Imager's Add Evidence Item option

In the window that appears, select Logical Drive, as shown in the following screenshot, and click Next:

Figure 6.2 – Select Source window

From the drop-down menu, select root (C:) and click Finish, as illustrated in the following screenshot:

Figure 6.3 – Select Drive window

You will then have the target host's filesystem on the left side of the main window. In the root, you can find the hibernation file. To copy it to removable media, right-click on it and select Export Files…, as illustrated in the following screenshot:

Figure 6.4 – Export Files option

In the dialog window, select your removable media where you want to save the hibernation file and click OK, as illustrated in the following screenshot:

Figure 6.5 – Destination path

You should see a progress bar showing the copying process to removable media, as illustrated in the following screenshot:

Figure 6.6 – Export process

This will result in a hiberfil.sys file appearing on the removable media, ready for further processing.

If there is no hibernation file on the target host but you still want to create one, you will need to do the following:

1. Make sure that hibernation mode is enabled.

To do this, run PowerShell as administrator and execute the following command:

PS C:windowssystem32> .powercfg.exe /availablesleepstates

2. If hibernation is enabled, you will see Hibernate in the list that appears. Otherwise, you can enable it by issuing the following command:

   PS C:windowssystem32> .powercfg.exe /hibernate on

Examples of commands are shown in the following screenshot:

Figure 6.7 – powercfg.exe

3. Create a hibernation file.

To do so, simply run the following command:

PS C:windowssystem32> .shutdown.exe /h

This command will bring the target computer into hibernation mode, and you will get a hiberfil.sys file with timestamps corresponding to when the command was run. You can then use FTK Imager to export this file.

Note that in forensic investigations, you are more likely to work with forensic images rather than with live systems. To extract a hibernation file from a forensic image, simply open it with a special tool. You can use the same FTK Imager and the Add Evidence Item… menu option, but now, instead of the logical drive of the live system, you must select Image File and specify the path to the forensic copy on the drive. The rest of the process of exporting the hibernation file to disk will be similar to the process described previously.

Now that we have successfully obtained the hibernation file, let's look at how to analyze it.

Analyzing hiberfil.sys

As the hibernation file is a compressed copy of RAM, we first need to uncompress it and get a raw copy. This can be done by using a Volatility plugin called imagecopy. This plugin allows us to convert memory dumps into different formats and to convert a hibernation file into a raw format. It looks like this:

Figure 6.8 – Volatility imagecopy

We use the -f option to specify the path to our hibernation file and the -O or --output-image option to specify the path where we want to save the result, as well as the name and extension of the desired file. Don't forget the --profile option, where you need to specify the profile that corresponds to the operating system version of the target host. This will give you a file ready for analysis, which in this case is hiberfil.raw.

Another way to convert a hibernation file into a raw format is to use the Hibr2Bin utility included in the Comae Toolkit. To get this tool, you need to become a member of the beta program by registering on the official website at https://www.comae.com/.

This tool can be run via the command line. Not only input and output files but also several options such as the platform and major and minor versions of the operating system must be specified, as shown next:

Figure 6.9 – Comae Toolkit Hibr2Bin

Hibr2Bin supports the following versions:

• /MAJOR 5 /MINOR 1 Windows XP
• /MAJOR 5 /MINOR 2 Windows XP x64; Windows 2003 R2
• /MAJOR 6 /MINOR 0 Windows Vista; Windows Server 2008
• /MAJOR 6 /MINOR 1 Windows 7; Windows Server 2008 R2
• /MAJOR 6 /MINOR 2 Windows 8; Windows Server 2012
• /MAJOR 6 /MINOR 3 Windows 8.1; Windows Server 2012 R2
• /MAJOR 10 /MINOR 0 Windows 10; Windows Server 2017

This will also result in a raw file. Such files can be analyzed with the tools you are already familiar with. For example, you can use Volatility to get a list of active processes, search for files, or detect traces of malicious activity.

Important note

Since a hibernation file has its own structure, some information will still be missing from there. For example, when you go into hibernation mode, information about active network connections is cleared, so you will not be able to retrieve full information about network connections from the hiberfil.sys file.

Let's see how we can get a list of active processes from the hibernation file using Volatility. To do this, we use the pslist plugin, as illustrated in the following screenshot:

Figure 6.10 – List of active processes from hibernation file

Similarly, we can get details of the files encountered in the hibernation file, as illustrated in the following screenshot:

Figure 6.11 – List of files from hibernation file

And we can even try to extract them, as shown next:

Figure 6.12 – File extraction from hibernation file

As you can see, this step of the analysis does not differ much from the analysis of full memory dumps. You can therefore apply the techniques we discussed in the previous chapters without any doubts.

For automated processing and analysis of a hibernation file, you can use paid tools such as Hibernation Recon from Arsenal Recon or complex solutions such as Magnet AXIOM or Belkasoft Evidence Center.

This is how we can analyze the hibernation file, but this is only one of the alternative sources we are considering. Let's move on.

Examining pagefiles and swapfiles

We have already mentioned pagefiles and swapfiles in previous chapters. There, we talked about the mechanism used by our operating system to keep a large number of processes running at the same time. This mechanism operates by putting temporary process data into a specially reserved space on disk—the pagefile—when physical memory shortages occur.

Important Note

Data is loaded into a pagefile page by page, in blocks of 4 kilobytes (KB), so the data can occupy a continuous area as well as different parts of the pagefile. Consequently, you can use both file carving and string searching during analysis. Additionally, Windows keeps track of pagefile entries and their relation to a particular process only in memory at runtime, so it is not possible to recover this relationship during pagefile analysis.

The main difference between swapfiles and pagefiles is that a swapfile stores data from Microsoft Store applications (previously known as Metro applications). It stores data that is not currently needed but may be needed when switching between applications or opening an application from a live tile in the Start menu. The way a swapfile works is also different. It represents a sort of hibernation mechanism for applications. Despite all the differences, most pagefile analysis methods will work for swapfiles as well, so we will focus on pagefile.sys.

Acquiring pagefiles

A pagefile is enabled by default, so you don't need to create it manually. Furthermore, there may be several such files on the system and they will not always be located in the root. To find the paging files, you need to check the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management registry key values of ExistingPageFiles and PagingFiles. This can be done using the registry editor on a live machine or by analysis of the SYSTEM registry file obtained from the forensic image, as illustrated in the following screenshot:

Figure 6.13 – ExistingPageFiles and PagingFiles values in SYSTEM registry file

Once you have checked the number and location of the paging files, they can be extracted in the same way as a hibernation file, as shown next:

Figure 6.14 – Pagefile extraction

In addition, some tools allow you to create a copy of a pagefile along with the memory dump. Look back at the FTK Imager dump creation process; there, you can enable the capture of a pagefile using the Include pagefile checkbox, as illustrated in the following screenshot:

Figure 6.15 – FTK Imager Include pagefile

This will create two files: a memory dump and a copy of the pagefile.

Once you have successfully extracted the pagefile, you can start analyzing it.

Analyzing pagefile.sys

There are different ways of analyzing a pagefile. We will try to elaborate on the most essential ones so that you can choose the method that best suits your investigation objectives.

Important Note

Starting with build 10525, Windows 10 uses pagefile compression. This means that you will need to decompress the pagefile in order to analyze it. You can use the winmem_decompress utility developed by Maxim Sukhanov for this purpose (https://github.com/msuhanov/winmem_decompress).

Some tools—for instance, MemProcFS—allow the joint analysis of memory dumps, pagefiles, and swapfiles. To do this, the -pagefile0...9 option is added to the -device option. The default value for a pagefile is 0; for a swapfile, it is 9. An example of running MemProcFS is shown next:

Figure 6.16 – Joint analysis of memory dump and corresponding pagefile

In this case, the data in the pagefile will complement the data in the memory dump, but it is easier to miss specific information in this situation. Therefore, it is better to analyze the pagefile with separate tools.

We have already mentioned that data in a pagefile is stored in blocks of 4 KB. Since these blocks can occupy different parts of the file and it is difficult to get a structured representation of the content, pagefile analysis will not be straightforward. So, one of the best ways to start analyzing a pagefile is to search for strings.

String searching

The easiest way to start analyzing a pagefile is to look for specific strings. You can use the Strings utility you are already familiar with to retrieve all ASCII and Unicode characters found in a given file. To run it, use PowerShell and the following command:

PS D:> .strings64.exe .pagefile.sys > D:output.txt

The input is the path to our pagefile, and the output is redirected to a text file, which is output.txt. In the resulting file, as before, we can use a keyword search or simply examine the output to see if there are any strings related to the execution of any programs potentially used by attackers, as illustrated in the following screenshot:

Figure 6.17 – Strings output

You can see in the preceding screenshot that analysis of the Strings output detected a HTTPS reverse shell run.

Since we are talking about searching strings, naturally, we should not forget about searching by regular expressions and YARA rules. Here, we have the yara utility to help us. The principle of this utility is the same as the Volatility yarascan plugin. You can use the official GitHub repository to download this tool, at https://github.com/VirusTotal/yara/. You can see the GitHub page in the following screenshot:

Figure 6.18 – yara GitHub repository

On the right side of the page, there is a link to the latest releases, which is exactly what you need. On the Releases page, select the version you need, then download and extract the archive with the executable. You can use PowerShell to run it. To see all the options available, run the command shown in the following screenshot:

Figure 6.19 – yara options

You can use YARA rules from public sources or write your own. Let's use a YARA rule to find the URLs in our file. The rule and its results are shown next:

Figure 6.20 – yara scan results

We can also extend our search with domains, emails, SQL queries, and more with bulk_extractor, as illustrated in the following screenshot:

Figure 6.21 – bulk_extractor execution

Here, we can find not just IP addresses and domains, but also the full URLs, as shown next:

Figure 6.22 – bulk_extractor URL histogram

Pay attention to IP addresses. You can always check them on VirusTotal or any other resource you like. If you check one of the addresses we found, you will find the following results:

Figure 6.23 – VirusTotal results

VirusTotal has detected several malicious files containing this IP address. It would be a good idea to check if our pagefile contains such files.

File carving

In addition to string searching, you can apply tools to carve files. You can use PhotoRec for this purpose. This tool enables signature-based searches and can recognize over 300 file families, including archives, images, Microsoft Office files, PDF files, and more.

PhotoRec can be downloaded along with the TestDisk tool from the official website at https://www.cgsecurity.org/wiki/PhotoRec. To do this, find a link to the latest release on the right side of the page and click on it. In the window that opens, select the appropriate version, then download and unpack the archive. You need an executable called photorec.

Run the following command to analyze the paging file:

PS D:> . estdisk-7.2-WIPphotorec_win.exe D:pagefile.sys

This will open a separate window, as shown next:

Figure 6.24 – PhotoRec media selection

Press Enter to continue, and you will see the following:

Figure 6.25 – PhotoRec filesystem type

As our filesystem is New Technology File System (NTFS), don't change anything, and press Enter again. In the next window, you need to select the directory to save the results, as illustrated in the following screenshot:

Figure 6.26 – PhotoRec destination folder selection

In our case, the output folder will be used to save the carving results. When the output directory is specified, the C key must be pressed to start. The file recovery process will look like this:

Figure 6.27 – PhotoRec carving process

Carving will take some time, so be patient. Eventually, all files that have been recovered will appear in the directory of your choice, as illustrated in the following screenshot:

Figure 6.28 – Carving results

As you can see in the preceding screenshot, we were able to recover a large number of dynamic-link libraries (DLLs), as well as several text and executable files. We can now check to see if there is a file containing the IP address we checked earlier. Let's use PowerShell and the Select-String command, as illustrated in the following screenshot:

Figure 6.29 – Select-String results

Note the context and extension of the file in which our IP address is detected. The content resembles the signatures used by antivirus solutions to search for malware. This is a fairly common situation, so be careful. In this case, the file is more likely to be legitimate; however, there's nothing stopping us from checking the other files for malware. For example, here are the results of checking one of the recovered libraries:

Figure 6.30 – Malicious DLL detection

Several vendors have identified our file as malicious. This cannot be left unattended, so a more in-depth analysis of the recovered DLL can be performed at this point.

As you can see, a pagefile is also a good source of data. You may find not only interesting IP addresses, domains, parts of emails, or shell commands, but also entire files. All of this data will help you to clarify the missing pieces of the puzzle and complete a picture of the incident.

Now, it's time to look at our latest alternative source, crash dumps.

Analyzing crash dumps

When a system gets into an unstable state—for example, due to an exception that cannot be handled correctly—a Windows crash occurs. This happens because of bugs in kernel drivers or other code running at the kernel level. In this case, Windows attempts to save information that is relevant to the crash and can be used for debugging purposes. Since the system is in an unstable state during the crash, the data is first written to the paging file and then transferred to the appropriate dump file during the next boot. Depending on the system configuration, different crash dumps can be created. The following screenshot shows the dump formats offered by Windows 10:

Figure 6.31 – Crash dump formats in Windows 10

Let's take a closer look at these formats, as follows:

• Small memory dump: These files have a size of 64 KB and 128 KB in 32-bit systems and 64-bit systems respectively. They contain information about running processes, loaded drivers, and bug check messages.
• Kernel memory dump: These files contain memory pages in kernel mode only. Consequently, they contain information about the memory used by the kernel. Usually, the size of such dump files will be around one-third of the size of the physical memory on the system.
• Complete memory dump: These are the largest kernel-mode dumps. They contain a complete dump of physical memory at the time of the crash. Unmapped memory is not included.
• Automatic memory dump: This dump is similar to the kernel memory dump. The main difference is in how the information is stored. For the automatic memory dump, Windows sets the size of the system paging file. Starting with Windows 8, this is the default method of creating crash dumps.
• Active memory dump: This dump was introduced in Windows 10, and it is similar to a complete memory dump and contains active memory from user and kernel modes. However, pages that are not likely to be relevant to troubleshooting problems on the host machine are filtered out.

You may get varying information in different amounts depending on the dump being created. To check which crash dumps are created on a particular host, you can check the settings on a live system. To do this, go to My Computer -> System and Security -> System -> Advanced Settings -> Startup and Recovery. Similar information can be found in the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCrashControl registry key. To retrieve this data from the forensic image, you can refer to the SYSTEM registry file, as illustrated in the following screenshot:

Figure 6.32 – CrashControl registry key

The CrashDumpEnabled value defines the type of dump to be created. On Windows 10, the following values are possible:

• 0: None
• 1: Complete or active memory dump
• 2: Kernel memory dump
• 3: Small memory dump
• 7: Automatic memory dump

Note that here, you can also find the path where the crash dump was created. By default, this is the %SystemRoot%MEMORY.DMP file.

In addition to system crashes, there may be a situation whereby a problem occurs in a specific application and the system remains stable. In such situations, mini-crash dumps are created containing error code, application, and host details. These are generated by Windows error reporting and can be found at C:ProgramDataMicrosoftWindowsWER. WER can also be configured to create complete memory dumps of user-mode processes. For this purpose, the LocalDumps key with a DumpType value of DWORD = 00000002 is created in the HKLMSoftwareMicrosoftWindowsWindows error reporting registry key. Herewith, created dumps of user processes will be stored in the %LocalAppData%Crashdumps folder of the user who got the error, and dumps of system processes will be stored in the C:WindowsSystem32configsystemprofileAppDataLocalCrashDumps folder.

Analysis of process crash dumps is particularly important in incident response, as exploitation by malware of an application vulnerability is usually followed by a crash of that application. Analysis of application crash dumps can tell us which techniques the attackers used for the initial access.

All of the files described previously are created by the system during various crashes. You can search for such files in forensic images and retrieve them in the way described previously for hibernation files.

If you are working with a live system, you can create such files yourself if necessary.

Crash dump creation

Before you start creating crash dumps, you need to make sure that their creation is enabled. Don't forget to select the type of dump you want. You can do this by going to My Computer -> System and Security -> System -> Advanced Settings -> Startup and Recovery. Once you are ready, you can begin creating a crash dump.

There are different ways to simulate a system crash—for example, using standard Windows tools or the Windows Debugger (WinDbg). However, the easiest and most reliable way is still to use the NotMyFault tool from Sysinternals. To use this tool, simply download and unpack the archive from the official site at https://docs.microsoft.com/en-us/sysinternals/downloads/notmyfault. In the archive, you will find executable files for 32- and 64-bit systems.

Simulation of a system crash

Run notmyfault.exe as administrator. In the window that opens, you will see options corresponding to the most common causes of system crashes, as illustrated in the following screenshot:

Figure 6.33 – NotMyFault main window

Select the option that suits you and click Crash. We will use the High IRQL fault option. After you press Crash, you will see the notorious blue screen of death (BSoD). The next time you start the computer up, you will have a MEMORY.DMP file, which is a crash dump.

It's a different story with application dumps. The process for creating them is simpler and more flexible as you can use either standard Windows tools such as Task Manager, or third-party tools. Let's look at how to create process dumps.

Process dump creation

Let's start with the built-in tools—more specifically, Task Manager.

To dump a process, start Task Manager by pressing Ctrl + Alt + Delete. In the window that appears, find the suspicious process and right-click on its name. In the pop-up menu, select Create dump file, as shown in the following screenshot:

Figure 6.34 – Creating process dump with Task Manager

If the dump was successfully created, you will see the following window:

Figure 6.35 – Process dumping results

Here, you will find the name of the dump you have created and its location. As you can see, this method is easy to use but does not allow you to select the dump format. Another tool, Process Hacker (https://processhacker.sourceforge.io/downloads.php) can be used in a similar way. You can see this tool in action in the following screenshot:

Figure 6.36 – Creating process dump with Process Hacker

If you want to be able to create different process dumps, there is another tool from Sysinternals, called ProcDump. As the name suggests, this tool is designed specifically for creating process dumps. As with NotMyFault, it can be downloaded from the official site at https://docs.microsoft.com/en-us/sysinternals/downloads/procdump. This tool supports the types of dumps shown in the next screenshot:

Figure 6.37 – ProcDump supported formats

As you may have noticed, you will need PowerShell to run the tool. You can use the PID from the Details tab of Task Manager to specify which process you want to dump, as illustrated in the following screenshot:

Figure 6.38 – Identifying PID

To create a mini-dump containing process, thread, module, handle, address space, and stack information, you need to use the -mm option, and to create a full dump, use the -ma option. This is how it will look:

Figure 6.39 – Mini-dump and full dump creation

These are the tools you can use to create various dumps. Now, it's time to talk about their analysis.

Analyzing crash dumps

Since a system crash and an application crash create different dumps, some of the analysis methods will differ. Let's start with the analysis of dumps created during a system crash.

System crash dumps

The most obvious way to analyze system crash dumps is to use WinDbg. This tool is designed specifically for debugging and allows you to do more than just analysis of crash dumps in order to find out the cause of the crash. Use this link to download the tool: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools. Find Download WinDbg Preview from the Microsoft Store option and click the WinDbg Preview link. Click GET. You will be redirected to the Windows Store. Simply click GET again to install.

After installation, you can launch WinDbg. Go to the File menu and select Open dump file, as illustrated in the following screenshot:

Figure 6.40 – WinDbg File menu

Select your crash dump, and once it is loaded, use the command line to run the !analyze -v command, as illustrated in the following screenshot:

Figure 6.41 – WinDbg !analyze -v command

This command allows you to display detailed information about the cause of the crash, as we can see here:

Figure 6.42 – WinDbg Bugcheck Analysis

Here, you will be able to find data such as faulty driver information, exception errors and code, faulty IPs, failure ID hash strings, and so on.

Another tool that allows a similar analysis is BlueScreenView by NirSoft (https://www.nirsoft.net/utils/blue_screen_view.html), which is shown in the following screenshot:

Figure 6.43 – NirSoft BlueScreenView

Keep in mind that this tool works best with mini-dumps on a live system. It is therefore not practical for postmortem analysis.

There is another solution to help you with postmortem analysis: SuperDump (https://github.com/Dynatrace/superdump). Its main advantage is that it allows you to automate the analysis process and get all the data in a graphical report. The tool is shown in the following screenshot:

Figure 6.44 – SuperDump

SuperDump is a service for automated crash dump analysis that has a web as well as a REST (Representational State Transfer) interface to upload Windows crash dumps. Moreover, it allows you to analyze Linux core dumps as well. However, to run this tool, you will need to have Docker installed.

You now have several tools in your arsenal for system crash dump analysis. You can choose the tool you feel most comfortable working with. We now move on to something more interesting: process dump analysis.

Process dump analysis

Analysis of process dumps is an excellent way to investigate individual suspicious processes without creating full memory dumps. This technique is often used during incident response.

Debuggers can naturally be used to analyze process dumps, but more classic methods can be applied as well—for example, string search or search by YARA rules. Analysis with the help of bulk_extractor can be used here as well.

Let's consider an example with dump analysis of the suspicious process explorer.exe. Let's start with the Strings tool. We will use the standard command, as follows:

PS D:> .strings64.exe .explorer.exe_210813_000718.dmp > D:explorer.txt

The resulting text file can be searched using keywords. In our case, a keyword search for cmd found a command executed by the malware, as illustrated in the following screenshot:

Figure 6.45 – Malicious cmd command in the Strings output

bulk_extractor will be useful as well. We can find IP addresses and domain names used by the malware with the following command:

PS D:> .ulk_extractor.exe -o D:output .explorer.exe_210813_000718.dmp

Results from scanning are shown next:

Figure 6.46 – bulk_extractor domain histogram

Checking these IP addresses revealed that many of them are associated with malicious files, as we can see here:

Figure 6.47 – IP address from bulk_extractor output

Lastly, let's return to the results of the Strings utility. A keyword search for exe also yielded extremely useful information, as we can see here:

Figure 6.48 – Detection of malicious files

In this case, we see the name of the directory used by the malware, as well as the names of the executable file and library. Using the new keyword allowed us to discover even more data related to the malicious activity, as we can see here:

Figure 6.49 – yrpoykg keyword search

As you can see, some analysis techniques are excellent for both full memory dumps and memory dumps of individual processes.

Summary

Analyzing Windows memory dumps is a time-consuming process but can yield invaluable results. In addition to examining full dumps, you should not forget about alternative sources, which can also be of great help in forensic investigations and incident response.

Alternative sources include hibernation files, page files, and swap files, as well as crash dumps and process memory dumps. Some of these files, such as a pagefile and a swapfile, are enabled by default and are created automatically while the operating system is running. Others are created when the system goes into a specific state—for example, a hibernation file is created when the system enters the appropriate mode. The latter, crash dumps, are created when a system crash or application crash occurs, but you can also trigger these states artificially. Among other things, there are special tools that allow you to create individual process dumps, such as process memory dumps, without directly affecting their state.

For analysis of alternative sources, both special tools such as debuggers and more general tools that allow you to search through strings, regular expressions, YARA rules, and signatures can be used.

On that note, we're finishing our analysis of Windows memory. Although this system has been the leader on the desktop operating system market for many years, other systems such as macOS and Linux are becoming more and more popular year by year. It's now time to talk about their analysis. In the next part, we will start to walk through the process of creating Linux memory dumps in detail and then move on to their analysis. As always, we will cover the key techniques and tools used for Linux forensic investigation, accompanied by illustrative examples from our practice. See you in the next part!