memory forensics with volatility

Memory Forensics With Volatility

Michael CohenSoftware Engineer - Google Inc.

Acknowledgements

Many great researchers in the memory forensics field (and Volatility Contributors):

● Aaron Walters.● Brendan Dolan-Gavitt.● Andreas Schuster.● Michael Hale Ligh.● Andrew Case.● Jamie Levy.● Mike Auty.● ... and many others!

References

Malware Analyst'sCookbook

Michael Hale Ligh,Steven Adair,Blake Hartstein,Matthew Richardhttp://code.google.com/p/malwarecookbook/

http://code.google.com/p/malwarecookbook/source/checkout

http://code.google.com/p/malwarecookbook/source/checkout

Module 1 - Introduction

● Why memory forensics?● What can Volatility do for me?● Symbols and debugging information.

○ How does Volatility support multiple operating systems and versions.

● Memory imaging○ Linux.○ Windows.

Memory Forensics - Why?

● Live response.○ Can quickly triage a system.

● Capture of memory freezes system state.○ As memory is volatile we can minimize interference

with memory.○ Analysis does not use the system APIs.

● Memory analysis technology evolves with time.○ We used to only have grep :-)○ NIST reference image: xp-laptop-2005-06-25.img:

■ Registry dump■ Passwords■ Screenshots

The Volatility Memory Forensics Framework.

● Current release on google code:http://code.google.com/p/volatility/

○ Supports 64 bit windows up to windows 7.● Volatility technology preview (TP):

○ Major refactoring/code rewriting - lots of new features.

○ Ease of use as a library.○ Interface uses IPython - interactive console.○ Memory acquisition drivers included.

● We will be using both but mainly Volatility TP.○ Check with the volatility site for an upcoming

release.○ Subject to lots of changes before release.

http://code.google.com/p/volatility/

http://code.google.com/p/volatility/

A short Volatility Demo

Types and debugging Information.

● Operating systems are generally written in Ctypedef unsigned char uchar;enum { OPT1, OPT2} options;

struct foobar { enum options flags; short int bar; uchar *foo;}

It is generally not possible to predict the memory layout of a C struct without knowing external factors:

● Alignment● Endianess● Bit size● Compiler● Optimizations etc

Unless packed structs.

Types and debugging Information - DWARF.$ readelf --debug-dump=info module.ko <1><10fe>: Abbrev Number: 28 (DW_TAG_structure_type)

<10ff> DW_AT_name : (indirect string, offset: 0x7d7e): task_struct

<1103> DW_AT_byte_size : 5864

<1105> DW_AT_decl_file : 17

<1106> DW_AT_decl_line : 7

<1107> DW_AT_sibling : <0x19c8>

<2><110b>: Abbrev Number: 32 (DW_TAG_member)

<110c> DW_AT_name : (indirect string, offset: 0x254): state

<1110> DW_AT_decl_file : 18


<1113> DW_AT_type : <0x3cf>

<1117> DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0)

<2><111a>: Abbrev Number: 32 (DW_TAG_member)

<111b> DW_AT_name : (indirect string, offset: 0xb200): stack

<111f> DW_AT_decl_file : 18


<1122> DW_AT_type : <0x615>

<1126> DW_AT_data_member_location: 2 byte block: 23 8 (DW_OP_plus_uconst: 8)

Types and debugging Information - PDB.

Types and debugging Information - The Volatility Type system - Profiles.

● A compilation unit is a self consistent unit of compiled code which uses the same memory layout for structs.○ For example, a .obj file or a dll.○ It is important to note that the same struct may have

different layout in different dlls. For example:■ 32 bit processes running on a 64bit operating

system have different definitions for integers.■ Microsoft exports _EPROCESS in the kernel and

in userspace but these are different.● VTypes is a special language for specifying memory

layout of structs and other objects using python data structures.

User Space/Kernel Space


'_EPROCESS' : [ 0x4d0, {

'Pcb' : [ 0x0, ['_KPROCESS']],

'ProcessLock' : [ 0x160, ['_EX_PUSH_LOCK']],

'CreateTime' : [ 0x168, ['_LARGE_INTEGER']],

'ExitTime' : [ 0x170, ['_LARGE_INTEGER']],

'RundownProtect' : [ 0x178, ['_EX_RUNDOWN_REF']],

'UniqueProcessId' : [ 0x180, ['pointer64', ['void']]],

'ActiveProcessLinks' : [ 0x188, ['_LIST_ENTRY']],

'ProcessQuotaUsage' : [ 0x198, ['array', 2, ['unsigned long long']]],

'ProcessQuotaPeak' : [ 0x1a8, ['array', 2, ['unsigned long long']]],

'CommitCharge' : [ 0x1b8, ['unsigned long long']],

'QuotaBlock' : [ 0x1c0, ['pointer64', ['_EPROCESS_QUOTA_BLOCK']]],

'CpuQuotaBlock' : [ 0x1c8, ['pointer64', ['_PS_CPU_QUOTA_BLOCK']]],

'PeakVirtualSize' : [ 0x1d0, ['unsigned long long']],

'VirtualSize' : [ 0x1d8, ['unsigned long long']],

'SessionProcessLinks' : [ 0x1e0, ['_LIST_ENTRY']],

'DebugPort' : [ 0x1f0, ['pointer64', ['void']]],

.....

Struct SizeStruct NameMember Offset

Member Type

Special support for array and pointers (legacy).


● VTypes are autogenerated from debugging symbols:○ Linux: a special module is compiled with debugging

symbols and the DWARF information is extracted.■ Uses pyelftools or dwarfdump.

○ Windows: the pdb files are downloaded from the microsoft symbol server and parsed.■ Uses pdbdump by Brendan Dolan-Gavit.

● VTypes are not enough though!○ Debug information fails to convey semantic

meaning.○ PDB files may be incomplete or not exist - then we

need to reverse engineer the struct members.

https://bitbucket.org/eliben/pyelftools

http://code.google.com/p/pdbdump/


● The volatility object system is built on the vtypes definition language to present an object oriented, automatic parsing system.○ Everything is an object extending obj.BaseObject()○ Definitions are layered:

VType definition.

Overlays

Object classes


● An Overlay is a partial vtype structure with "holes" signified by None which overlays on top of the original VType definition.○ This is used to "correct" the original vtype, while

allowing some aspect of the previous definitions to come through.

'_EPROCESS' : [ 0x4d0, { 'Pcb' : [ 0x0, ['_KPROCESS']], 'ProcessLock' : [ 0x160, ['_EX_PUSH_LOCK']], 'CreateTime' : [ 0x168, '_LARGE_INTEGER']], 'ExitTime' : [ 0x170, ['_LARGE_INTEGER']], .....}],

'_EPROCESS' : [ None, { 'CreateTime' : [ None, ['WinTimeStamp', {}]]], 'ExitTime' : [ None, ['WinTimeStamp', {}]], .....}],

VType Overlay


● The overlay can apply to wide range of operating system versions○ The exact offsets are controlled by the debugging

symbols, but the semantic meaning is given by the overlay.

'_EPROCESS' : [ 0x4d0, { 'Pcb' : [ 0x0, ['_KPROCESS']], 'ProcessLock' : [ 0x160, ['_EX_PUSH_LOCK']], 'CreateTime' : [ 0x168, '_LARGE_INTEGER']], 'ExitTime' : [ 0x170, ['_LARGE_INTEGER']], .....}],


VType Overlay


● Behaviors can be attached to objects via defining specialized classes.○ The VType system instantiates a named class with

the given arguments when a struct member is dereferenced.

○ The class instance can provide extra methods. '_EPROCESS' : [ 0x4d0, { 'Pcb' : [ 0x0, ['_KPROCESS']], 'ProcessLock' : [ 0x160, ['_EX_PUSH_LOCK']], 'CreateTime' : [ 0x168, '_LARGE_INTEGER']], 'ExitTime' : [ 0x170, ['_LARGE_INTEGER']], .....}],


VType Overlay


This is an object representing the _EPROCESS struct.In [1]: task = session.profile._EPROCESS(0xFA8000ACAB30)Out[1]: [_EPROCESS _EPROCESS] @ 0xFA8000ACAB30

There is a CreateTime member which is an instance of the WinTimeStamp class.In [2]: type(task.CreateTime)Out[2]: volatility.plugins.overlays.basic.WinTimeStamp

The WinTimeStamp class knows how to print itself nicely.In [3]: print task.CreateTime2012-02-22 11:28:59

The WinTimeStamp class offers more functionality related to timestamp conversions.In [4]: print task.CreateTime.as_windows_timestamp()129743837397084000


● A Profile is an internally consistent collection of vtypes and definitions.○ Strictly a profile represents a single compilation unit.○ Volatility 2.0 has one global profile

■ Can not represent multiple, contradictory compilation units (e.g. 32bit process on 64bit OS).

● Volatility TP has domain specific profiles.○ A profile therefore represents an internal

implementation of a specialized parser. For example the registry parser consists of vtypes, overlays and classes together forming an API for handling the windows registry.

Supporting multiple operating system versions.

● For windows we have pre-computed profiles from different versions of ntoskrnl.exe.○ Must specify the correct profile to use using the

session.profile variable. (or --profile command line).● For linux we must generate vtypes to

specific kernel version we are analysing.○ This is because the struct layouts vary depending on

kernel configuration. (There are #ifdefs in the middle of the structs).

○ We generate a profile_file which is a zip containing:■ System.map-2.6.32-40-generic■ A special module.ko built with symbols.

Memory Imaging.

Take a permanent copy of physical memory:● Lots of techniques to do this:

○ Hardware based■ Firewire.■ Cold Boot attack.■ Tribble

○ Software base■ Hibernation■ Crash dumps■ Inserting a special driver.■ Debugger APIs.

Hibernation

● When a system hibernates it copies its memory state to disk.○ Volatility can analyse this image.○ Pros

■ Easy to obtain image.■ No prior preparation needed.

○ Cons■ Prior to hibernation, an ACPI pnp event is

transmitted to all drivers:● Network sockets are removed.● Malware may cleanup.

■ Windows only copies in use pages to the hibernation file.

Crashdump - Windows BSOD.

● A crashdump is a standard mechanism for windows debugging.○ Pros:

■ The system stops most running threads during the dump - atomicity is best.

■ Can attach the windows debugger (windbg) to the crash dump. Raw image can be converted to crash dump too.

○ Cons:■ Usually must be pre-configured.■ Only dumps memory used by the kernel (e.g. not

bios areas - page 0).■ System can not resume - so we can not do

differential analysis.

Memory Acquisition tools.

● Volatility TP comes with the winpmem acquisition driver (Experimental):○ For 64 bit windows these must be signed.○ The winpmem driver makes physical memory

accessible via the \\.\pmem device.■ This means you can run Volatility TP directly on

the raw memory device.■ Can produce a crash dump via raw2dmp plugin.

● Other popular options:○ windd by moonsols http://www.moonsols.com/windows-memory-toolkit/

■ Can produce crashdumps etc.■ Only writes image from kernel space and

therefore not suitable for live memory analysis.

http://www.moonsols.com/windows-memory-toolkit/

Windows acquisition - Example

Driver reports CR3 and valid memory ranges

Imager pads gaps with zeros for raw image.

Memory Acquisition tools - Linux.

● Volatility TP comes with a Linux driver pmem.ko○ Must be compiled for the exact kernel version that

should be imaged (this is a Linux requirement).○ Provides a new device in /dev/pmem.○ Can use Volatility TP to analyse the running system.

● Kernel driver normally has to be compiled to the kernel version.○ The linux kernel has symbol versioning. When

loading a module with insmod the kernel ensures the module is compiled for the same version.

○ Not very convenient from an incident response point of view.

Memory acquisition - Linuxscudette@scudette:~/volatility/svn/tools/linux$ sudo apt-get install linux-image-3.0.0-22-generic linux-headers-3.0.0-22-generic

Reading package lists... Done

Building dependency tree

Reading state information... Done

linux-image-3.0.0-22-generic is already the newest version.

linux-headers-3.0.0-22-generic is already the newest version.

0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.

scudette@scudette:~/volatility/svn/tools/linux$ make KVER=3.0.0-22-generic

make -C //lib/modules/3.0.0-22-generic/build CONFIG_DEBUG_INFO=y M=/home/scudette/volatility/svn/tools/linux modules

make[1]: Entering directory `/usr/src/linux-headers-3.0.0-22-generic'

CC [M] /home/scudette/volatility/svn/tools/linux/module.o

CC [M] /home/scudette/volatility/svn/tools/linux/pmem.o

....

Copy to the target machine and then:

# insmod pmem.ko

# dd if=/dev/pmem of=myimage.dd

# rmmod pmem

This is the target kernel image version.

Driver creates a new device

Patching linux kernel modules

● Ideally we want to have a binary kernel module we can insert to any kernel version.○ This can only work if the structs used are stable

across versions.■ The pmem driver is very simple - all real work is

done in userspace so kernel space code is minimized and remains stable across versions.

○ Must bypass the linux kernel's module versioning checks.

○ Andreas Moser has implemented a live module patcher.■ Search the system for other kernel modules.■ Copy the symbol versions to pmem.ko

Patching kernel module - Example

scudette@scudette:~/volatility/svn/tools/linux$ sudo insmod ./module.ko

insmod: error inserting './module.ko': -1 Invalid module format

scudette@scudette:~/volatility/svn/tools/linux$ python ko_patcher.py module.ko patched_module.ko

INFO:root:Module version is 2.6.32-21-generic, kernel version is 2.6.32-40-generic.

INFO:root:All imports found, gathered data from 1 modules.

INFO:root:Checksum mismatch for module_layout.

INFO:root:Kernel Object patched.

scudette@scudette:~/volatility/svn/tools/linux$ sudo insmod ./patched_module.ko

scudette@scudette:~/volatility/svn/tools/linux$

Virtual Machine Imaging

Taking a memory image from a virtual machine is most reliable:

e.g. Virtual Box:VBoxManage debugvm <vmname> dumpguestcore --filename <name>

● Introduction to memory forensics and Volatility○ Symbols types and memory layout.○ The Volatility type system.○ What are Profiles.○ Generating profiles for Linux.

● Memory Imaging○ Different types of images.○ How to image Windows systems.○ How to image Linux systems.○ Live memory analysis with volatility.

Summary for Module 1

Module 2 - Virtual Memory and Paging

● How does virtual memory work?● We can see a string in the image - where

does it come from?● Why do I get a 2gb file when I dump out a

single process address space?

Virtual Memory and Paging.

Paged out

Backed Mem

Shared Memory

Backed Mem

Page File

Physical Memory

Process AVirtual Memory

Process B Virtual Memory

Overcommited

Virt

ual A

ddre

ss

Phy

sica

l A

ddre

ss

FramesPages

Virtual Memory and Paging.● Paging allows different processes to have

their own unique view of physical memory:○ Physical memory can be shared between processes

at different virtual addresses.○ Physical memory can be assigned to a specific

process's use without being accessible from other processes.

○ Processes can request memory to be mapped into their virtual address space which is not yet backed by physical memory (overcommitted).

○ A process's memory can be paged out to disk.○ A process may map a file into its address space -

the kernel will automatically read from the file when a page fault occurs.

Paging in 32 bit model.

Page Directory Index Page Table Index Byte Index

Page DirectoryPage Tables

Physical Memory

CR3

PTN

PTE

Page Frame

Directory Table Base (DTB)

Virtual Address

The CR3 register.

● Paging is done automatically by the MMU in hardware.○ All the CPU has to do is store the address of the

current Page directory table in the CR3 register.○ When the kernel switches task context (to another

process), a new value of CR3 is loaded to point at new page tables.

○ The value of CR3 is key to make sense of a physical memory image.

○ Some imaging tools also capture CR3.

Page Table Entry.

Page Frame number U P Cw Gl L D A Cd Wt O W V

Valid

Prototype

Large Page

Page Faults

● When bit 1 in the PTE is set to 0 (invalid), any access to this page will generate a page fault.○ Note that all other bits of PTE are ignored in this

case. So the PTE can be technically used for OS private data.

○ Page fault handler is a kernel routine which handles the page fault:■ Page may be fetched from page file.■ Page is in transition if Prototype bit is also set.

● A page is transition is waiting to be paged out, but is actually valid still. A page fault here can return it into the working set immediately.

■ Page may be overcommitted and kernel will allocate physical memory for it.

Volatility Address Spaces

● An address space is an object which satisfies read requests.○ Many address spaces satisfy their reads from

another address space - Address Spaces stack.

IA32PagedMemory

MmapFileAddressSpace

read()

An address space can be sparse - i.e. read() to some regions will fail. The address space should implement get_available_addresses() to assist in scanning.

zread() can be used to pad invalid regions with 0.

Volatility Address Spaces

● By default, most plugins will invoke the load_as() plugin.○ This uses an automated voting algorithm to figure

out the correct layering of address spaces (it will call the find_dtb() scanner).

○ loas_as() will populate the session with the physical and kernel address spaces.

● A profile is applied onto an address space in order to instantiate a vtype object:

task = session.profile._EPROCESS(vm=self.kernel_address_space, offset=0x12345)

print task.ImageFileName

'_EPROCESS' : [ 0x260, {

'Pcb' : [ 0x0, ['_KPROCESS']],

'ImageFileName' : [ 0x174, ['array', 16, ['unsigned char']]],

}]

'_KPROCESS' : [ 0x6c, {

'Header' : [ 0x0, ['_DISPATCHER_HEADER']],

'ProfileListHead' : [ 0x10, ['_LIST_ENTRY']],

'DirectoryTableBase' : [ 0x18, ['array', 2, ['unsigned long']]],

How to find the Kernel DTB - Windows

● Many imaging tools already capture the DTB.● Can deduce DTB from any process:

○ When the kernel schedules a process, it must restore CR3 to the process DTB - hence the process DTB is stored in the process struct (task.Pcb.DirectoryTableBase):

○ Every process maps the kernel!Typically scan for "Idle"

In [15]: find_dtb?

find_dtb: A plugin to search for the Directory Table Base for windows systems.

Scans the image for the Idle process.

...

In [16]: find_dtb

-------> find_dtb()

_EPROCESS (P) DTB

0x02813140 0x00187000

0x1179b7dc 0x00490050

How does imaging work?LinuxIn Linux it is more efficient to implement devices through mmap:static int pmem_vma_fault(struct vm_area_struct *vma,

struct vm_fault *vmf) {

loff_t offset = vmf->pgoff << PAGE_SHIFT; /* Offset of faulting page */

unsigned long pfn = (unsigned long)(vmf->pgoff); /* Faulting page */

struct page *page;

/* Map the real page here. */

page = pfn_to_page(pfn);

get_page(page);

vmf->page = page;

return 0;

}

static struct vm_operations_struct pmem_vm_ops = {

.fault = pmem_vma_fault,

};

Listing processes - Linux.

● In linux processes are represented by task_struct structures:

'task_struct': [5864,

'tasks': [576, ['list_head']],

}]

'list_head': [16, {

'next': [0, ['pointer', ['list_head']]],

'prev': [8, ['pointer', ['list_head']]]}]

○ All tasks are connected in a list.○ The init task is always alive and its address is hard

coded into the kernel symbols.

Listing processes - Linux.

prev

next

prev

next

prev

next

Init Task

The Kernel Debugger Block - Windows KDBG.

Blink

Flink

Blink

Flink

Blink

FlinkPsActiveProcessHeadBlink

Flink

KDBG Block

The Kernel Debugger Block - Windows KDBG.

● The kernel debugger uses the KDBG to store information important for debugging.○ The PsActiveProcessHead is a pointer to the list

head of the active processes.● The KDBG is not critical to the operation of

the system, so malware can easily corrupt it.● You can always list the processes by finding

a single _EPROCESS object and following the list around.○ The PsActiveProcessHead is not a real process, so

will need to discard that.

Scanning for the KDBG$ python vol.py -f ~/images/xp-laptop-2005-06-25.img --profile WinXPSP3x86 kdbgscan

Volatile Systems Volatility Framework 2.1_alpha

**************************************************

Instantiating KDBG using: Kernel AS WinXPSP2x86 (5.1.0 32bit)

Offset (V) : 0x8054c060

Offset (P) : 0x54c060

KDBG owner tag check : True

Profile suggestion (KDBGHeader): WinXPSP3x86

Version64 : 0x8054c038 (Major: 15, Minor: 2600)

Service Pack (CmNtCSDVersion) : 2

Build string (NtBuildLab) : 2600.xpsp_sp2_gdr.050301-1519

PsActiveProcessHead : 0x805604d8 (47 processes)

PsLoadedModuleList : 0x8055a420 (127 modules)

KernelBase : 0x804d7000 (Matches MZ: True)

Major (OptionalHeader) : 5

Minor (OptionalHeader) : 1

KPCR : 0xffdff000 (CPU 0)

Listing processes - Windows.$ ./vol.py -f ~/images/win7_trial_64bit.raw --profile=Win7SP0x64 --logging info

In [1]: pslist

------> pslist()

INFO:root:Autodetected physical address space WindowsCrashDumpSpace64

INFO:root:Autodetected virtual address space AMD64PagedMemory@0x00187000 (Kernel AS@0x187000)

INFO:root:KDBG not provided - Volatility will try to automatically scan for it now using plugin.kdbgscan.

INFO:root:Found a KDBG hit [_KDDEBUGGER_DATA64 _KDDEBUGGER_DATA64] @ 0xF80002803070. Hope it works. If not try setting it manually.

Offset (V) Name PID PPID Thds Hnds Sess Wow64 Start Exit

-------------- -------------------- ------ ------ ------ -------- ------ ------ -------------------- --------------------

0xfa80004b09e0 System 4 0 78 489 ------ False 2012-02-22 19:58:20 -

0xfa8000ce97f0 smss.exe 208 4 2 29 ------ False 2012-02-22 19:58:20 -

0xfa8000c006c0 csrss.exe 296 288 9 385 0 False 2012-02-22 19:58:24 -

0xfa8000c92300 wininit.exe 332 288 3 74 0 False 2012-02-22 19:58:30 -

Finding hidden processes - psxview

● Combines the output from several plugins○ _EPROCESS list traversal○ Pool tag scanning.○ CSRSS handles○ Thread scanning.○ Kernel debugger PspCidTable

● Results are always inconsistent○ Some processes just do not show up on some

sources.

In [5]: psxview

------> psxview()

Offset(P) Name PID pslist psscan thrdproc pspcdid csrss

---------- -------------------- ------ ------- ------- -------- ------- -------

0x01f67500 TaskSwitch.exe 1952 True True True True True

0x02000980 wmiprvse.exe 4080 True True True False False

0x02025608 atiptaxx.exe 2040 True True True True True

0x12cd3020 smss.exe 448 False True False False False

0x0fe5f8e0 snmp.exe 1424 False True False False False

0x01f8eb10 winlogon.exe 528 True True True True True

0x02079c18 cmd.exe 2624 True True True True True

0x02218020 PluckSvr.exe 944 True True True True True

0x01ed76b0 PluckTray.exe 2740 True True True True True

0x01f48da0 tcpsvcs.exe 1400 True True True True True

0x01f6db28 msdtc.exe 1076 True True True True True

0x020e0da0 services.exe 580 True True True True True

0x1a192a90 Fast.exe 1960 False True False False False

0x01fa8240 Smc.exe 876 True True True True True

Volatility TP as a library#!/usr/bin/pythonfrom volatility import session

s = session.Session()s.filename = "MyImage.raw"s.profile = "Win7SP1x64"

pslist = s.plugins.pslist()for task in pslist.list_eprocess(): print task.UniqueProcessId, task.ImageFileName

A session is an object which holds all analysis results for the current session.

The module is available from the session object. A module exports methods which we can call.

Normally the vol() helper calls the render() method of the module, but many modules export many other methods.

What could go wrong?

BH Europe 2012: One-byte Modification for Breaking Memory Forensic Analysis specifically attacks these processes:1. Virtual address translation in kernel space.

a. Corrupt the header of Idle process.2. Guessing OS version and Architecture.

a. Change the PE header of kernel.3. Getting kernel objects

a. traversing linked lists or binary treesb. object carving

i. Corrupts the pool tags.The overall effect is that it does not work out of the box!

https://media.blackhat.com/bh-eu-12/Haruyama/bh-eu-12-Haruyama-Memory_Forensic-Slides.pdf



DKOM

Very old technique for unlinking _EPROCESS objects:

BlinkFlink

BlinkFlink

BlinkFlink

PsActiveProcessHead Blink

Flink

KDBG Block

Works because the scheduler uses threads

http://i159.photobucket.com/albums/t141/sovietweasel/hideproc-vmware.jpg



Summary of module 2

● Virtual paging○ Volatility Address spaces

● Analysis techniques○ List following

● Some antiforensic techniques○ DKOM○ Signature subversion.

Module 3

Windows internals:● The PE File format.

○ Finding PE files in memory.

● Scanning for kernel objects in memory.○ psscan, filescan, driverscan

PE Executables

● The PE file format is specifically designed to allow fast and efficient loading of executables into memory.○ The structure of executables on disk is similar to

their structure in memory.○ Imports and Exports are resolved at load time.

PE Overview

http://code.google.com/p/corkami/downloads/detail?name=pe-20110117.pdf



Example of PE Parsing from memoryIn [5]: from volatility.plugins.overlays.windows import pe_vtypes

In [6]: pe = pe_vtypes.PE(address_space=session.kernel_address_space, image_base= session.kdbg.KernBase)

In [7]: p pe.nt_header

[_IMAGE_NT_HEADERS _IMAGE_NT_HEADERS] @ 0x804D70E8

0x00 Signature [unsigned long:Signature]: 0x00004550

0x04 FileHeader [_IMAGE_FILE_HEADER FileHeader] @ 0x804D70EC

0x18 OptionalHeader [_IMAGE_OPTIONAL_HEADER OptionalHeader] @ 0x804D7100

0xF8 Sections <Array 21 x _IMAGE_SECTION_HEADER @ 0x804D71E0>

In [8]: p pe.nt_header.OptionalHeader

[_IMAGE_OPTIONAL_HEADER OptionalHeader] @ 0x804D7100

0x1C ImageBase [unsigned long:ImageBase]: 0x00400000

0x20 SectionAlignment [unsigned long:SectionAlignment]: 0x00000080

0x24 FileAlignment [unsigned long:FileAlignment]: 0x00000080

0x28 MajorOperatingSystemVersion [unsigned short:MajorOperatingSystemVersion]: 0x00000005

0x2A MinorOperatingSystemVersion [unsigned short:MinorOperatingSystemVersion]: 0x00000001

This is the address of ntoskrnl.exe

Version 5.1= Windows XP SP 2

Listing Sections of PE FilesIn [42]: for section in pe.Sections(): print section

('xr-', [String:Name]: '.text\x00\x00\x00', [unsigned long:VirtualAddress]: 0x00001000, 1689600)

('xr-', [String:Name]: 'INITKDBG', [unsigned long:VirtualAddress]: 0x0019D000, 1706496)

('xr-', [String:Name]: 'POOLMI\x00\x00', [unsigned long:VirtualAddress]: 0x001A1000, 1715200)

('xr-', [String:Name]: 'POOLCODE', [unsigned long:VirtualAddress]: 0x001A3000, 1728512)

('xrw', [String:Name]: 'RWEXEC\x00\x00', [unsigned long:VirtualAddress]: 0x001A6000, 1728512)

('-r-', [String:Name]: '.rdata\x00\x00', [unsigned long:VirtualAddress]: 0x001A7000, 1980928)

('-rw', [String:Name]: '.data\x00\x00\x00', [unsigned long:VirtualAddress]: 0x001E4000, 2046976)

('-r-', [String:Name]: '.pdata\x00\x00', [unsigned long:VirtualAddress]: 0x00278000, 2783744)

.....

The peinfo pluginIn [11]: peinfo?

peinfo: Print information about a PE binary.

Dump a PE binary from memory.

Status is shown for each exported function:

- M: The function is mapped into memory.

Parameter Documentation

------------------------------ ----------------------------------------------------------------------

address_space The address space which contains the PE image.

image_base The address of the image base (dos header).

The peinfo pluginIn [3]: peinfo session.kernel_address_space, session.kdbg.KernBase

Machine TimeDateStamp

-------------------- -------------

Machine IMAGE_FILE_MACHINE_AMD64

TimeDateStamp 2009-07-13 23:40:48 UTC+0000

Characteristics IMAGE_FILE_EXECUTABLE_IMAGE, IMAGE_FILE_LARGE_ADDRESS_AWARE

....

Sections (Relative to 0xFFFFF8000261A000):

Perm Name VMA Size

---- -------- -------------- --------------

xr- .text 0x000000001000 0x00000019b800

xr- INITKDBG 0x00000019d000 0x000000003a00

xr- POOLMI 0x0000001a1000 0x000000001c00

....

Data Directories:

- VMA Size

---------------------------------------- -------------- --------------

IMAGE_DIRECTORY_ENTRY_EXPORT 0xfffff80002b43000 0x000000010962

IMAGE_DIRECTORY_ENTRY_IMPORT 0xfffff80002bbccec 0x000000000078

IMAGE_DIRECTORY_ENTRY_RESOURCE 0xfffff80002bbe000 0x000000035d34

...

Other PE Files - ProcessesIn [12]: eprocess = session.profile._EPROCESS(vm=session.kernel_address_space, offset=0x0000fa8000aa0b30)

In [5]: eprocess.Peb.ImageBaseAddress

Out[5]: <Void Pointer to [0xFF120000] (ImageBaseAddress)>

In [14]: pe = pe_vtypes.PE(address_space=eprocess.get_process_address_space(), image_base=eprocess.Peb.ImageBaseAddress)

In [16]: for section in pe.Sections(): print section

('xr-', [String:Name]: '.text\x00\x00\x00', [unsigned long:VirtualAddress]: 0x00001000, 332288)

('-r-', [String:Name]: '.rdata\x00\x00', [unsigned long:VirtualAddress]: 0x00052000, 455168)

('-rw', [String:Name]: '.data\x00\x00\x00', [unsigned long:VirtualAddress]: 0x00070000, 468480)

('-r-', [String:Name]: '.pdata\x00\x00', [unsigned long:VirtualAddress]: 0x00073000, 499712)

('-r-', [String:Name]: '.rsrc\x00\x00\x00', [unsigned long:VirtualAddress]: 0x0007A000, 602112)

('-r-', [String:Name]: '.reloc\x00\x00', [unsigned long:VirtualAddress]: 0x00093000, 606208)

This is the address of a process that comes from pslist

The process Environment Block

The PE file is mapped into the process address space

DLLs

● The _EPROCESS object has 3 lists of dlls loaded:○ eprocess.Peb.Ldr.InInitializationOrderModuleList○ eprocess.Peb.Ldr.InLoadOrderModuleList○ eprocess.Peb.Ldr.InMemoryOrderModuleList

● Unfortunately these are located in the process address space.○ A malicious process can easily unlink their dlls from

these lists.

Process Loaded DLL lists.

In [10]: for x in eprocess.get_load_modules(): print x.FullDllName, hex(x.DllBase)

C:\Windows\system32\SearchIndexer.exe 0xff120000

C:\Windows\SYSTEM32\ntdll.dll 0x76d40000

C:\Windows\system32\kernel32.dll 0x76b20000

C:\Windows\system32\KERNELBASE.dll 0x7fefcd50000

C:\Windows\system32\ADVAPI32.dll 0x7fefd110000

In [11]: for x in eprocess.get_init_modules(): print x.FullDllName, hex(x.DllBase)




In [12]: for x in eprocess.get_mem_modules(): print x.FullDllName, hex(x.DllBase)

C:\Windows\system32\SearchIndexer.exe 0xff120000




DLLs are PE files too.

In [16]: for version in pe.VersionInformation(): print version

( [UnicodeString:Key]: u'CompanyName\x00', [UnicodeString:Value]: u'Microsoft Corporation\x00')

( [UnicodeString:Key]: u'FileDescription\x00', [UnicodeString:Value]: u'Microsoft English Natural Language Server Data and Code\x00')

( [UnicodeString:Key]: u'FileVersion\x00', [UnicodeString:Value]: u'6.1.7600.16385 (win7_rtm.090713-1255)\x00')

( [UnicodeString:Key]: u'InternalName\x00', [UnicodeString:Value]: u'NlsData0009\x00')

Dumping a PE file from memory def WritePEFile(self, fd, address_space, image_base):

dos_header = self.pe_profile._IMAGE_DOS_HEADER(offset=image_base,

vm=address_space)

image_base = dos_header.obj_offset

nt_header = dos_header.NTHeader

# First copy the PE file header, then copy the sections.

data = dos_header.obj_vm.zread(image_base,

nt_header.OptionalHeader.SizeOfHeaders)

fd.seek(0)

fd.write(data)

for section in nt_header.Sections:

data = section.obj_vm.zread(section.VirtualAddress + image_base,

section.SizeOfRawData)

fd.seek(section.PointerToRawData, 0)

fd.write(data)

The PE Image is located in memory.

Copy the headers.

Copy each section.

PE Dumping from memory

● Can be done using a bunch of plugins:○ procdump - Dumps _EPROCESS images using PID.○ dlldump - Dumps DLLs.○ pedump - Generic PE dumper that is used by the

other modules.● Potential problems:

○ Rootkits can easily change the in-memory PE headers. (e.g. Section description etc).■ It is possible to corrupt the headers so the tool

blows up - too much data, huge executables.○ Import Address Table is not patched.○ Not all sections are fully mapped into memory (e.g. .

rsrc not always mapped in).

Dumping packed binaries.

● Normal binaries contain two import thunks:

Packed binaries

● Packed binaries have a very small IAT on disk (just enough for the unpacker).○ The real import table is built in memory ○ but does not contain any function names - only

function pointers.IAT on disk

IAT in memory

dll 1 export table

dll 1 export table

dll 1 export table

dll 1 code

dll 1 code

dll 1 code

Binary Code Section

impscan - Reconstruct IATs

1. Scan all the dlls in the process address space, and enumerate their exports.

2. We disassemble the code segment of the binary, looking for indirect calls through the IAT.

3. Match up these calls with the known dll exports.

4. Create a report or IDAC code to inform IDA about the exports.

ExampleIn [2]: impscan pid=2236

------> impscan(pid=2236)

**************************************************

Process conhost.exe PID 2236

IAT Call Module Function

-------------- -------------- -------------------- --------

0x0000ffddf000 0x07fefd7c2520 GDI32.dll CreateRectRgn

0x0000ffddf018 0x07fefd7c1090 GDI32.dll DeleteObject

0x0000ffddf030 0x07fefd7c1860 GDI32.dll SelectObject

0x0000ffddf038 0x07fefd7c6274 GDI32.dll SelectPalette

0x0000ffddf048 0x07fefd7c222c GDI32.dll DeleteDC

0x0000ffddf070 0x07fefd7c103c GDI32.dll GetStockObject

0x0000ffddf078 0x07fefd7c14a0 GDI32.dll PolyPatBlt

Module 3 Summary

● The PE executable format.○ Relation between PE in memory and PE on disk.○ Dumping out PE from memory.○ Different types of PE files:

■ Processes.■ DLLs.■ Kernel Drivers.

Module 4: Memory Management

● The windows kernel Object Manager.○ Allocation strategy - Pool tags○ Scanning for objects.○ Back references to _EPROCESS objects.○ Scanning vs. List following.

● Process memory management:○ Page File Number database.○ VAD tree.○ Some Malware hiding techniques.

Window Kernel Memory Allocation

● The windows kernel uses Pools to manage allocation:○ Paged pool - can be paged to disk.○ Non paged - For use by critical components which

must not be paged (e.g. Interrupt level).● Allocations come from the pool, and are

tagged using a special identifier "Tag":○ ExAllocatePoolWithTag○ Tags are used to track memory owners and detect

leaks.

Poolmon

Windows Kernel Objects

● The windows Object Manager is responsible for managing allocation/deallocation of objects.○ An object is a managed data structure in the kernel.○ There are many types of objects - basically anything

we require the kernel to manage is an object.○ Allocation functions end up delegating to

ObCreateObject()

Object Allocation Schemehttp://www.codemachine.com/article_objectheader.html

Pool Header

Optional Header

Optional Header

Object Header

ObjectObCreateObject()

Number of optional headers is encoded in the Object Header

http://www.codemachine.com/article_objectheader.html

http://www.codemachine.com/article_objectheader.html

The Volatility Scanning framework

● Specify a set of conditions which all have to match.○ Conditions are tested in order, exit early.○ Conditions can specify a "skipper" - i.e. can return a

number of bytes to skip which can never match.● The user of the scanner calls the scan()

iterator to receive possible matches.● Some useful scanners:

○ Discontiguous Scanner - can efficiently scan Virtual Address Space.

○ VAD Scanner - used to scan memory accessible to a process.

Virtual Address Space

Physical Address Space

Discontiguous Scanners

Discontiguous Scanners.

Scanning for Objectsclass PoolScanDriver(PoolScanFile):

""" Scanner for _DRIVER_OBJECT """

allocation = ['_POOL_HEADER', '_OBJECT_HEADER', '_DRIVER_OBJECT',

'_DRIVER_EXTENSION']

checks = [ ('PoolTagCheck', dict(tag = "Dri\xf6")),

('CheckPoolSize', dict(condition = lambda x: x >= 0xf8)),

('CheckPoolType', dict(paged = True, non_paged = True, free = True)),

('CheckPoolIndex', dict(value = 0)),

]

● We can scan in the physical address space or kernel address space:○ Physical AS can be fooled by process allocations but

is slightly faster.○ Scanning for kernel objects in kernel address space

is sufficient.

Declare header allocation order.

Pool Tag

Scanning for Objects

● Because the size of the object header is variable we can not just calculate the size directly:○ Use a bottom up approach:

Pool Header

Optional Header

Optional Header

Object Header

Object

Allocation Size

Size of Object (e.g. _FILE_OBJECT)

Size of Object Header

Total Size of Object Optional Headers

Windows 8

● The bottom up method does not work on Windows 8:○ Windows 8 uses a binned memory allocator:

■ Each allocation is rounded up to the next bin size.

■ Can not calculate object size from allocation size.■ Need to iterate through all possible header

configurations.○ In addition pool tags are not unique enough

■ e.g. for EPROCESS it is "Proc"● Pool scanning on windows 8 is slower ☹

Object Owners

● When the object manager allocates a kernel object on behalf of a process, sometimes, there is a reference to the _EPROCESS embedded into the _OBJECT_HEADER:○ object_obj.HandleInfo.SingleEntry.Processhttp://computer.forensikblog.de/en/2009/04/linking-file-objects-to-processes.html

In [4]: vol plugins.filescan, address_space=session.kernel_address_space

Offset #Ptr #Hnd Access Owner OwnerPid OwnerName Name

------------------ ---- ---- ------ ------------------ --------- ---------------- ----

0x0000f6fd40004530 15 0 RW-rw- ------------------ --------- ---------------- \Users\testing\AppData\Roaming\Microsoft\Windows\Cookies\Low\index.dat

0x0000f6fd40006050 1 1 RW-r-d 0x0000fa80004b09e0 4 System \Windows\System32\wdi\LogFiles\WdiContextLog.etl.001

0x0000fa8000514dd0 19 1 RW-r-- 0x0000fa80007d09e0 916 svchost.exe \Windows\System32\winevt\Logs\Microsoft-Windows-BranchCacheSMB%4Operational.evtx

http://computer.forensikblog.de/en/2009/04/linking-file-objects-to-processes.html

http://computer.forensikblog.de/en/2009/04/linking-file-objects-to-processes.html

Example: psscan vs. pslist$ vol.py --profile WinXPSP2x86 -f malwarecookbook/15/6/prolaco.vmem psscan

Offset Offset(V) Name PID PPID PDB Time created Time exited

---------- ---------- ---------------- ------ ------ ---------- -------------------- --------------------

0x005f23a0 0xff0dd3a0 rundll32.exe 1260 1724 0x06cc0360 2010-08-11 16:50:29 2010-08-11 16:50:42

0x010f7588 0x80f94588 wuauclt.exe 468 1028 0x06cc0180 2010-08-11 06:09:37

0x01122910 0x80fbf910 svchost.exe 1028 676 0x06cc0120 2010-08-11 06:06:24

0x0113f648 0x80fdc648 1_doc_RCData_61 1336 1136 0x06cc0340 2010-08-11 16:50:20

$ vol.py --profile WinXPSP2x86 -f malwarecookbook/15/6/prolaco.vmem pslist


---------- -------------------- ------ ------ ------ -------- ------ ------ -------------------- --------------------

0x810b1660 System 4 0 56 253 ------ False - -

.... (Not found)

0xff37a4b0 ImmunityDebugge 1136 1724 2 73 0 False 2010-08-11 16:50:19 -

The Page Frame Number (PFN) database (Windows).

● The operating system maintains a database about the allocation status of every physical page in the system.○ Since the page tables exist in the physical address

space, but the OS can only reference the Virtual Address space, there must be a way to quickly access the PTEs that control a particular physical page.

○ The hardware can only do the forward mapping (Virtual to Physical).

○ Hence the operating system needs to keep track of the reverse mapping (Physical Page to PTE).

Paging in 32 bit model.

Page Directory Index Page Table Index Byte Index

Page DirectoryPage Tables

Physical Memory

CR3

PTN

PTE

Page Frame

Directory Table Base (DTB)

Virtual Address

PFN DB Maps PFN to PTE

The PFN Database

● An array of _MMPFN structs, one for every page of physical memory.○ The PFN database start is referenced by kdbg.

MmPfnDatabase.○ To get the PFN of a physical address we just divide

by 0x1000 (i.e. its the page number).○ Index the array of _MMPFN structs (aka the PFN

database) to read the PFN record.● The PFN record contains important

information about the physical page.○ In use/Valid/Paged○ Virtual Address of the PTE which controls this page.

[_MMPFN MmPfnDatabase[200264] ] @ 0xFA800092AD80

0x00 Type [ValueEnumeration:Type]: 0x00000006 (ActiveAndValid)

0x00 u1 [__unnamed_152d u1] @ 0xFA800092AD80

0x08 u2 [__unnamed_152f u2] @ 0xFA800092AD88

0x10 Lock [long:Lock]: 0x40018718

0x10 PteAddress <CType Pointer to [0xF6FC40018718] (PteAddress)>

0x10 PteLong [unsigned long long:PteLong]: 0xFFFFF6FC40018718

0x10 VolatilePteAddress <Void Pointer to [0xF6FC40018718] (VolatilePteAddress)>

0x18 u3 [__unnamed_1534 u3] @ 0xFA800092AD98

0x1C UsedPageTableEntries [unsigned short:UsedPageTableEntries]: 0x00000000

0x1E VaType [unsigned char:VaType]: 0x00000000

0x1F ViewCount [unsigned char:ViewCount]: 0x00000000

0x20 AweReferenceCount [long:AweReferenceCount]: 0x00000080

0x20 OriginalPte [_MMPTE OriginalPte] @ 0xFA800092ADA0

0x28 u4 [__unnamed_153c u4] @ 0xFA800092ADA8

[__unnamed_153c u4] @ 0xFA800092ADA8

0x00 PrototypePte [BitField:PrototypePte]: 0x00000000

0x00 PteFrame [BitField:PteFrame]: 0x00019A18

0x00 Unused [BitField:Unused]: 0x00000000

Page Frame Number

Page is valid.

The PTE address in Kernel Address Space

The physical page containing the PTE.

Physical to Virtual mapping

● Can use the PFN database to map from physical address to virtual address.○ Find the Virtual PTE address for the physical

address. (e.g. 0xF6FC40018718)○ Find the PteFrame (This is the physical address for

the PTE). (e.g. 0x00019A18)○ PTE Physical address is then 0x00019A18718.○ Because there is a virtual mapping to the PTE itself,

we can repeat the process to find the PTE controlling this PTE (i.e. the PDE).■ Use the PFN database to locate the PDE,

PDPDTE, PML4E and DTB, in turn.

ExampleIn [36]: vtop 0xf880030e3000

-------> vtop(0xf880030e3000)

Virtual 0xF880030E3000, Page Directory 0x00187000

pml4e@ 0x00187F88 = 0x2E004863

pdpte@ 0x2E004000 = 0x2E003863

pde@ 0x2E0030C0 = 0x19A18863

pte@ 0x19A18718 = 0x30E48963

PTE mapped@ 0x19A18718 = 0x30E48000

In [37]: ptov 0x30E48000

-------> ptov(0x30E48000)

Physical Address 0x0000000030E48000 => Virtual Address 0x0000F880030E3000

DTB @ 0x0000000000187000

PML4E @ 0x0000000000187F88

PDPDE @ 0x000000002E004000

PDE @ 0x000000002E0030C0

PTE @ 0x0000000019A18718

Physical Address

PFN DB is used to connect all the levels.

DTB for this page is found.

In [35]: pfn 0x30E48

-------> pfn(0x30E48)

PFN 0x00030E48 at kernel address 0x0000FA800092AD80

flink 00000000 blink / share count 0000000000000001

pteaddress (VAS) 0x0000F6FC40018718 (Phys AS) 0x0000000019A18718

reference count 0001 color 0

containing page 0x00019A18 ActiveAndValid M

Modified

Finding hidden processes using PFN

● Every process has its own address space.○ Hence every process has its own DTB.○ Perform the physical to virtual mapping of all the

physical pages, and find all the DTBs.○ Compare to the DTBs of known processes.

● This is actually very hard for a rootkit to hide.

Finding hidden processes using PFN$ python vol.py -f ~/images/win7_trial_64bit.dmp --profile=Win7SP0x64 dtbscan

DTB _EPROCESS Image Name

-------------- -------------- ----------

0x000000187000 0xfa800096a9e0 System

0x00001f915000 0xfa8001d4b630 svchost.exe

0x0000209de000 0xfa8000bbdb30 �&�.exe0x00001b2c8000 0xfa8001ea5b30 spoolsv.exe

0x0000211a4000 0xfa8001dbfb30 svchost.exe

0x00002ceb9000 0xfa8000a2d060 svchost.exe

0x00002178b000 0xfa8001db5b30 svchost.exe

0x000022e75000 0xfa8000bbd060 conhost.exe

0x000022192000 0xfa8001d03ac0 lsm.exe

0x000019295000 0xfa80020bfb30 sppsvc.exe

0x00001d3a2000 0xfa8001fd9890 svchost.exe

0x00002573b000 0xfa8001974630 winlogon.exe

-0x00000001000 -------------- Process not Found!

0x000021533000 0xfa8001e905b0 svchost.exe

0x00001d5c7000 0xfa8001dd7800 explorer.exe

.....

Process Memory management - The Vad Tree.

● Windows manages process memory through 2 mechanisms:○ Ultimately pages are assigned through the page

tables and the PFN database.○ The Virtual Memory Address Descriptors (VAD)

maintain a high level overview of the pages assigned to a process.

○ A binary tree in memory of virtual memory assigned to a process.

○ The kernel uses the VAD tree to manage the page tables for this process.

The VAD tree: A process-eye view of physical memory - Brendan Dolan-Gavitt digitalinvestigation 4S (2007) S62–S64

Inspecting the VADIn [2]: vad pid=4012

------> vad(pid=4012)

Pid: 4012 dd.exe

VAD lev start end com - - Protect Filename

---------- --- ---------- ---------- ---- ------- ------ -------------------- --------

0x81edc7e0 0 0x30 0x12f 3 Private READWRITE

0x8220fad0 1 0x10 0x10 1 Private READWRITE

0x81ff0398 2 0x20 0x20 1 Private READWRITE

0x820ee328 1 0x400 0x40d 2 Mapped Exe EXECUTE_WRITECOPY \dd\UnicodeRelease\dd.exe

0x82068e78 2 0x140 0x23f 12 Private READWRITE

0x81f1b548 3 0x130 0x132 0 Mapped READONLY

0x81f338b0 3 0x250 0x25f 0 Mapped READWRITE

0x81ffa408 4 0x240 0x24f 6 Private READWRITE

0x81eef6d8 6 0x2c0 0x300 0 Mapped READONLY \WINDOWS\system32\sortkey.nls

0xff94a1d0 6 0x330 0x332 0 Mapped READONLY \WINDOWS\system32\ctype.nls

0x8220e848 7 0x320 0x32f 8 Private READWRITE

0x8136f140 10 0x37f 0x37f 0 Mapped READONLY

0x82216830 2 0x7c900 0x7c9af 5 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\ntdll.dll

0x820c9308 3 0x7c800 0x7c8f3 5 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\kernel32.dll

0x81f16390 4 0x10000 0x10005 2 Mapped Exe EXECUTE_WRITECOPY \dd\UnicodeRelease\getopt.dll

Mapped DLLs are shared between processes.

vadinfo$ vol.py -f xp-laptop-2005-06-25.img --profile WinXPSP2x86 --pid 4012 vadinfo

....

VAD node @ 0x820c9308 Start 0x7c800000 End 0x7c8f3fff Tag Vad

Flags: CommitCharge: 5, ImageMap: 1, Protection: 7

Protection: PAGE_EXECUTE_WRITECOPY

ControlArea @820e24b8 Segment e165b3d8

Dereference list: Flink 00000000, Blink 00000000

NumberOfSectionReferences: 1 NumberOfPfnReferences: 119

NumberOfMappedViews: 41 NumberOfUserReferences: 42

WaitingForDeletion Event: 00000000

Control Flags: Accessed: 1, File: 1, HadUserReference: 1, Image: 1

FileObject @821745e0 FileBuffer @ e17c2460 , Name: \WINDOWS\system32\kernel32.dll

First prototype PTE: e165b410 Last contiguous PTE: fffffffc

Flags2: Inherit: 1

Using the VAD to find hidden files.$ vol.py --profile WinXPSP2x86 -f malwarecookbook/15/6/prolaco.vmem

Welcome to the volatility interactive shell!

In [1]: psscan

Offset Offset(V) Name PID PPID PDB Time created Time exited

---------- ---------- ---------------- ------ ------ ---------- -------------------- --------------------

0x005f23a0 0xff0dd3a0 rundll32.exe 1260 1724 0x06cc0360 2010-08-11 16:50:29 2010-08-11 16:50:42

0x010f7588 0x80f94588 wuauclt.exe 468 1028 0x06cc0180 2010-08-11 06:09:37

0x01122910 0x80fbf910 svchost.exe 1028 676 0x06cc0120 2010-08-11 06:06:24

0x0113f648 0x80fdc648 1_doc_RCData_61 1336 1136 0x06cc0340 2010-08-11 16:50:20

...

In [2]: vad eprocess=0x80fdc648

Pid: 1336 1_doc_RCData_61


---------- --- ---------- ---------- ---- ------- ------ -------------------- --------

0xff1418a8 0 0x400 0x454 48 Mapped Exe EXECUTE_WRITECOPY \Documents and Settings\Administrator\Desktop\1_doc_RCData_612.exe

0x80fddab0 1 0x10 0x10 1 Private READWRITE

0xff277bc8 2 0x20 0x20 1 Private READWRITE

0xff083310 3 0x30 0x22f 4 Private READWRITE

0xff149fa8 4 0x230 0x232 0 Mapped READONLY

This is the hidden process.

The original Executable location.

Using the vad to double check loaded dlls.

● As we mentioned previously there are 3 lists of loaded dlls in the Peb:○ In loaded order.○ In Init order.○ In Memory order.

● Malware can easily unlink a module from these lists, but its harder to manipulate the VAD.

The ldrmodules plugin.$ vol.py --profile WinXPSP2x86 -f malwarecookbook/stuxnet.vmem --pid 680 --verbose ldrmodules

Pid Process Base InLoad InInit InMem MappedPath

-------- -------------------- ---------- ------ ------ ----- ----------

1928 lsass.exe 0x00080000 False False False -

1928 lsass.exe 0x7c900000 True True True \WINDOWS\system32\ntdll.dll

1928 lsass.exe 0x77c00000 True True True \WINDOWS\system32\version.dll

1928 lsass.exe 0x01000000 True False True -

1928 lsass.exe 0x5b860000 True True True \WINDOWS\system32\netapi32.dll

1928 lsass.exe 0x76bf0000 True True True \WINDOWS\system32\psapi.dll

1928 lsass.exe 0x77c10000 True True True \WINDOWS\system32\msvcrt.dll

1928 lsass.exe 0x77dd0000 True True True \WINDOWS\system32\advapi32.dll

1928 lsass.exe 0x7c9c0000 True True True \WINDOWS\system32\shell32.dll

1928 lsass.exe 0x00870000 True True True -

1928 lsass.exe 0x76f20000 True True True \WINDOWS\system32\dnsapi.dll

1928 lsass.exe 0x5d090000 True True True \WINDOWS\system32\comctl32.dll

1928 lsass.exe 0x71aa0000 True True True \WINDOWS\system32\ws2help.dll

1928 lsass.exe 0x77b20000 True True True \WINDOWS\system32\msasn1.dll

How can we get an executable area without being in the module lists and not having file mapping?

Process Hollowing

● Malware can attempt to hide by using process hollowing:1. Create a new process using a legitimate

executable, but do not start it.2. Free the memory section that contains the

ImageBase from the executable.3. Allocate a new memory region in the new

process, and copy malicious code into it.a. VirtualAllocEx, WriteProcessMemory

4. Resume the start thread from the new executable.

Malware Analyst's Cookbook - Michael Hale Ligh, Steven Adair, Blake Hartstein, Matthew Richard

How does that look in memory?$ vol.py --profile WinXPSP2x86 -f malwarecookbook/stuxnet.vmem

In [1]: pslist pid=868


---------- -------------------- ------ ------ ------ -------- ------ ------ -------------------- --------------------

0x81c498c8 lsass.exe 868 668 2 23 0 False 2011-06-03 04:26:55 -

In [3]: vad eprocess=0x81c498c8

Pid: 868 lsass.exe


---------- --- ---------- ---------- ---- ------- ------ -------------------- --------

0x81f459d0 0 0x210 0x21f 0 Mapped READWRITE

0x822e7e70 1 0x80 0xf9 0 Mapped Exe EXECUTE_READWRITE

0x81fc8520 2 0x10 0x10 1 Private READWRITE

...

0x8209b818 3 0x200 0x20f 6 Private READWRITE

0x8209c3d0 1 0x7c900 0x7c9ae 5 Mapped Exe EXECUTE_WRITECOPY \WINDOWS\system32\ntdll.dll

0x81f1ef08 2 0x1000 0x1005 2 Mapped Exe EXECUTE_READWRITE

0x81fa64b0 3 0x240 0x280 0 Mapped READONLY \WINDOWS\system32\locale.nls

0x81c970a8 4 0x220 0x235 0 Mapped READONLY \WINDOWS\system32\unicod

Executable memory which is not backed by a file????

In [7]: task = session.profile._EPROCESS(vm=session.kernel_address_space, offset=0x81c498c8)

In [8]: dump task.get_process_address_space(), 0x80000

------> dump(task.get_process_address_space(), 0x80000)

0x00080000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ..............

0x00080010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......

0x00080020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

0x00080030 00 00 00 00 00 00 00 00 00 00 00 00 08 01 00 00 ................

0x00080040 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 ........!..L.!Th

0x00080050 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f is.program.canno

0x00080060 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 t.be.run.in.DOS.

0x00080070 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 mode....$.......

0x00080080 c7 1c 48 b9 83 7d 26 ea 83 7d 26 ea 83 7d 26 ea ..H..}&..}&..}&.

0x00080090 a4 bb 4b ea 81 7d 26 ea 9d 2f a2 ea 88 7d 26 ea ..K..}&../...}&.

Module 4: Summary

● Scanning for objects in kernel memory.○ Discontiguous scanners.

● Examining the PFN database○ dtbscan○ physical to virtual mapping.

● The VAD tree○ Finding evidence of VirtualAllocEx and

WritePrecessMemory.○ Dll injections, process hollowing.

Module 5: Hooking

● Hooking means to change the flow control of execution to take control of certain code paths.○ Malware uses hooking to monitor and filter various

operations.○ e.g. File operations can be subverted to prevent

security software from seeing malware specific files.○ HTTP traffic can be intercepted even prior to

encryption - used for credential stealing etc.● Security software has similar goals - hence

many security applications also hook.

Kernel hooking - ssdt

● The system dispatcher table is used to control what driver can service requests from userspace.○ Not really useful on new versions of windows due to

patchguard.● ssdt plugin: Entry 0x0073: 0x8060bc6c (NtOpenEventPair) owned by ntoskrnl.exe

Entry 0x0074: 0x8056e26a (NtOpenFile) owned by ntoskrnl.exe

Entry 0x0075: 0x8056bab6 (NtOpenIoCompletion) owned by ntoskrnl.exe

Entry 0x0076: 0x805ca2ac (NtOpenJobObject) owned by ntoskrnl.exe

Entry 0x0077: 0x80619f68 (NtOpenKey) owned by ntoskrnl.exe

Entry 0x0078: 0x8060c064 (NtOpenMutant) owned by ntoskrnl.exe

Entry 0x0079: 0x805e8fcc (NtOpenObjectAuditAlarm) owned by ntoskrnl.exe

Entry 0x007a: 0xfca2953e (NtOpenProcess) owned by lanmandrv.sys

Entry 0x007b: 0x805e229e (NtOpenProcessToken) owned by ntoskrnl.exe

Entry 0x007c: 0x805e1ea4 (NtOpenProcessTokenEx) owned by ntoskrnl.exe

Kernel hooking - Drivers.

● In windows IO operations on a device are sent to a driver in an IO Request Packet (IRP):○ The IRP contains the data for the IO operation as

well as a completion routine.○ The user space program is free to continue with

other tasks while waiting for the IO.○ The IRP is sent to the driver, and is services

asyncronously.● There are several types of IRPs - each type

is handled by a different dispatch routing in the driver.


● The windows _DRIVER_OBJECT:In [10]: driverscan address_space=session.kernel_address_space

Offset(P) #Ptr #Hnd Start Size Service Key Name Driver Name

---------- ---- ---- ---------- ---------- -------------------- ------------ -----------

0x81e97b28 3 0 0xf8711000 0x8900 Gpc Gpc \Driver\Gpc

0x81e97f38 7 0 0xf819f000 0x10e00 PSched PSched \Driver\PSched

0x81f7dda0 3 0 0xf88f9000 0x4a80 Msfs Msfs \FileSystem\Msfs

In [11]: d = session.profile._DRIVER_OBJECT(0x81f7dda0)

In [12]: p d

[_DRIVER_OBJECT _DRIVER_OBJECT] @ 0x81F7DDA0

0x1C DriverName [_UNICODE_STRING DriverName] @ 0x81F7DDBC

0x38 MajorFunction <IndexedArray 28 x Pointer @ 0x81F7DDD8>

In [13]: p d.MajorFunction

<IndexedArray 28 x Pointer @ 0x81F7DDD8>

0x0000 <Function Pointer to [0xF88FA2B0] (IRP_MJ_CREATE)>

0x0002 <Function Pointer to [0xF88FAD74] (IRP_MJ_CLOSE)>

0x0003 <Function Pointer to [0xF88F9E62] (IRP_MJ_READ)>

0x0004 <Function Pointer to [0xF88FA0B4] (IRP_MJ_WRITE)>

Scan for drivers in the kernel address space.

Instantiate a _DRIVER_OBJECT at this address.

Each element of this array points to a different function.


● When an IO Request Packet (IRP) is created by the kernel for this device, the kernel uses the MajorFunction table to pass the IRP to the driver for processing.

● A couple of ways for subversion○ Malware can install their own handler for this device

so it legitimately receives the IRP for processing (layered model).

○ A malicious driver can insert a detour in another driver to intercept IRPs intended for the legitimate driver.

Driver 1

Driver 2

Driver 3

IRP

Driver 1

Driver 2

Driver 3

IRP

Driver 1

Driver 2

Driver 3

IRP

Malicious DriverMalicious Driver

Detour hooking through the Major Function Table

Normal handling of IRP

Attaching to device as a filter driver.

Kernel hooking - driverirp

● driverirp scans for drivers and enumerates their major functions. These functions are then located in their respective driver.

In [15]: driverirp

....

**************************************************

DriverName: Teefer

DriverStart: 0xf837d000

DriverSize: 0x1d000

DriverStartIo: 0x0

Func Name Func Addr Module

---- ------------------------------------ ---------- ------------------------------

0 IRP_MJ_CREATE 0xf83852c0 Teefer.sys

1 IRP_MJ_CREATE_NAMED_PIPE 0x805031be \WINDOWS\system32\ntoskrnl.exe

2 IRP_MJ_CLOSE 0xf8385380 Teefer.sys

3 IRP_MJ_READ 0xf8386e40 Teefer.sys

4 IRP_MJ_WRITE 0xf8386e10 Teefer.sys

5 IRP_MJ_QUERY_INFORMATION 0x805031be \WINDOWS\system32\ntoskrnl.exe

6 IRP_MJ_SET_INFORMATION 0x805031be \WINDOWS\system32\ntoskrnl.exe

This driver only handles some IRPs

Usermode hooks

● Malware can intercept functions used by user mode programs.

IAT in memory

dll 1 code

dll 1 code

Binary Code Section

Malware Code

Malware Code

Legitimate process

Detour/Trampoline

https://citizenlab.org/wp-content/uploads/2012/07/image29-500.png

Trampoline hook installed

Hijack code is located in an injected memory region

FinFisher - A commercial rootkit.

https://citizenlab.org/2012/07/from-bahrain-with-love-finfishers-spy-kit-exposed/








Registry Dumping

● The windows registry is a central location for configuration data.○ A rich source of evidence in a digital investigation.○ There are many tools that can analyse registry files.

● The registry is cached in memory○ Registry data is stored in hives.○ Hives are divided into HBins.○ HBins are cached in memory.

● Volatility has a full registry parser and a bunch of modules to deal with registry.

Forensic Analysis of the Windows Registry in Memory. - Brendan Dolan-Gavitt. DFRWS 2008

http://www.dfrws.org/2008/proceedings/p26-dolan-gavitt.pdf




Registry in Memory

_CMHIVE: System _CMHIVE: SoftwareLinked list

HBIN

HBIN

HBIN

Not resident

Hive.Storage.Map[].Directory[].Table[].BlockAddress

Structure is very similar to a page table which refers to HBINS. If a HBIN is not frequently used it will be paged out (i.e. not memory resident). When a program attempts to read a key which is contained in this HBIN - the HBIN will be paged into memory.

Registry in MemoryIn [5]: hivescan

------> hivescan()

Offset(V) Offset(P) Name

0xe102e008 0x02837008 [no name] @ 0xe102e008

0xe1035b60 0x0283db60 \Device\HarddiskVolume1\WINDOWS\system32\config\system @ 0xe1035b60

0xe1558578 0x02d63578 [no name] @ 0xe1558578

.....

In [9]: printkey key="Software"

Legend: (S) = Stable (V) = Volatile

----------------------------

Registry: \Device\HarddiskVolume1\Documents and Settings\NetworkService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat @ 0xe1bf1b60

Key name: Software (S)

Last updated: 2005-03-18 21:42:02

Subkeys:

(S) Microsoft

....

Registry analysis from memory.

● There are some excellent forensic tools for registry analysis:○ Regripper○ Registry Decoder○ Encase/FTK and other commercial tools

● But these tools typically only work with registry files...○ So we need to dump out the registry into files.

Dumping out the registryIn [11]: regdump?

regdump: Dump all registry hives into a dump directory.

Parameter Documentation

------------------------------ -----------------------------------------------------

hive_offset A list of hive offsets as found by hivelist (virtual

address). If not provided we call hivescan ourselves

and dump all hives found.

dump_dir Directory in which to dump hive files.

In [12]: regdump dump_dir="/tmp/"

**************************************************

Dumping \Device\HarddiskVolume1\WINDOWS\system32\config\system @ 0xe1035b60 into "/tmp/system @ 0xe1035b60"

Dumped 5312512 bytes

**************************************************

Dumping \Device\HarddiskVolume1\Documents and Settings\Sarah\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat @ 0xe1ecd008 into "/tmp/UsrClass_dat @ 0xe1ecd008"

Dumped 8192 bytes

Domain Specific Profiles

● Memory analysis of modules other than the kernel.○ Usually we do not have symbols for applications.○ We often need different profiles for applications than

the kernel.● Still a lot of research to do in this area.

Example: svcscan

● Windows drivers are loaded through the service control manager (SCM).○ The SCM is a process (services.exe) which keeps

additional accounting on which services are currently registered.

○ The process memory can be analysed.○ We can carve the process memory for tag

signatures of _SERVICE_RECORD objects.■ Use the VadScanner to only look at the process

memory.○ A malicious kernel driver may remove itself from the

module list but will remain in the SCM internal lists.

svcscanIn [14]: svcscan

Offset: 0x6e1e90

Order: 1

Process ID: -

Service Name: Abiosdsk

Display Name: Abiosdsk

Service Type: SERVICE_KERNEL_DRIVER

Service State: SERVICE_STOPPED

Binary Path: -

Offset: 0x6e1f20

Order: 2

Process ID: -

Service Name: abp480n5

Display Name: abp480n5

Service Type: SERVICE_KERNEL_DRIVER

Service State: SERVICE_STOPPED

Binary Path: -

Netscan - tcpip.sys

● The windows TCP/IP stack is implemented by tcpip.sys○ No public symbols available.○ However... Reverse engineering shows basic

structures:■ _TCP_ENDPOINT■ _UDP_ENDPOINT■ _TCP_LISTENER

○ These have well recognized pool tags.○ We can scan for these but structs must be reversed

for each version of windows.○ Information is mostly private to the tcpip.sys module.

Windows 7: netscanIn [7]: netscan

Offset(P) Proto Local Address Remote Address State Pid Owner Created

-------------- -------- -------------------- -------------------- ---------------- ----- -------------- -------

0x00000f882a30 TCPv4 0.0.0.0:135 0.0.0.0:0 LISTENING 628 svchost.exe -

0x00001121b7b0 TCPv6 :::135 :::0 LISTENING 628 svchost.exe -

0x000017de8980 TCPv4 0.0.0.0:49153 0.0.0.0:0 LISTENING 444 lsass.exe -

0x000017de8980 TCPv6 :::49153 :::0 LISTENING 444 lsass.exe -

0x000017f35240 TCPv4 0.0.0.0:49155 0.0.0.0:0 LISTENING 880 svchost.exe -

0x000017f362b0 TCPv4 0.0.0.0:49155 0.0.0.0:0 LISTENING 880 svchost.exe -

0x000017f362b0 TCPv6 :::49155 :::0 LISTENING 880 svchost.exe -

0x00001725d010 TCPv4 :49359 93.184.220.20:80 CLOSED 2820 iexplore.exe -

0x000017270530 TCPv4 10.0.2.15:49363 173.194.35.38:80 ESTABLISHED 2820 iexplore.exe -

0x000017285010 TCPv4 :49341 82.165.218.111:80 CLOSED 2820 iexplore.exe -

0x000017288a90 TCPv4 10.0.2.15:49254 74.125.31.157:80 CLOSE_WAIT 2820 iexplore.exe -

0x00001728f6b0 TCPv4 10.0.2.15:49171 204.245.34.130:80 ESTABLISHED 2820 iexplore.exe -

0x000017291ba0 TCPv4 10.0.2.15:49347 173.194.35.36:80 CLOSE_WAIT 2820 iexplore.exe -

0x000017292cf0 TCPv4 :49369 82.165.218.111:80 CLOSED 1892 iexplore.exe -

0x0000174e2cf0 TCPv4 :49368 82.165.218.111:80 CLOSED 2820 iexplore.exe -

0x0000174f9440 TCPv4 10.0.2.15:49296 74.125.127.148:80 CLOSE_WAIT 2820 iexplore.exe -

0x000017527cf0 TCPv4 :49358 93.184.220.20:80 CLOSED 2820 iexplore.exe -

0x0000175288b0 TCPv4 :49373 82.165.218.111:80 CLOSED 2820 iexplore.exe

Windows XP: connections and socketsIn [3]: connections

Offset (V) Local Address Remote Address Pid

---------- ------------------------- ------------------------- ------

0x820869b0 127.0.0.1:1055 127.0.0.1:1056 2160

0xffa2baf0 127.0.0.1:1056 127.0.0.1:1055 2160

0x8220c008 192.168.2.7:1077 64.62.243.144:80 2392

0x81f11e70 192.168.2.7:1082 205.161.7.134:80 2392

0x8220d6b8 192.168.2.7:1066 199.239.137.200:80 2392

In [4]: sockets

Offset (V) PID Port Proto Protocol Address Create Time

---------- ------ ------ ------ --------------- --------------- -----------

0x82004e98 984 1027 17 UDP 0.0.0.0 2005-06-25 16:48:02

0x82052e98 4 138 17 UDP 192.168.2.7 2005-06-25 16:47:48

0x821cad08 1400 19 17 UDP 0.0.0.0 2005-06-25 16:48:00

0x81341308 4 0 47 GRE 0.0.0.0 2005-06-25 16:48:13

0x82036008 1948 1030 6 TCP 0.0.0.0 2005-06-25 16:48:05

0x81fdf968 592 500 17 UDP 0.0.0.0 2005-06-25 16:47:59

Summary for Module 5 - Detecting malware.

● Kernel Hooking● Userspace Hooking● Domain specific profiles:

○ Registry Dumping○ Service Control Manager○ Network connections.

memory forensics with volatility

Documents

sys 0x805031be

textx00x00x00

datax00x00x00

windowssystem32kernel32

windowssystem32ntdll

windowssystem32searchindexer

windowssystem32kernelbase

rdatax00x00