Lecture notes—22/10/18

In many forensics cases, you encounter the system that is up and running. Earlier, forensic experts
use to yank the plug and used to acquire the system. However, in doing so, you may lose potential
information which resides in the memory. These information can help you with finding encryption
keys, running processes, network connections, and so on.

Further, lots of cases involve investigating Trojan or other malware which may lead to sensitive
information being copied to other systems. There may be other cases where anomalous or troubling
traffic in the firewall and IDS (Intrusion detection system) logs are detected.

Note: An intrusion detection system (IDS) is a system that monitors network traffic for suspicious
activity and issues alerts when such activity is discovered. While anomaly detection and reporting is
the primary function, some intrusion detection systems are capable of taking actions when malicious
acitivity or anomalous traffic is detected, including blocking traffic sent from suspicious IP addresses.

The above situations require the investigator to perform live analysis which is collecting data from a
system while it is still running. However, analysing a live system comes with a price and this price can
be best explained via Locard’s Exchange principle.

Locard's Exchange Principle

When we perform a live analysis, first thing which we should keep in mind is that no matter what
you do, some or the other changes will happen in the system. You will end up in leaving your
footprint over the system. You may change running processes, network connections time out or
created (when you are trying to transfer the data to other machine via networks). Even when you
are acquiring the images, changes are happening as you are opening new applications, you are
saving it in new hard drives and so on and so forth. All these changes can be collectively explained by
Locard's Exchange Principle.

In the early 20th century, Dr. Edmond Locard's work in the area of forensic science and crime scene
reconstruction became known as Locard's Exchange Principle. This principle states, in essence, that
when two objects come into contact, material is exchanged or transferred between them.

This usually occurs after a car hits something or when an investigator examines a body and locates
material that seems out of place. This same principle applies to the digital realm. For example, when
two computers communicate via a network, information is exchanged between them. Information
about one computer will appear in process memory and/or log files on the other. When a peripheral
such as removable storage device (a thumb drive, an iPod, or the like) is attached to a Windows
computer system, information about the device will remain resident on the computer. When an
investigator interacts with a live system, changes will occur to that system as programs are executed
and data is copied from the system. These changes might be transient (process memory, network
connections) or permanent (log files, Registry entries).
Programs that we use to collect information might have other effects on a live system. For example,
a program might need to read several Registry keys, and the paths to those keys will be read into
memory. Windows XP systems perform application prefetching, so if the investigator runs a program
that the user has already run on the system, the last access and modification times of the prefetch
file (as well as the contents of the file itself) for that application will be modified. If the program that
the investigator runs hasn't been used before, a new prefetch file will be created in the Prefetch
directory.

Investigators not only need to understand that these changes will occur, they must also document
those changes and be able to explain the effects their actions had on the system, to a reasonable
extent. For example, as an investigator you should be able to determine which .pf files in the XP
Prefetch directory are a result of your efforts and which are the result of user activities. The same is
true for Registry values. As with the application prefetching capabilities of Windows XR your actions
will have an effect on the system Registry. Specifically, entries may appear in the Registry, and as
such the LastWrite times of the Registry keys will be updated. Some of these changes might not be a
direct result of your tools or actions but rather are made by the shell (i.e., Windows Explorer), due
simply to the fact that the system is live and running.

By testing and understanding the tools you use, you will be able to document and explain what
artifacts found on a system are the result of your efforts and which are the result of actions taken by
a user or an attacker.

Here are the few things which we can acquire while doing live analysis:

System Information like date, time, when was the system started last when was it shut down last
and so on

Processes information like active processes

Network Information

Logged on users

Clipboard contents

Command history

Let us see what are some built in commands or free utilities can be used to extract out these
information. Make sure to redirect result outside of the suspect machine by using greater than or
Windows Netcat.

date /t & time /t to display system date and time (windows inbuilt)

uptime is a free utility to display when was the system rebooted

psinfo is used to display system information.

ipconfig (windows builtin) to check whether the network interface is running

To look for unusual processes, we can use task list or ps services like:

Tasklist /svc; psservices; pslist

To list currently loaded DLLs, we use listdlls or process explorer.

To view open files, we use psfile or open files.

Show network connections, we can use fport or netstat.

And to show logged in users, we use psloggedon or logonsessions.

To view clipped content, we use pclip.

And to view logs, we use Windows event viewer.

However, the main crucial part of the live analysis is to analyse physical memory. Before analysing it
first we should ask ourselves, how can we acquire the physical memory? What do I mean by
acquiring? How should we create a bitstream image of the memory like we were doing for the hard
disk image. Well, there are various tools which I will discuss towards the end of this lecture. But, for
starting let us discuss other options at low level so as to improve our understanding of how these
tools might be functioning.

Hardware Devices

In a paper by Brian Carrier and Joe Grand, titled “A Hardware-Based memory acquisition procedure
for digital investigations” in 2004, concept for a hardware expansion card dubbed Tribble was
proposed. This card can be used to retrieve the contents of physical memory to an external storage.
Using hardware device on the system will allow an investigator minimal footprint on the system. In
the paper, the authors stated that they had built a proof-of-concept Tribble device that could be
plugged into a PC bus before an incident occurs. This card is disabled until a physical switch on the
back of the system is pressed. The card cannot easily be detected by an attacker and the acquisition
procedure does not rely on untrusted resources.

The major advantage of the hardware devices are that the chances of data becoming obscured in
some manner is minimized as they do not require any additional software in the system. However,
the major limitation of this approach is that the hardware need to be installed before the incident
happens.

Firewire

Firewire is another device that can help you out with collecting physical memory data. Firewire is
another connector just like USB that can be used to add peripherals to your computer. Firewire is
used to connect digital camcorders, external hard drives and other devices.

So how Firewire can be helpful in collecting memory data?

Firewire devices use direct memory access (DMA), meaning that they can access the system memory
without having to go through the CPU. If an investigator has a controller device that contains
appropriate software and is capable of writing a command into a specific area of the fire wire
devices’s memory space than investigator can potentially get all the memory dump. Adam Boileau
first gave a method to cheat the target Windows-based OS to give the acquisition tool Direct
Memory Access right (Boileau, A.: Hit by a Bus: Physical Access Attacks with FireWire.
SecurityAssessment.com). This method does not need any pre-installation. FireWire ports are
equipped with many modern computers, even if there is not such a port that already integrated on
the system motherboard, it could be expanded through a PCMCIA or PCI Express slot.

Although this method has emerged and has been used by forensic experts for some years, there are
still problems such as weak stability in dealing with Windows-based systems and might run into a
BSoD (Blue Screen of Death) state when try to access the UMA (Upper Memory Area) [9] or other
spaces that were not mapped into system memory. You can find more details about this in this
paper: Live Memory Acquisition through FireWire by Lei Zhang, Lianhai Wang, Ruichao Zhang,
Shuhui Zhang, and Yang Zhou (2011).

Crash Dumps:

If you want to obtain an untainted copy of the content of RAM from a Windows system, perhaps the
only way to do that is to generate full crash dump. The reason for this is that when a crash dump
occurs, the system state is frozen and the contents of RAM are written to the disk. This preserves the
state of the system and ensures that not alterations are made to the system, beginning at the time
the crash dump was initiated.

However, there are couple of issues. First, not all systems generate full crash dumps by default.
Second, by default, windows systems do not generate crash dumps on command.

Let’s come to first issue: There are three types of crash dump: small, kernel, and complete crash
dump. What we are looking for is the complete crash dump because this is where we can find the
complete contents of RAM. Depending on various operating systems and settings, these can
generate either small, kernel or complete crash dumps. Further, in Microsoft documentations, it is
stated that complete crash dumps are not available on systems with more than 2GB of RAM. This is
due to the space requirements as well as the time it will take to complete the crash dump process.
There are ways in which system administrators and IT managers who are setting up and configuring
systems before an incident occurs, but the registry key settings can provide some significant clues
for an investigator. For example, if the system was configured to generate a complete crash dump
and administrator reported seeing Blue screen of death, the investigator should expect to see a
complete crash dump file on the system.

Let us assume that we have the option set to perform full crash dump, but how to perform it via
command? It turns out that there’s a registry key that can be set to cause a crash dump when the
right ctrl key is held down and the scroll lock key is pressed twice. However, once this key is set the
system must be rebooted for the setting to take effect.

Limitations of this method: Some Windows systems do not generate full crash dumps by default. In
addition, modifying a system to accept the keystroke sequence to create a crash dump requires a
reboot and must be done ahead of time to be used effectively for incident response. Even if this
configuration change has been made, the crash dump process will still create a file equal in size to
physical memory on the hard drive. To do so, the page file must be configured to be equal to at least
the size of physical memory plus 1 MB. This is an additional step that must be corrected to use this
method of capturing the contents of physical memory; it's one that is not often followed.
Hibernation File

When a Windows (Windows 2000 or later) system "hibernates," the Power Manager saves the
compressed contents of physical memory to a file called Hiberfil.sys in the root directory of the
system volume. This file is large enough to hold the uncompressed contents of physical memory, but
compression is used to minimize disk I/O and to improve resume-from-hibernation performance.
During the boot process, if a valid Hiberfil.sys file is located, the NTLDR will load the file's contents
into physical memory and transfer control to code within the kernel that handles resuming system
operation after a hibernation (loading drivers and so on). This functionality is most often found on
laptop systems. Here are the pros and cons:

Pros: Analyzing the contents of a hibernation file could give you a clue as to what was happening on
the system at some point in the past.

Cons: The hibernation file is compressed and in most cases will not contain the current contents of
memory. (The hibernation file might be significantly out of date.)

DD

Our famous dd command can be used to collect the contents of physical memory by accessing the
\Device\PhysicalMemory object from user mode. The following command line can be used to
capture the contents of RAM in the file ram.img on the local system:

D:\tools>dd if=\\.\PhysicalMemory of=ram.img bs=4096 conv=noerror

Other tools use a process similar to dd.exe to capture the contents of RAM. ProDiscover IR (version
4.8 was used in writing this book) allows the investigator to collect the contents of physical memory
(as well as system BIOS) via a remote server applet that can be distributed to a system via removable
storage media (CD, thumb drive, etc.) or via the network.

One of the problems with this technique, however, is that as of Windows 2003 SP1, access to the
\Device\PhysicalMemory object has been restricted from user mode. That is, only kernel drivers are
allowed to use this object. To address this issue, GMG Systems produced a new utility called KntDD,
which is part of" the KnTTools set of utilities. According to the licensing for KnTTools, the utilities are
available for private sale to law enforcement personnel and bona fide security professionals.

One of the aspects of using dd.exe, and tools like it, that the investigator needs to keep in mind is
Locard's Exchange Principle. To use dd.exe to collect the contents of RAM, dd.exe must be loaded
into RAM as a running process. This means that memory space is used and other processes might
have pages that are written out to the page file. Another aspect of these tools to keep in mind is that
they do not freeze the state of the system, as occurs when a crash dump is generated. This means
that while the tool is reading though the contents of RAM, as the thirtieth "page" is being read, the
eleventh page could change as the process using that page continues to run. The amount of time it
ultimately takes to complete the dump depends on factors such as processor speed and rates of bus
and disk I/O. The question then becomes, are these changes that occur in the limited amount of
time enough to affect the results of your analysis?
Other well-known Windows memory acquisition tools.

The open source MoonSols Windows memory toolkit is a host-based Windows memory acquisition
toolkit. It is very easy to use. When you run DumpIt, a tool from this toolkit, from a USB, the raw
memory dump will be generated and then written to the same directory you are running DumpIt
from. The other host-based Window's memory acquisition tools I recommend include winen.exe
from Guidance Software, MemoryDD from ManTech, FTK Imager from Access Data, and Belkasoft
Live RAM Capturer.

Cold Boot Attack

Consider a scenario where you encountered a machine with a full disk encryption, and if you do not
have the password to log into the system, you cannot start the investigation. However, what we can
do is if we can dump the entire memory of the system (if the system is on) and then if we can extract
the encryption keys from the memory our job will be done. To do that, we try to cold boot the
running computer and possibly reboot the machine from a USB to dump out memories to USB.

Cold booting is the process of turning the computer off and then on again quickly without letting the
operating system shut down cleanly. More detail here: Lest We Remember: Cold Boot Attacks on
Encryption Keys by J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William
Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten (2008).

In this paper, the authors have found that RAM isn’t completely erased when it no longer has
power. These researchers also developed a toolkit to dump out the memory and extract encryption
keys. A bootable image called a scraper.bin is used to dump computer memory to a USB. Then a
utility called USB Dump will dump the RAM from the USB to your forensics system. They developed
AES key finder and RSA key finder to search for keys from memory. You can read the entire process
in the paper or in the edx video.

After seeing so many approaches to acquire the memory, let us now discuss what to do with all the
content? How should we analyse the memory.

Memory Analysis

The commercial tools such as F-Response and the forensic toolkit allow examiners to conduct
forensic acquisition remotely by running an agent on a suspect machine. Once we have a physical
memory image dumped, how do we extract information such as running processes, registry data,
event logs, network traffic and web history, et cetera from the memory image for forensic analysis?

One possibility is to use the command called strings that extract out all the printable strings from the
memory dump (we have already seen this command). However, there is one main problem with this
approach. It will not be provide the overall context to the information that is found. For example, is
the string recovered from the memory dump is a part of word processing or text document, or was
copied to the system clipboard.
Well, you can again go to the famous tools which are designed to do the job for you. Some of the
tools are

1. WindowsSCOPE (commercial tool)

2. Redline Memoryze from FireEye (free tool)

3. Volatility framework (open source)—demo available at edx course.

4. Helix-3 is a powerful tool to do both volatile and non-volatile analysis. You can find the demo of
the tool on edx course and I would like to encourage you to check it out. This tool has a collection of
forensics tools for data acquisition, preservation, and analysis. While Helix3 Pro is a commercial tool,
they also have a free version, Helix 2009R1.

What we will see is how these tools work. What are the basics that you need to take into
considerations when you are doing the memory analysis

Analysing physical memory dump:

We will focus on parsing information regarding processes from a RAM dump. This is due to
the fact that majority of the literature on RAM dump analysis focuses on process analysis. So
let us first discuss what happens when process is created. You would have done it sometime
in your operating system course. Let us first understand the data structures related to the
processes:

Data Structures

Each Windows process is represented by an executive process (EPROCESS) structure.

Besides containing many attributes relating to a process, an EPROCESS contains and points
to a number of other related data structures. For example, each process has one or more
threads, each represented by an executive thread (ETHREAD) structure. The EPROCESS
and most of its related data structures exist in system address space. One exception is the
process environment block (PEB), which exists in the process address space. You can read
more details in this book: Mark E. Russinovich and David A. Solomon, Windows Internals,
fourth edition, Chapter 6 (Redmond, WA: Microsoft Press, 2005). I will keep to the basics
here.

One important point to note about the data structure of Eprocess is that the size and the values
of these structures change not only between the operating system versions but also between
the service packs of the same version of operating system. You can view the contents of these
data structures via microsoft debugging tools and a utility created by Andreas Schuster
known as LiveKD.exe. The details are given in windows analysis book.

If you look at the Eprocess data structure, an important element you will find is known as
process environment block (PEB). PEB contains lot of information, but we will be mostly
interested in the following information:

1) A pointer to the loader data structure that points to DLLs used by the process
2) A pointer to the image base address, where we can expect to find the beginning of the
executable image file.

3) A pointer to the process parameters structure, which maintains the DLL path, the path to
the executable image, and the command line used to launch the process.

Now, let us see what happens when a process is created (high level details). A Windows
subsystem process is created when an application calls (or eventually ends up in) one of the
process-creation functions, such as CreateProcess, CreateProcessAsUser,
CreateProcessWithTokenW, or CreateProcessWithLogonW. Creating a Windows process
consists of several stages carried out in three parts of the operating system: the Windows
client-side library Kernel32.dll (in the case of the CreateProcessAsUser,
CreateProcessWithTokenW, and CreateProcessWithLogonW routines, part of the work is first
done in Advapi32.dll), the Windows executive, and the Windows subsystem process (Csrss).

1) The file (.exe) to be executed is opened. During this stage, the appropriate parent process
(command prompt, win 16) is identified.

2) The Eprocess object is created. The kernel process block, the process environment block,
and the initial address space are also set up.

3) The initial thread is created

4) The windows subsystem is notified of the creation of the new process and thread, along
with the ID of the process’s creator and a flag to identify whether the process belongs to a
windows process.

5) Execution of the initial thread starts. At this point, the process environment has been set up
and resources have been allocated for the process’s thread(s) to use.

6) The initialization of the address space is completed in the context of new process and
thread.

At this point, the process now consumes space in memory in accordance with Eprocess
structure and PEB structure. The process has at least one thread and may begin consuming
additional memory resources as the process itself executes.

Parsing Processes Contents:

Basically you need the following: you want to locate and enumerate all the active process list.
All the processes are linked together in a doubly link list manner. Thus, if you find one
Eprocess block, ideally you should be able to find all the process blocks by following this
doubly link list. However, here is the problem with this approach. It is possible for a process
to unlink itself from other processes making it invisible to process viewers and memory
analysers. This just requires altering the forward and backward links of the neighbouring
processes. One possibility to overcome this disadvantage is use the characterstics of Eprocess
blocks. And this is the technique that is used by ptfinder.pl script written by Andreas Schuster.
ptfinder.pl Perl script written by Andreas Schuster can be used to enumerate all the processes
and threads located in the memory dump. The process can be found in detail in the paper
titled “Searching for processes and Threads in microsoft windows memory dump”, 2006.
There are other perl scripts written by the author of windows forensic analysis book, Harlan
Carvey. These scripts are as follows:

1) Lsproc.pl: This scrip list all the processes from the RAM dump file. The command is:

lsproc.pl mem.dmp

This command will basically have six columns corresponding to each active process it finds:
The word proc (anticipating it is process not thread), the parent process ID, the process ID,
name of the process, the offset of the process structure within the dump file, and creation time
of the process.
If your run the command on your system, you may find that in the output some processes
may have (x) after process name. This indicates that the processes have exited. In these cases,
the contents of the physical memory have been freed for use but have not been overwritten
yet, so it would seem that some information is retained in physical memroy following a
reboot.

Interesting Fact: It has been observed that some of the time stamps on the processes (output
from these perl scripts) are older than the system reboot time. Question is how is this
possible? It is possible that the data survived the reboot. There don’t seem to be any
specifications that require that when a windows system shuts down or suffers a crash dump,
the contents of the physical memory are zeroed out or wiped. It is possible that the contents
of physical memory remain in their previous state if they are not overwritten when the system
restarted. Many BIOS have a feature to overwrite memory during boot as a part of RAM test,
but this feature is usually disabled to speed up the boot process.

2) lspd.pl: This script allows you to list the details of a particular process. The command line
is:
lspd.pl mem.dmp offset

Here offset is the process offset recovered from lsproc output. lspd.pl follows all the pointers
provided by Eprocess structure and then gives you all the required information about the
processes.
3) lspm.pl: This script allows you to use the information provided in the process structure
within the memory and locate all the pages the process used that were still in memory when
the contents were dumped. With the help of lspm.pl, and strings command you can actually
find which string is associated with which process. Command:

lspm.pl mem.dmp offset

This command will extract the available pages from the dump file and will write them to the
file within the current working directory.

4) lspi.pl: This script locates the beginning of the executable image for the process. If the
image base address offset does indeed lead to an executable image file, lspi.pl will locate the
pages that make up the rest of the executable image file.

Lspi.pl mem.dmp offset