Memory Forensics: Harvesting Windows Credentials from Volatile Storage

MEMORY FORENSICS: HARVESTING WINDOWS CREDENTIALS FROM VOLATILE STORAGE

Haider M. al-Khateeb, Carsten Maple {haider.alkhateeb, carsten.maple}@beds.ac.uk Department of Computer Science and Technology, University of Bedfordshire, UK

Abstract In forensic investigations, it is a challenge to recover objective evidence through means of research then attribute the relevant artefacts to an individual. In this series of articles and within the context of volatility memory forensic investigation, we set our scope on recovering user credentials which could be essential not only to unlock hidden and/or encrypted data but also to identify recent users and analyse their unique characteristics. These can then be used to establish a connection between digital evidence and a user of the system. That being said, the article also aims to critically discuss the significance of memory forensics, in addition to demonstrating tools and techniques used to carry out the process of memory acquisition and analysis.

Keywords: Memory Forensics; Windows; Volatile; Volatility; Incident Response; Digital Investigation

Introduction

What artefacts can be extracted from the volatility memory in Windows? And, What makes memory a significant part of any digital forensic methodology?

The best way to answer these questions is through a reasonably brief demonstration of what the computer memory is used for. Foremost, volatile storage maintains data as long as power is available and data is erased/lost when power is interrupted or the computer is switched off. It allows fast CPU read/write access to data compared to non-volatile memory such as Hard Disk Drives (HDDs) where data originally reside. Hence, data-bytes are always moved from non- volatile memory to volatile memory for processing. The Performance tab in Windows Task Manager gives an overview of what seems to be different memory space allocations measures in Mega Bytes as shown in Figure-1.

In our context, another term to use is Random Access Memory (RAM) which is the traditional example of a volatile memory. However, other Windows terminology includes Physical Memory or just Memory!

Figure 1: The different allocations of Memory spaces, and sizes in MB as displayed by Windows 7 Task Manager

The final version of this article has been published in the Digital Forensics Magazine (https://www.digitalforensicsmagazine.com/). Full reference: al-Khateeb, H. M., Maple, C. (2014) ‘Memory Forensics: Harvesting Windows Credentials From Volatile Storage’, Digital Forensics Magazine, 2014(19): 32-36. Physical memory is what is stored on RAM chips lined up in built-in notches on the motherboard, hence the term reflects the total amount of real storage, e.g. if two 1GB memory modules are installed, then the physical memory is 2GB. Figure 1 shows 2047 MB of total physical memory usable by the Operating System, at this point, it is important to bear in mind that the value here can be different from the actual RAM installed in scenarios such as when a machine has the Redundant Memory feature or Memory Mirroring enabled in the BIOS. These options are used as a failover mechanism for the system and can reduce the total RAM available to Windows. A forensic investigator must recognise such technical detail because every memory space is a potential source of digital evidence.

While some RAM spaces featured in the Task Manager such as ‘Available’ and ‘Free’ has more of a usability effect on the system, ‘Cached’ is highlighted to be of a forensic interest to us. It reports the amount of RAM used for the most recently accessed data. To boost performance, software and other data remain in the cache even after they have been closed by the user; this is because, future data access requests can be served faster from the cache!

In addition to what has been discussed so far, the computer structure is designed in way that part of the RAM will be strictly reserved and dedicated for the Kernel. This space will be used to load essential system processes during start-up and then keep them running separately in what is known as a ‘Nonpaged’ area (in contrast to ‘Paged’ which is a virtual memory that will be discussed later). Such implementation maintains high availability of physical space to the core processes responsible to keep the OS running and also keeps it safe and isolated from RAM manipulated by other hosted software.

Why Windows 7? The discussion and demonstration of the tools and techniques in this article were performed on Windows 7. This was not a random choice, but rather influenced by results published in early 2014 by market share statistics reporters such as netmarketshare.com showing that Windows 7 dominates around 47% of the usage share of Desktop Operating Systems followed by Windows XP at around 30%. While the accuracy of such results can be challenged and argued about, it does give a good indication on the type of Operating System a forensic investigator will most likely be dealing with.

Virtual Memory What happens if the physical memory is exhausted in a busy machine where many applications are running simultaneously? In this case, the OS can compensate using a simulating technique that extends RAM virtually to a utilised area in the HDD called a Paging File, this will release some RAM space for other prioritised applications, hence the name: Virtual Memory. As such, if you observe the value of the ‘Available’ physical memory shown in Figure 1, it should never be zero since some processes will always be moved to the virtual memory on the HDD. Similarly, the ‘Paged’ value subtitled within the Kernel Memory refers to the part of the virtual memory dedicated to the Kernal. By default, Windows automatically adjusts the Paging File but it also gives users the privilege to manually determine the size of their Paging File or even stop using this feature, these settings can be changed from

Control Panel  System and Security  System  Advanced System Settings  Advanced  Performance, Settings  Advanced tab  Change

If a Paging File is used (which is strongly recommended), the OS will continuously swap processes between the RAM and virtual memory which implies that an investigator should consider the data in both. In Windows 7, this file is called pagefile.sys and is stored in the %SystemDrive%\ which usually happens to be the C:\ drive as shown in Figure 2. But to actually see it, make sure you

- Navigate to Windows Explorer Tools  Folder options  View - Select ‘Show hidden files, folder, and drives’ - And, unstick ‘Hide protected operating system files (Recommended)’ - Note that pagefile.sys can not be simply copy-pasted because the OS keeps it open and therefore protected from user access. Hence, special purpose tools such as FTK Imager or Forensic Get (FGET) must be used to perform the task. Analysis of this file is beyond the scope of this article but it is important to mention that the standard page size in Paging Files is 4KB. This implies that data moved from the RAM are split into small chunks of data which might only be meaningful if mapped back correctly to the memory to reconstruct existing objects.

Figure 2: The Paging File is a hidden system file used as a virtual memory to support RAM and can be located at %SystemDrive%\pagefile.sys

Memory dump A memory dump is an acquired copy of the volatility memory data-bytes, those were originally moved from the Hard Drive for processing. Hence, this image must be taken from a running machine which is why memory forensics is also referred to as ‘Live Forensics’. Memory dumps can be taken for various reasons, for instance a windows user might be facing a Blue Screen error and require technical support to solve this issue, a memory dump in this case can be sent to a service provider such as McAfee for analysis. Although, in our work we are more interested in extracting evidence from the captured memory. There are different file formats for the memory dump used to distinguish between the outputs of different tools. For instance:

- Windows creates a .dmp file - DumpIt creates a .raw file - In a virtual machine, VMware tools creates a .vmem file. Further, the snapshot method creates a .vmsn file in the virtual machine directory and a suspended VM saves .vmss file.

And since some analysis tools were designed to support specific files, tools such as the vmss2core utility can be used to accomplish that. However, conversion might not always be needed especially when a tool such as Bulk extractor is used. This is because it scans and extracts information without parsing the file system in a given image, which makes it compatible to work with various artefacts from memory dumps to Solid State Drives (SSDs) and HDDs. The output of Bulk extractor includes credit Card numbers, email addresses and wordlists that can be imported into a password- cracking software, which is why it is reverent to this series of articles and will be covered in further detail later.

Nevertheless, we discussed that the RAM is split into a space reserved and secured for the Kernel and a larger space for the hosted applications. Now if the acquisition considers both then it is a complete memory dump, otherwise there can be different types of smaller memory dumps as shown below: - Complete: contains the fill physical memory. - Kernel memory dump: limited to the memory in use by the Kernel - Small and mini memory dumps: includes selected parts of memory associated with one or more processes; this is clearly not very sufficient for analysis unless the forensic investigation is intestinally scoped on a particular process

Significance of the Volatile Memory Well-trained criminals attempt to eliminate their footprints on the hard drive which increases the importance of the data stored on the volatile memory. This makes memory dumps an extremely important environment to extract and analyse digital artefacts for both: the kernel and user applications. While this article focuses on harvesting user credentials, other critical information that can be recovered include: - Running processes - DLLs - Encryption keys - Files - Open sockets

How to get a memory dump? There are different methods to obtain memory dumps, at times we rely on a third-party tool to achieve this. For example, DumpIt from moonsols.com is widely utilised by professionals because it is easy-to-use, fast and works on both 32-bit and 64-bit systems. It can be placed on a USB-stick with a size larger than the physical memory of the targeted system and then executed. It will prompt the user one time and if asked to continue then a full memory dump is created in the same directory the tool is running from as shown in Figure 3. It is also crucial to plan the file system used for the USB-stick, for instance, the RAM in my laptop is 8 GB while the maximum size of a file on FAT32 is limited to 32 bits, hence it cannot be used to store files larger than 4 GB! Overall, a good approach is to rely on NTFS in this case.

Figure 3: DumpIt in action. The output of DumpIt is a .raw file

Other third-party tools such as Procdump and PMDump are designed to create a memory dump of selected processes. To do this we require the identifiers for these processes. In windows 7, this can be learned from the Task Manager  Processes (tab). However, the PID column is not listed by default, to display it we should go to View (menu)  Select Columns…  then tick the PID (Process Identifier) and click OK. The PID will then be added to the Task Manager (Processes tab) as shown in Figure 4.

Figure 4: Windows Task Manager can be configured to show the PIDs required by tools such as Procdump and PMDump

Procdump is a tool from the famous Windows Sysinternals and is very well documented. Figure 5 shows how we used this tool to create a memory file for the iexplore.exe PID 4080 with all process memory (therefore the argument –ma was used).

Figure 5: Using Procdump to capture the memory space of a selected process

Similarly, PMDump is another tool that lets you dump memory contents of a process. It supports Windows NT 4.0, 2000, XP, 2003 and Vista, but then, v1.2 worked well on Windows 7 as part of our ongoing experiments. The tool can be used through Command Prompt to display all processes: pmdump –list and then to create a memory dump for the 4080 process, the following command can be used where filename.dmp is any given file name to which the memory will be written pmdump 4080

In addition to using third-party tools to capture memory, Windows Task Manager itself can be used to achieve this objective. Right-click a process and from the pop-up menu select  Create Dump File This memory file will then be created in the path shown in Figure 6.

Figure 6: Windows Task Manager can be used to create memory dups of a process

Nevertheless, it is also possible to rely of the OS’s recovery mechanism. It is known that the blue Screen (BSoD) is forced when the operating system fails to recover from a fatal error, at times this can be due to a rootkit or a malicious process working at the Kernel level. In such cases, Windows creates a memory dump to recover data and to have an evidence of the incident for further technical analysis. By default this file is saved to %SystemRoot%\MEMORY.DMP but this will not be a complete memory dump unless configured otherwise in the Registry. Microsoft article 307973 includes full detail of how to backup and configure the Registry in different flavours of Windows to create full memory dumps when the system crashes. When this configuration is in place, it is also possible to force system crash to create a complete memory dump on a targeted system.

While configuring the Registry is an advanced task, it is required to enable complete memory dumps. Nonetheless, the GUI in Windows can be used to enable Kernel and Small memory dumps and select the path for the MEMORY.DMP file. In Windows 7, these options are available from My Computer (right-click)  Properties  Advanced  Startup and Recovery, Settings.

Nevertheless, in a virtual environment, the VMware tools create a .vmem file; the snapshot method creates a .vmsn file; and a suspended VM saves into a .vmss file in the virtual machine directory. Those checkpoint state files can be

WARNING Use a suitable file system for your USB-stick when your perform memory acquisition! It is crucial to select the right file system for your USB-stick when using a tool such as DumpIt, remember that file size in FAT32 is limited to 32 bits, hence it cannot store files larger than 4 GB while the total physical memory in modern machines is larger than that. NTFS is a good option.

Memory Dumps Integrity There are methods to verify that the collected memory dump is not corrupt and that it has been created properly. For Windows, the dumpchk.exe utility from Microsoft can be used for this purpose. Another note in this regard is in the case of relying on Windows recovery to create a full memory dump, make sure that the pagefile.sys in windows is given a size that is larger than the total physical memory size installed in the system. This is because Windows writes the full memory dump to the pagefile.sys prior to saving it to the .dmp file.

Harvesting user credentials The Volatility Framework is an advanced open-source forensic framework. We will use it to initiate our analysis and demonstrate how to extract Windows 7 usernames and password hashes from the Security Accounts Manager (SAM) file. The SAM file is used in Windows to store user account information such as usernames and passwords. It represents a hive in the registry and is stored in %SystemRoot%\System32\Config\SAM. The SAM file is always locked because it is used by the Operating System. However, a number of techniques can be used to get a copy through: - A backup of the SAM file - From the registry with tools such as pwdump - From a memory dump using tools such as hashdump (part of the Volatility Framework) The passwords in the SAM file are hashed in NT LAN Manager (NTLM) hash, this is currently in version two (NTLMv2). NTLM is the successor of the LM hash used in systems prior to Windows NT but this has been compromised and is not considered a true one-way hash. However, even the current NTLMv2 hash can be cracked with a proper rainbow table attack.

This file can not be accessed while Windows is running but from a memory dump this is indeed possible if we know the right virtual addresses. To start using Volatility, it is required that the OS profile from which the memory dump was acquired is identified correctly. If the system details are unknown, we can use the imageinfo tool to identify the right profile as shown in Figure 7. Otherwise, run the executable followed by the –h option to view all available tools in the volatility framework; e.g. C:\>volatility-2.3.1.standalone.exe -h

Figure 7: Using Vlatility imageinfo to identify the OS’s profile

Figure 7 shows that we have used the Volatility’s stand-alone executable to run the imageinfo tool on the .raw memory dump identified by the –f option. This memory file was obtained using DumpIt. The result suggests that the system was either Win7 32-bit or Win7 32-bit SP1. This indicated that no significant changes to the system were implemented by Microsoft on these systems to allow the framework to distinguish the difference, which is fine because we can then use any (or test both) of the two to continue our analysis.

The final version of this article has been published in the Digital Forensics Magazine (https://www.digitalforensicsmagazine.com/). Full reference: al-Khateeb, H. M., Maple, C. (2014) ‘Memory Forensics: Harvesting Windows Credentials From Volatile Storage’, Digital Forensics Magazine, 2014(19): 32-36. Following this step, it is important to learn the virtual address of both the SYSTEM and the SAM file registry hives in the memory. To do this, Hivelist is the next Volatility plugin/tool to be used. Figure 8 shows how this was done. The raw file was identified by the –f option followed by the hivelist tool to work; and then the Win7SP1x86 profile was used as suggested by the imageinfo tool earlier. The result recovered the virtual addresses for SYSTEM and SAM file to be 0x8c01c008 and 0x8ccac9c8 accordingly. Now that we know this detail, we can use another Volatility tool called Hashdump to extract Windows 7 usernames and password hashes. Figure 8 shows this final command, it has the following parts in order:

- The volatility executable - -f option to link the memory dump file being investigated - The hashdump tool to work - The virtual address of the SYSTEM hive in registry identified by –y - The virtual address of the SAM file hive in registry identified by –s - And finally, the last part is to write the output to a file called Win7-Hashes.txt

Figure 8: hivelist and hashdump are part of the Volatility Framework and can be used to extract Windows usernames and password hashes

To confirm the outcome of this experiment, Figure 9 shows the usernames and password hashes extracted in the previous step.

Figure 9: The usernames and password hashes extracted from Windows 7 using hashdump

While a hash is the outcome of a one way encryption method, the plain text for these can still be recovered using large tables of pre-calculated hashes linked to their original values e.g. rainbow tables. This and other methods to recover these hashes will be discussed in our upcoming article.

Future Work This article is first in a series of experiments to research the tools and techniques used to recover user credentials from volatile memory. Memory acquisition was critically discussed and some of the tools from the Volatility Framework were used to extract Windows 7 credentials. Now that the bases are established, future work will be more focused on memory analyses to recover and locate user information. We argue that such information can be found using one of two main approaches; either by extracting information from pre-identified virtual addresses (our hashdump demonstration is

Q&A Your demonstration was on a 32-bit Operating System, does it work on 64-bit? Hashdump is confirmed to work for memory dumps taken from 32-bit Windows OSs but there is currently a bug for 64-bit systems that is still being dealt with by the developers. It was just last month (March 2014) when the Volatility project manager confirmed in a comment that they have re-wrote tools with a similar bug e.g. lsadump while “the issue with x64 hashdump is still being addressed”, the solution is there and the tool is currently being updated.

References

Michael Hale Ligh, Andrew Case, Jamie Levy, AAron Walters (2014). The Art of Memory Forensics: Detecting Malware and Threats in Windows, Linux, and Mac Memory. John Wiley & Sons; 1 edition (3 Oct. 2014). ISBN: 978-1-118-82509-9