Analysing System Memory

Week 11
Windows maintains a lot of important information
and artifacts that can only be recovered while a
system is powered on. Memory is considered
volatile sources of evidence and can help
reconstruct timelines that may have been
impacted from anti-forensic techniques as they are
more reliable and can provide tamper resistant
results.
Table of Contents

● Type of Evidence
● Physical Memory
● Memory Analysis
Types of Evidence from Memory

What kind of evidence can we get from memory?

As technology and forensic tools evolve, we are starting to
get more and more our of memory forensics.
Types of Evidence

● Running Processes ● Portions of non-volatile evidence

● System Objects ○ Registry
● Active Network Connections ○ Event Logs
○ MFT
● Loaded drivers
● Previously executed console
● User credentials
commands
● Clear-text data that may be
encrypted on the drive
● Data structures
Physical Memory
Like most OS, Windows provides a virtual memory subsystem that can use both RAM
and hard disk space together as a single source of memory for running processes.
So memory on a windows system, therefore is composed of two fundamental
components: physical memory and the pagefile.

Physical memory is simple - its the contents of RAM.

We acquire the contents of physical memory the same way we do an HDD - we take an
image of it. So if you have a 4GB RAM in the device, the image taken will be 4GB.
In most cases, you’ll use software based methods to acquire memory from a windows
system. Most of these tools can run in portable mode which means there is no need for
an installation
These include Mandiant/Fireeye Memorize, Magnet AXIOM Ram capture, and more.

So now that you have a memory, what do we do now?

In the past we’d really just search it manually by running strings and hope for the best.
Its a bit easier these days with tools like Volatility that can parse the data into human
readable format.
Pagefile

● Key component of memory

architecture
● Provides a secondary storage
location
● Has a hidden attribute & protected
by the OS
● Location:
%SYSTEMDRIVE%\[Link]
● Reg key:
HKLM\Current\ControlSet\Control\
Session Manager\Memory
Management\PagingFiles
● Pagefile is used to provide a secondary storage location - typically residing on a
slower fixed drive for data used by running processes that cannot fit within the
physical memory.
● This is all handled behind the scenes by the kernel;s memory management routines.
● Each running process within user-la is allocated a virtual memory space that it can
use on it own.
● The kernel then maintains a table that tracks where eage “page’ in virtual memory
actually resides. Which is either in the physical memory or in the pagefile.

● As you use more RAM to complete tasks on your machine, the paging activity
occurs more frequently which in turn helps with system performance.
Crash Dumps

● Kernel Memory Dump

○ Contains all kernel’s read/write memory pages at the time of the crash
○ Contains list of processes and loaded drivers
● Small Memory Dump (Minidump)
○ Contains limited data
■ Loaded drivers
■ Processor context
■ Kernel call stack
■ Metadata for halted processes
● Complete Memory Dump
○ Contains a full image of physical memory
○ Rarely enabled…
● If your system crashes, windows will automatically
generate a crash dump files that contains some or all
contents of memory,
● They kinda act like a blackbox to help developers
debug and troubleshoot why a crash occurred.
● Either it's a poorly designed app, or poorly written
malware.
● Windows records 3 different levels of crash dump -
user settings would be used to adjust these.
Hibernation Files

● Preserves the state of a running system while drawing the least amount of
power
● Steps:
○ Saves the full contents of physical memory to a file on disk
○ Powers down the machine
● Location: %SYSTEMDRIVE%\[Link]
● Kinda sounds like memory imaging - you’re right!
● Its a compressed version (not raw or bit-by-bit), and
includes some additional metadata
● You’ll need to convert it to a readable format - you
can use AXIOM for that, or use Volatility to parse
into a standard memory image.
Memory Analysis
So now that you know where some of the memory evidence is
sourced from, we can go into the analysis part.
We aren’t going to be doing line by line memory analysis (manual
method), but we will learn how to use some tools and techniques to
parse what we are looking for.
Processes

● Process list = what is running

● Executive Process (EPROCESS) blocks are enumerated kernel data structures
● Memory Forensics tools will extract the following from EPROCESS blocks:
○ Process ID (PID)
○ Parent PID
○ Process Name
○ Process path
○ Process command line
○ Process start and exit times
○ Number of threads and handles
So if you ever use a task manager, or the sysinternals process explorer, and pslist
tools, you can view the process listings.
Through memory analysis, we can reconstruct the same sort of data by enumerating
kernel data structures aka Executive Process (EPROCESS) blocks - which account
for each running process on a system.
● PID - a unique numeric identifier assigned upon process startup
● Parent PID - the ID of the process that was responsible for executing the current
process
● Process name - executable file’s name
● Process path - the fully qualified path to the executable file
● Process command line - any argument parameters supplied to the executable’s
command line
● Process start and exit (if applicable)
Plist extraction using Volatility
To link processes to user/SID: [Link]
This is a typical output of a plist using volatility.
You can combine this evidence with other sources in
the kernel - by doing so, you can reconstruct the SID or
username under which a given process is running.
Its important to remember that process only tracks the
Parent PID and not the name of path. So its on you to
analyze and walk through all PIDs and map out the
parent-child relationships .
Its also important to remember that once a process is
terminated, its not possible to map the parent PID
Handles

● Handles serve as an abstract layer through which user-mode applications can

obtain indirect access to Windows objects:
○ Files
○ Registry keys
○ Security tokens
○ Threads
● Each running process has a handle table
● Whenever a windows API call interact wit an object (like opening a
file), the kernel’s object manager brokers and tracks the access.
● Each running process has a handle table which is maintained by the
kernel memory
● We review handles to provide detailed insight into a running program
behavior.
● What files its reading from, or writing to. The registry keys its
accessing or setting, the devices it connects to, etc. It's very useful
when trying to determine suspicious behavior and identifying if
something is malicious or legitimate.
Suspicious handles found using Mandiant Redline
Sections

● Every process has its own virtual address space

● Section may be mapped to a file or a loaded DLL
● Section can also represent dynamic content (heap or or stack space)
● Virtual Address Descriptor (VAD) tree:
○ Used to identify each section of memory within a process’ address space
○ Can also indicate the security protections in place for any given section
■ Read only or writable, or can be executed
○ More info: [Link]
physical-memory/
● Its essentially a range of addresses, allocated by the memory manager,
that it can use to read/write data and execute code.
Remember when we label this address space as “virtual” because any
given portion of it may reside in physical memory (RAM) or paged out
to the disk (Pagefile).
A process doesn't care which one its used, it's a contiguous series of
addresses.
● The OS ensures that data is swapped in/out of RAM and that any
requested memory page is available upon request.
● Section analysis can allow you to identify all the DLLs loaded by a
running process in memory - this can help you conclude an
executable’s capabilities. Using sections, you can check a DLL;s valid
signature, hash checksums and more - this can help find rogue loaded
DLLs.
● You can also recover portions or mapped files, DLLs, or executables
from a memory acquisition by extracting or dumping a portion of a
section.

● And lastly, section analysis can help identify evidence of process-

tampering (malware running code in memory)
Other Memory Artifacts

● Network Connections:
○ Active & Recently closed connections
○ Can include process name, source & destination IP and port, connection state, and
socket creation time
● Loaded drivers:
○ Review rogue entries (malicious drivers running with elevated privileges)
● Console command history
● Strings in memory
● Credentials