Memory Forensic in Incident

Response
and Threat Hunting
 Agent Based: Enterprise and Remote
System Analysis
• Remote System Incident Response &
Forensics:
Incident Response -> Compromised System
• Remote Enterprise Incident Response &
Forensics:
Incident Response -> Enterprise Network
 Enterprise Incident Response(Forensic
Deployable Agent Models)
Remote Access Agent:
• Provides connector to Raw disk and memory access only.
Pros:
• Great for targeted analysis:-
- Registry
- File Querying
- Quick Artifact Examination
-Tends to be cheaper solution
Cons:
• Poor for file carving, stream extraction and memory analysis because
remote data has to traverse the network for local processing traverse.
e.g. Memory analysis may require entire RAM image to be transferred to
analysis system to perform analysis
• Latency is an issue.
Remote Analysis Agent:
• Agent contains code to perform on system analysis
• Can perform both quick extraction and add file carving, stream
extraction and memory analysis on system.
Pros:
• Great for targeted or drop analysis of system:
- Registry
- File querying and scanning
- Quick and/or deep artifact examination
- Memory Analysis
Cons:
• Tends to be a resource log need to time scan to be done when system
is not being utilized.
• Tends to be more expensive solution.
• Usually, require a controller to manage the agents and reporting.
 F-Response Enterprise
• F-Response is a forensic, e-discovery, and incident
response connection and collection application.
• It is license based.
• It provides direct, read-only access, to remote
physical machine as well as remote cloud storage
providers.
• It provides a simple optional imaging capability
for collecting F-Response presented data from
multiple sources.
 F-Response Functions
• F-Response Enterprise functions as a single
executable on the remote target computer
that requires no drivers or installation
components, as well as no reboot when
deployed and started.
• It gives us access to any file and contents on
the remote system content(Registry Files,
Database Files etc)
 KAPE
• KAPE is an efficient and highly configurable triage program
that will target essentially any device or storage location, find
forensically useful artifacts, and parse them within a few
minutes.
• KAPE is a multi-function program that primarily: 1) collects
files and 2) processes collected files with one or more
programs.
Features:
• Portable(no install)
• Flexible & customizable
• Collect locked system files and ADS
• Fast
• Allows for easy standardization of what teams collect
 Why Kape?

Forensically Sound
• Full metadata preservation
• Detailed audit logs
Robust
• Supports volume shadows copies
• Extracts alternate data streams
Flexible
• Handles locked files
• Reduplication of files via SHA-1
Extensible
• Customize it to our investigative needs
• Create your own targets and modules
 Target Collection

C:\>

• Where the data is --target • Where to copy the

• Drive Letter data to
• Directory • What data to collect • Directory
• F-Response • File System • UNC Path
• Evidence of execution • VHD/VHDX container

--tsource --tdest
tsource :
drive letter or directory to search. This should be
formatted as C, D; or F:\ .

target:
target configuration to run, without the extension.
Get list of all available targets with -- tlist switch.

tdest:
directory where files should be copied to. It will be
created if it does not exist. This can be a regular directory or a
UNC path.
 Advanced Options
• --vss : Find, mount and search all Volume Shadow
Copies on –tsource. Default-false. Set true to process.
• --vhd/--vhdx/--zv : Create vhdx virtual hard drive from
contents of –tdest. This switch is used as a part of
filename for vhdx file.
• --debug : When true, enables debug messages. This
will result in more details as to what Kape is doing in
background as it runs.
• --trace : When true, enables trace message. This will
result in an even large amount of information to be
generated about what Kape is doing as it runs.
 Endpoint Detection and Response:
Capabilities
• Host- based continuous monitoring.
-Threat Hunting
-IR Support
-Anomaly Detection
• Agent send large volume of endpoint and network
activity to central database.
- Pattern analysis, stacking and indicator matching
- Historical searches for hunting, scoping and
remediation
- Real-time visibility and analytics
• Force multiplier for security team.
 How EDR works?
• Endpoint detection and response tools work by
monitoring endpoint and network events and
recording the information in a central database
where further analysis, detection, investigation,
reporting, and alerting take place. A software agent
installed on the host system provides the
foundation for event monitoring and reporting.
• Ongoing monitoring and detection are facilitated
through the use of analytic tools. These tools
identify tasks that can improve a company’s overall
state of security by identifying, responding to, and
deflecting internal threats and external attacks.
 Why is Endpoint importance?
• Visibility is crucial during an intrusion.
• Where the data is == Where the action is
• Best place to collect necessary data at scale
- Process objects and file extensions
- Command-line and process trees
- Unusual Windows API activity
- File, service and registry changes
- Networking / local DNS, APR, pipes, sockets
• Monitoring both inside and outside the
perimeter.
 Need of EDR
• EDR monitors endpoints to detect suspicious
activities and capture data for forensic and
security investigations, focusing on each stage of
an attack.
• The EDR console can show you specific details
about an attack: where it started, what kind of
attack it is, where it went, how it is behaving and
when it began.
• The EDR solution can identify anomalous
behaviour and determine whether it may
represent a threat.
 EDR Challenges
• EDR platforms are not “enterprise forensics tools”
- EDR does not collect a complete set of data
- Few have ability to perform triage, disk or memory
acquisition
- Typically noisy and lead to artifact pollution
• EDR is more forward facing and forensics is more
historical
- Deep-dive forensics can help fill in gaps and find root
cause
• Knowledgeable analysts and hunters are still required
- Threat intelligence and indicators are highly utilized
 EDR and Memory Forensics
• In- memory detection provides advanced capabilities.
- Archival of Command-line data per process
- Recording of host-based Network Activity including
local DNS cache, sockets, ARP etc
- Tracking of new Process handles and execution tracing
-Identification of common DLL injection and hooking
(rootkit) detection techniques
- Analyzing suspicious Threat creation and memory
allocation
• Required to detect many PS, WMI and file less attacks.
• Forensics and memory analysis skills enable effective
use of EDR by analysts and hunters.
 Why Memory Forensics?
Everything in OS traverses RAM
• Processes and threads
• Malware(including rootkit technologies)
• Network sockets, URLs, IP addresses
• Open files
• User generated content
-Passwords, cache, clipboards
• Encryption Keys
• Hardware and software configuration
• Windows registry keys and event logs
 Memory Analysis Advantages
• Best place to identify malicious software activity
 Study running system configuration
 Identify inconsistencies (contradiction) in system
 Bypass packers, binary obfuscators, rootkits (including kernel
mode) and other hiding tools.
• Analyze and track recent activity on the system
 Identify all recent activity- in context
 Profile user or attacker activities
• Collect evidence that cannot be found anywhere else
 Memory-Only malware
 Chat threads
 Internet activities
 What is Memory Forensics?
• Study of data captured from memory of a target system
• Ideal analysis include physical memory data (from RAM) as
well as Page File (or SWAP space) data

• Capture Raw Memory

Acquire

• Establish Context
Context • Find key Memory Offsets

• Analyze Data For Significant Elements

Analyze • Recover Evidence
 Some tools by which we dump
• DumpIt.exe
memory:
- http://www.moonsols.com/2011/07/18/moonsols-dumpit-goes-
mainstream/
• win32dd.exe / win64dd.exe
- Author : Matthew Suiche
- http://www.moonsols.com/products/
• Mandiant Redline
- http://www.mandiant.com/products/free_software/redline/
• Hibernation File
- Contains a compressed RAM image
- %SystemDrive%\hiberfil.sys
• Memory Dump
- %WINDIR%\Memory.DMP
 Virtual Machine Memory Acquisition
• VMware (Fusion/Workstation/Server/Player)
.vmem file=raw memory image
• Microsoft Hyper-V
.bin file=raw memory image
• Parallels
.mem file=raw memory image
• VirtualBox
.sav file=partial memory image
 Hibernation File Analysis
• The hibernation file (hiberfil.sys) is the file used by default
by Microsoft Windows to save the machine’s state as part of the
hibernation process.
• Compressed copy of RAM at time of hibernation.
• Some tools can decompress to raw:
- Volatility imagecopy
- Comae hiber2bin.exe
- Arsenal Hibernation Recon
• Many tools can analyze natively
- Bulk Extractor
- Internet Evidence Finder
- Volatility
-Passware
 Windows Memory Analysis
1. Identify Context
• Find the Kernel Processor Control Region(KPCR)
2. Parse Memory Structure
• Executive Process (EProcess) blocks
• Process Environment (PEB) blocks
• Tracks DLLs loaded
• Virtual Address Descriptors (VAD) Tree
• List of process memory sections
• Kernel modules
• Drivers
3. Scan for Outliers
• Unlinked processes, DLLs, sockets and threads
• Unmapped pages with execute privileges
• Hook detection
• Known heuristics and signatures
4. Look for anomalies and cross-view data
 KDBG
VAD tree

EPROCESS

Process
Environment Handles Access Tokens Threads
Block(PEB)

SID Group
SID
Object Thread
Group Id Group
DLL SID
 Some terminology
• PEB: Describe the code that was loaded by
process
• Handles: The object it is using
• Access tokens: Permission of process
• VAD: Memory section that owned by process
• Threads: To execute code
 Volatility
• Volatility is one of the best open source software
programs for analyzing RAM in 32 bit/64 bit systems.
• It supports analysis for Linux, Windows, Mac, and
Android systems.
• It is based on Python and can be run on Windows,
Linux, and Mac systems.
• It can analyze raw dumps, crash dumps, VMware
dumps (.vmem), virtual box dumps, and many others.
• Installation
The Volatility software may be downloaded from here-
https://code.google.com/p/volatility/downloads/list
 How to use Volatility?
• Getting Help :
# vol.py –h (show options and supported plugins)
# vol.py plugin –h (show plugin usage)
# vol.py plugin --info (show available OS profiles)
• Sample Command Line :
# vol.py -f image --profile=profile plugin
• Identify System Profile :
imageinfo - Display memory image metadata
# vol.py –f mem.img imageinfo
• Using Environment Variables :
Set name of memory image (takes place of -f )
# export VOLATILITY_LOCATION=file:///images/mem.img
Set profile type (takes place of --profile= )
# export VOLATILITY_PROFILE=Win10x64_14393
 Image Identification: imageinfo
• vol.py -f memory.img imageinfo
• imageinfo interrogates the memory image and returns
information such as the system date and time when the memory
image was acquired, the Kernel Data Debugger Block(KDBG),
or starting point for identification of structures in memory system
information like number of processors and most importantly, OS
time and service pack information.
• This information is important because it provides –profile value
that we will include when using the rest of volatility plugins.
• Note: The imageinfo plugin will not work on hibernation files
unless the correct profile is given in advance. This is because
important structure definitions vary between different operating
systems.
 Image Identification: kdbgscan
• vol.py -f /memory/hiberfil.sys imagecopy -o
hiberfil.raw –profile=WinXPSP2x86
• kdbgscan is designed to positively identify the correct
profile and the correct KDBG address (if there happen to be
multiple). This plugin scans for the KDBGHeader
signatures linked to Volatility profiles and applies sanity
checks to reduce false positives. The verbosity of the output
and number of sanity checks that can be performed depends
on whether Volatility can find a DTB, so if you already
know the correct profile (or if you have a profile suggestion
from imageinfo), then make sure you use it.
• Convert crash dump and hibernation files to raw memory
images.
 Finding the First “Hit”
When we are handed a memory image and review it for signs of
intrusion or malware, then we must follow these steps:
1. Identify Rogue Process
2. Analyze process DLLs & handles
3. Review network artifacts
4. Look for evidence of code injection
5. Check for signs of a rootkit
6. Dump suspicious processes and drivers
Traditional Malware Detection:
1. Signature
2. Contradiction
3. Heuristic/ behavioural
 Six Steps Methodology
1. Identify rogue processes: Malware often hides its
behaviour behind processes that on the surface may seem
legitimate. Uncovering these involves identifying what
processes are running, the location in the operating system
they are running from, and verifying that only legitimate
processes are in use. Sometimes processes are hidden in
plain sight where adversaries change a single letter in a
process name. Other times, they will attempt to execute a
process from an illegitimate source.
2. Analyze process DLLs and handles: Once a process or
multiple processes have been identified as rogue, the next
step is to examine the DLL files associated with the
process as well as other factors such as account
information.
3. Review network artifacts: Malware, especially multi-stage
malware, requires connection to the internet. Even systems that
are fully compromised often beacon out to C2 servers. Active and
listening network connections are contained within the memory of
these systems. Identifying external host IP addresses may give
some insight into what type of compromise has taken place.
4. Look for evidence of code injection: Techniques such as
process hollowing and unmapped sections of the memory are
often used by advanced malware coders. Memory analysis tools
assist analysts with finding the evidence of these techniques.
5. Check for signs of a rootkit: Achieving persistence is a goal
with many external threat actors. If they are able to achieve the
initial compromise of the system, it is critical that they maintain
that.
6. Dump suspicious process and drivers: After locating any
suspicious processes or executables, analysts need to be able to
acquire them for later analysis with additional tools.
 Step 1
Identify Rogue Processes
 Identify Rogue Processes: Plugins
• pslist – Print all running processes within EPROCESS double
linked list.
# vol.py pslist
• psscan - Scan physical memory for EPROCESS blocks.
# vol.py psscan
• pstree - Display parent-process relationships(using EPROCESS
linked list).
# vol.py pstree
• malprocfind – Automatically identify suspicious system process
# vol.py malprocfind
• processbl – Compare process and loaded DLLs with a baseline.
# vol.py processbl
 Step 2
Analyzing Process Objects Plugins:
• dlllist - List of loaded dlls by process
-p Show information only for specific processes (PIDs)
# vol.py dlllist –p 1022,868
• Cmdline - Display command-line arguments for each process
# vol.py cmdscan
• getsids - Print process security identifiers
-p Show information only for specific PIDs
# vol.py getsids –p 868
• handles - List of open handles for each process
-p Show information only for specific PIDs
-t Display only handles of a certain type
{Process, Thread, Key, Event, File, Mutant, Token, Port}
# vol.py handles –p 868 –t File, Key
 Plugins:
• Mutantscan - Scan memory for mutant
objects(KMUTANT)
• Svcscan - Scan memory for Windows Service
Information, Windows Service Records, giving
into on processes and drivers
• Seviceb1 - Compare services with baseline
image
 Security Identifiers(SID)
-> A security identifier (SID) is a unique value of
variable length that is used to identify a security
principal or security group in Windows operating
systems.
-> Well-known SIDs are a group of SIDs that
identify generic users or generic groups. Their
values remain constant across all operating
systems.
-> This information is useful for troubleshooting
issues that involve security.
 Well Known Security Identifiers
• SID: S-1-5-18
Name: Local System
Description: A service account that is used by the operating system.
• SID: S-1-5-19
Name: NT Authority
Description: Local Service
• SID: S-1-5-20
Name: NT Authority
Description: Network Service
• SID: S-1-5-32-544
Name: Administrators
Description: A built-in group. After the initial installation of the operating
system, the only member of the group is the Administrator account. When a
computer joins a domain, the Domain Admins group is added to the
Administrators group. When a server becomes a domain controller, the
Enterprise Admins group also is added to the Administrators group.
•SID: S-1-5-32-545
Name: Users
Description: A built-in group. After the initial installation of the
operating system, the only member is the Authenticated Users group.
When a computer joins a domain, the Domain Users group is added
to the Users group on the computer.
•SID: S-1-5-32-546
Name: Guests
Description: A built-in group. By default, the only member is the
Guest account. The Guests group allows occasional or one-time
users to log on with limited privileges to a computer's built-in Guest
account.
 Step 3
Network Artifacts
• When available, network artifacts can provide interesting
clues to the legitimacy of a process.
• When reviewing network data, we should focus on:
1. Suspicious Ports
2. Suspicious connection
3. Known bad IP address
4. Suspicious network behaviour from processes
5. Interesting creation time of network sockets
• Volatility network plugins are dependent on the OS
- netscan for win7 and connscan/ sockscan for winXP
 Suspicious Ports:
•Communication via abnormal ports?
•Indications of listening ports/backdoors?
Suspicious Connections:
•External connections
•Connection to known bad IPs
•TCP/UDP connection
•Creation times
Suspicious Processes:
•Why does this process have network capability/open
sockets?
Example: Port 80, 443 or 8080 that is not a browser.
 Network Artifacts Plugins
• connections - [XP] List of open TCP connections
# vol.py connections
• connscan - [XP] ID TCP connections, including closed
# vol.py connscan
• sockets - [XP] Print listening sockets (any protocol)
# vol.py sockets
• sockscan - [XP] ID sockets, including closed/unlinked
# vol.py sockscan
• netscan - [Win7] Scan for connections and sockets
# vol.py netscan
 Network Artifacts: netscan
#vol.py netscan
• Identify network sockets and TCP structures in
memory.
• Both active(established) and terminated(closed)TCP
connection may be returned.
• Pay close attention to process attached to the
connection. Does a socket or network connection for
that process make sense?
• Sockets have associated creation times and TCP
connections do not.
• Sockets record information about any protocol(not just
TCP)
Code Injection, Rootkits and
Extraction:
 Step 4
Look for Code Injection
Why Code Injection?
• Camouflage
• Access to memory and permissions of target
• Process Migration
• Evade antivirus and white listing
• Assists with complex attacks(i.e. Rootkits)
Code Injection
 Detecting Injection
• DLL injection is very common with modern malware
- VirtualAllocEx() and CreaterRemoteThread()
- SetWindowsHookEx()
- Reflective injection loads code without registering with
host process
- Use of PowerShell-based injection is growing in popularity
• Process hollowing is another injection technique
- Malware starts a new instance of legitimate process
- Original process code de-allocate and replaced
- Retains DLLs , handles, data etc. From original process
 Code Injection is relatively easy to
detect
• Review memory sections marked as
Page_Execute_ReadWrite and having no
memory-mapped file present
- Scan for DLLs(PE files) and shellcode
• Process image not backed with file on disk =
process hollowing
 DLL Injection
• DLL injection is the process of inserting code into a running process. The
code we usually insert is in the form of a dynamic link library (DLL), since
DLLs are meant to be loaded as needed at run time. However this doesn't
mean we cannot inject assembly in any other form (executables,
handwritten, etc..). It's important to note that you'll need to have an
appropriate level of privileges on the system to start playing with other
program's memory.
Overview:
• The Windows API actually offers a number of functions that allow us to
attach and manipulate into other programs for debugging purposes. We'll
leverage these methods to perform our DLL Injection. I've broken down
DLL injection into four steps:
Attach to the process
• Allocate Memory within the process
• Copy the DLL or the DLL Path into the processes memory and determine
appropriate memory addresses
• Instruct the process to Execute your DLL
Execution Starting Point:
We have a couple of options
(e.g. CreateRemoteThread(),NtCreateThreadEx(), etc...) when
instructing the target process to launch our DLL. Unfortunately we
can't just provide the name of our DLL to these functions, instead we
have to provide a memory address to start execution at. We perform
the Allocate and Copy steps to obtain space within the target process'
memory and prepare it as an execution starting point.
There are two popular starting points: LoadLibraryA() and jumping
to DllMain.
1. LoadLibraryA():
LoadLibraryA() is a kernel32.dll function used to load DLLs,
executables, and other supporting libraries at run time. It takes a
filename as its only parameter and magically makes everything work.
This means that we just need to allocate some memory for the path to
our DLL and set our execution starting point to the address
of LoadLibraryA(), providing the memory address where the path lies
as a parameter.
The major downside to LoadLibraryA() is that it registers the loaded DLL with
the program and thus can be easily detected. Another slightly annoying caveat is
that if a DLL has already been loaded once with LoadLibraryA(), it will not
execute it. You can work around this issue but it's more code.
Jumping to DLLMain(or another entry point):
An alternative method to LoadLibraryA() is load the entire DLL into memory,
then determine the offset to the DLL's entry point. Using this method you can
avoid registering the DLL with the program (stealthy) and repeatedly inject into
a process.
Step 1: Attaching to the Process
First we'll need a handle to the process so that we can interact with it. This is
done with the OpenProcess() function.
Step 2: Allocating Memory
Before we can inject anything into another process, we'll need a place to put it.
We'll use the VirtualAllocEx() function to do so.
VirtualAllocEx() takes amount of memory to allocate as one of its parameters. If
we use LoadLibraryA(), we'll allocate space for the full path of the DLL and if
we jump to the DllMain, we'll allocate space for the DLL's full contents.
DLL Path
Allocating space for just the DLL path slightly reduces the amount of
code you'll need to write but not by much. It also requires you to use
the LoadLibraryA() method which has some downsides (described
above). That being said, it is a very popular method.
Full DLL
Allocating space for the full DLL requires a little more code however it's
also much more reliable and doesn't need to use LoadLibraryA().
First, open a handle to the DLL with CreateFileA() then calculate its size
with GetFileSize() and pass it to VirtualAllocEx().
Step 3:Copying the DLL/Determine Addresses
We can now copy the DLL (path or contents) to the target process space.
Now that we have space allocated in our target process, we can copy our
DLL Path or the Full DLL (depending on the method you choose) into
that process. We'll use WriteProcessMemory() to do so.
Step 4: Executing the DLL
At this point we have our DLL in memory and we know the
memory address we'd like to start execution at. All that's really left
is to tell our process to execute it.
 Volatility Code Injection Plugins
• ldrmodules: Detected unlinked DLLs and non-
memory-mapped files.
• malfind: Find hidden and injected code and
dump affected memory sections.
• hollowfind: Identify evidence of known
process hollowing techniques.
• threadmap: Analyze threads to identify
process hollowing counter-measures.
 Code Injection: ldrmodules
• There are many ways to hide a DLL. One of the ways
involves unlinking the DLL from one (or all) of the linked
lists in the PEB. However, when this is done, there is still
information contained within the VAD (Virtual Address
Descriptor) which identifies the base address of the DLL
and its full path on disk. To cross-reference this information
(known as memory mapped files) with the 3 PEB lists, use
the ldrmodules command.
• For each memory mapped PE file, the ldrmodules
command prints True or False if the PE exists in the PEB
lists.
• # vol.py –f TDSS.img ldrmodules | grep false
 Relative Code Injection
• Advanced technology to perform arbitrary code
execution without explicitly calling Load Library.
- Uses a custom reflective loader instead of
Windows Loader
• Code is not registered in any way with the host
system, making it very difficult to detect. Code
can be injected directly from memory.
• Used by many advanced adversary toolkits.
- Metasploit, PowerShell, Empire, Double Pulsar
• Memory analysis is well suited for detection.
 Reflective DLL Injection
• Reflective DLL injection is a library injection technique in
which the concept of reflective programming is employed
to perform the loading of a library from memory into a host
process. As such the library is responsible for loading itself
by implementing a minimal Portable Executable (PE) file
loader.
• It can then govern, with minimal interaction with the host
system and process, how it will load and interact with the
host.
• The main advantage of the library loading itself is that it is
not registered in any way with the host system and as a
result is largely undetectable at both a system and process
level.
Detecting hidden and Reflective Code
Injection

Unusual
Unmapped
Permission
• Memory • Memory • Memory
section marked section not section
as
Page_Execute_ backed with a contains code
ReadWrite file on disk. (PE file or
shellcode)
 Detecting Code Injection: malfind
• The malfind command helps find hidden or injected
code/DLLs in user mode memory, based on characteristics
such as VAD tag and page permissions.
• Note: malfind does not detect DLLs injected into a process
using CreateRemoteThread->LoadLibrary. DLLs injected
with this technique are not hidden and thus you can view
them with dlllist. The purpose of malfind is to locate DLLs
that standard methods/tools do not see. For more
information see Issue #178.
• If you want to save extracted copies of the memory
segments identified by malfind, just supply an output
directory with -D or --dump-dir=DIR. In this case, an
unpacked copy of the Zeus binary that was injected into
explorer.exe would be written to disk.
 Step 5
Hooking and Rootkit Detection
Rootkit:
• Rootkits is that they are trying to hide the
attacker’s presence.
• Rootkits are programs that hide the existence of
malware by intercepting (i.e., Hooking) and
modifying operating system API calls that supply
system information.
• Adversaries may use rootkits to hide the presence
of programs, files, network connections, services,
drivers, and other system components. Rootkits
have been seen for Windows, Linux, and Mac OS
X systems
 Rootkit Hooking
• Adversaries may use hooking to load and execute
malicious code within the context of another process,
masking the execution while also allowing access to
the process's memory and possibly elevated privileges.
• Malicious hooking mechanisms may also capture API
calls that include parameters that reveal user
authentication credentials for Credential Access. [6]
• Hooking is commonly utilized by Rootkits to conceal
files, processes, Registry keys, and other objects in
order to hide malware and associated behaviors.
System Service Descriptor Table(SSDT)
• The System Service Descriptor Table also
called System Service Dispatch Table (SSDT).
• It is a table containing pointers to service functions
(APIs) in ntoskrnl.exe (NtOpenProcess, NtOpenThread,
… ).
• Make of a hook in this table consist to replace the
original pointer value of an entry by the address of a
function with the same prototype in any kernel mode
loaded module.
• SSDT hooks are used by malware to self-protect and
hide their ass, and by antivirus vendors (on old
systems) to filter system access (process starts, registry
write).
 Interrupt Descriptor Table(IDT)
• The Interrupt Descriptor Table (IDT) stores the
addresses of functions known as ISR (Interrupt
Service Routines or Interrupt handlers). These
functions handle interrupts and processor
exceptions. Like hooking an SSDT, an attacker
may hook the entries in the IDT to redirect
control to the malicious code.
Volatility Rootkit Detection Plugins
• psxview - Find hidden processes using cross-view
# vol.py psxview
• modscan - Scan memory for loaded, unloaded,
and unlinked drivers
# vol.py modscan
• apihooks - Find API/DLL function hooks
-p Operate only on specific PIDs
-Q Only scan critical processes and DLLS
# vol.py apihooks
• ssdt - Hooks in System Service Descriptor
Table
# vol.py ssdt | egrep –v ‘(ntoskrnl|win32k)’
•driverirp - Identify I/O Request Packet (IRP)
hooks
-r Analyze drivers matching REGEX name
pattern
# vol.py driverirp –r tcpip
•idt - Display Interrupt Descriptor Table
# vol.py idt
 Rootkit Detection: ssdt
• Display hooked function within the System Service
Descriptor Table(Windows Kernal Hooking).
• The SSDT holds pointer to various kernel functions that
pointer to various kernel functions that power windows.
• The advantage of hooking these functions is that they are
instantly global: The hooks will be valid for any process on
the system.
• Disadvantage is that it requires changes to the kernel,
which can risk the stability of the running system.
• We can identify SSDT hooks using volatility plugins ssdt.
• This plugin provides table entry, function, function offset,
function owner.
Rootkit Detection: Direct Kernel Object
Manipulation(DKOM)
• Advanced process hiding techniques, unlink an
EPROCESS from doubly linked list.
• DKOM allows malware to make changes to kernel
objects directly within memory.
• The changes do not get written to disk giving a
very small footprint and making it very difficult
for protection mechanism like antivirus to detect.
• It can be used to change nearly any kernel object,
but popular attacks include unlinking objects
from their standard kernel lists.
 Rootkit Detection: psxview
• Cross-view analysis is simple but powerful
technique for identifying rootkit.
• We start a cross-view analysis by querying the
system at a high level, say using the Windows API
on a live system or reading the linked lists with a
memory image.
• Then, we compare those results with low- level
data gathering such as manually reading the
Master File Table from a raw disk or scanning all
of memory for errant process structures.
 psxview plugins
• pslist: Read EPROCESS doubly linked list
• psscan: Scan for EPROCESS structures throughout
memory
• thrdproc: Review all threads in memory image and
collect processes using thread parent process identifier
• pspcid: It get another kernel object that keeps track of
process and thread parent process
• csrss: The csrss.exe process keep a handle to each
process started after it.
• session: List of processes belonging to each logon
session
 Step 6
Extracting Process, Drivers and Objects
• Review strings, antivirus scan and reverse engineering.
Extracting Process Object Plugins:
• dlldump - Extract DLLs from specific processes
-p Dump DLLs only for specific PIDs
-b Dump DLLs from process at base offset
-r Dump DLLs matching REGEX name
--dump-dir Directory to save extracted files
# vol.py dlldump --dump-dir=./output –r metsrv
• moddump - Extract kernel drivers
-b Dump driver using base address (from modscan)
-r Dump drivers matching REGEX name
--dump-dir Directory to save extracted files
# vol.py moddump --dump-dir=./output –r gaopdx
•procdump - Dump process to executable sample
-p Dump only specific PIDs
-o Specify process by physical memory offset
-n Use REGEX to specify process
--dump-dir Directory to save extracted files
# vol.py procdump --dump-dir=./output –p 868
•memdump - Dump every memory section into a single file
-p Dump memory sections from these PIDs
-n Use REGEX to specify process
--dump-dir Directory to save extracted files
# vol.py memdump –dump-dir=./output –p 868
•dumpfiles - Dump File_Objects from file cache
-Q Extract using physical offset
-r Extract using REGEX (-i for case insensitive)
--dump-dir Directory to save extracted files
# vol.py dumpfiles –dump-dir=./output –r \\.exe