Developing a Baseline Approach to Identify Indicators of Compromise (IOCs) w/ Volatility 2.0

I recently attended Richard Bejtlich’s TCP/IP Weapons School 3.0 where students are provided guidance on how to apply an investigative methodology to identify network intrusions. Students are provided several evidence files including full packet capture, session data, alert data, and Windows event logs to facilitate intrusion identification. The course is about establishing an investigative method and then applying the approach. It’s about performing a security investigation, not just performing alert management. The instructor steps through his approach for examining network-based evidence (NBE). Without having any indicators, how can I step through the evidence and identify intrusion? I can’t speak highly enough about the instructor, course, and content.This inspired me to revisit my approach when analyzing host-based evidence, specifically physical memory (RAM). Without having any indicators, what basic steps can I take to analyze memory and identify the presence of indicators?

Hogfly's exemplar memory images (http://forensicir.blogspot.com/2009/03/memory-snapshot-project-part-ii.html) are a great way to establish a memory forensic response capability. The memory images are VMware snapshots (.vmem) of infected Windows based systems. I used Volatility 2.0 (https://www.volatilesystems.com/default/volatility) to analyze exemplar4.vmem (MD5=359df4feb25af47cfef228f393d07c10). Volatility is an outstanding open source digital forensic tool that can analyze memory acquired from Windows based systems including:

• 32bit Windows XP Service Pack 2 and 3
• 32bit Windows 2003 Server Service Pack 0, 1, 2
• 32bit Windows Vista Service Pack 0, 1, 2
• 32bit Windows 2008 Server Service Pack 1, 2 (there is no SP0)
• 32bit Windows 7 Service Pack 0, 1
• Ref: https://www.volatilesystems.com/default/volatility#images

Again, the goal of this article is to provide a basic approach to analyzing memory acquired from a Windows device. The memory image being analyzed is pretty vanilla, which is a good thing. We want to start simple, apply a baseline approach, and then continue to extend our forensic capabilities by re-visiting and applying different methods to our approach over time. Everyone’s process is different. Learn what works and what doesn’t. Remember that different scenarios will call for different approaches. Provided is my basic approach.

Summary of Approach

• Validate MD5 of acquired evidence
• Review external connections out
• Identify connections to potentially hostile IP addresses
• Identify odd ports/protocols
• Review running processes
• Identify processes requiring further review
• Full path to executable on the disk
• Non-standard path
• Summary of libraries the binary has loaded
• Associated threads
• Threads are responsible for doing the work
• Review Handles
• Review objects process of interest is accessing
• Threads, Registry Keys, Mutex, Files, etc.
• Export module of interest and review strings
• Provide summary of deviations from non-standard and indicators
• Determine scope based on indicators
• Query enterprise for the presence of the indicators
• Netflow, Network Logs

Triage Goals

• Identify Indicators of Compromise (IOCs)
• Identify scope
• Sweep the enterprise for the presence of the IOCs
• Netflow, event log analysis
• Identify additional IOCs
• Contain and remove the threat
• Query the enterprise for the presence of IOCs identified Pre & Post containment

Triage Tools
Volatility 2.0
Dependencies: Python
Command line utility

Evidence File
MD5 (exemplar4.vmem) = 359df4feb25af47cfef228f393d07c10
File available here: Hogfly Sky Drive

Memory Analysis

Validate MD5 hash of virtual memory image
MD5 (exemplar4.vmem) = 359df4feb25af47cfef228f393d07c10
Command: md5 exemplar4.vmem

Output: MD5 (exemplar4.vmem) = 359df4feb25af47cfef228f393d07c10
Match! Proceed with triage.

Profile evidence file 
Command: python vol.py imageinfo –f exemplar4.vmem
"imageinfo” command allows you to identify information for the image. 
Virtual memory image of Windows XP device
Image data and time: 2009-01-08 02:02:18

Examine open network connections 
Command Line: python vol.py connscan -f exemplar4.vmem

• Any processes connecting out to a potentially hostile IP address? 
• What process (PID) is making the connection? 
• Identify Port numbers 
• Any ports requiring further review? Provide summary of deviations

Summary of external connections out:

• PID 1936 is connecting out to 66.249.128[d]230
• Identify web reputation of 66.249.128[d]230
• PID 1936 is connecting outbound to port 9989/TCP
• Port 9989/TCP is associated with the Ini-Killer remote access Trojan
• PID 1936 requires further review
• All other connections appear to be normal HTTP connections

List running processes and applications
Command Line: python vol.py pslist -f exemplar4.vmem
The “pslist” command will print all running processes by following the EPROCESS lists. Processes are containers for executing a program.

• Unique identifier called a Process ID (PID)
• Private virtual memory space
• At least one thread of execution
• System processes have defined parents
• cmd.exe should not be the parent of lsass.exe

Process diagram 
Creating a process diagram is an effective way to get a visual representation of what is being loaded into memory and by what. Some system processes should never start programs. If lsass.exe creates cmd.exe this is bad! If ‘netstat’, ‘hostname’, ‘systeminfo’ are being run from cmd.exe this could represent attacker commands being run on the target. It is important to provide context to what is running in memory.


Diagram:

Offset(V)	Name	PID	PPID	Thds	Hnds	Time	Analyst's Notes
0x817cc7f8	System	4	0	53	244	1/1/70 0:00
0x8140f600	smss.exe	516	4	3	21	1/8/09 1:46	Started by System/Normal
0x81712170	csrss.exe	588	516	9	303	1/8/09 1:46	Started by smss/Normal
0x8172d2d8	winlogon.exe	612	516	20	599	1/8/09 1:46	Started by smss/Normal
0x81459b38	services.exe	656	612	15	249	1/8/09 1:46	Started by Winlogon/Normal
0x812ee9a0	lsass.exe	668	612	20	321	1/8/09 1:46	Started by Winlogon/Normal
0x8143c388	svchost.exe	888	656	9	222	1/8/09 1:47	Started as a Service - PPID 656
0x814068b0	svchost.exe	984	656	69	1491	1/8/09 1:47	Started as a Service - PPID 656
0x815db628	svchost.exe	1020	656	18	197	1/8/09 1:47	Started as a Service - PPID 656
0x812aa3c0	svchost.exe	1232	656	5	79	1/8/09 1:47	Started as a Service - PPID 656
0x8170cd50	svchost.exe	1304	656	13	202	1/8/09 1:47	Started as a Service - PPID 656
0x812e3020	spoolsv.exe	1516	656	11	109	1/8/09 1:47	Started as a Service - PPID 656
0x8163d020	alg.exe	408	656	5	98	1/8/09 1:48	Started as a Service - PPID 656
0x81290920	explorer.exe	1928	2000	12	311	1/8/09 1:49
0x814bc988	wscntfy.exe	1048	984	1	27	1/8/09 1:49
0x81504c30	svhost.exe	1936	1888	7	83	1/8/09 2:01	Non-standard name /Last Loaded

Summary:

• smss.exe (PID 516) is loaded during Windows startup
• Starts the winlogon.exe / PID 612 (Windows logon manager)
• Starts csrss.exe / PID PID 588 (provides user mode of W32 subsystem
• Normal behavior
• winlogon.exe (PID 612) starts lsass.exe (PID 668)
• Normal behavior
• lsass.exe is one of the first processes to get loaded when Windows boots
• One of the first processes loaded (2009-01-08 01:46:59)
• Does not start any other processes

If a process is started as a Windows service it will have a parent process id (PPID) of services.exe. Services are user mode programs that provide functionality independent of the current user.

The following processes were started as a service:

• svchost.exe
• Normal behavior to have multiple running instances of svchost.exe
• Normal behavior to start and stop in different order (note load time)
• Some system processes should never start programs. lsass.exe should not start cmd.exe

Process diagram

• Process ID 1936
• Unique Identifier
• Opened by Process ID 1888
• PID 1888 is not listed and appears to have exited

Other Info:

• 7 threads
• A thread is a container for execution. A thread uses a unique identifier called a thread ID (client id or TID).
• 83 handles
• Handles indicate access to an object.

Preliminary findings

• svhost.exe name is non-standard
• svhost.exe could be mistaken as svchost.exe
• not loaded as a service / PPID != 656
• svhost.exe was loaded last (2009-01-08 02:01:52)
• PPID for svhost.exe (PID 1888) has exited

Examine DLLs for process of interest
Command Line: python vol.py dlllist -p 1936 -f exemplar4.vmem
List DLLs for svhost.exe. The dlllist command identifies the location of the binary on the physical disk.

Output of Interest

Preliminary findings

• svhost.exe running from C:\Windows\msagent\
• svhost.exe loaded wsock32.dll 
• wsock32.dll is used to handle internet connections

Review Strings of the Suspicious Process
Command: python vol.py procexedump -p 1936 -f exemplar4.vmem --dump-dir=output dir
Warning: The above command will extract the suspicious/malicious process from memory.

• svhost.exe has been identified as suspicious/malicious
  Review the strings of this process to get an indication of what it’s doing
• URL/IP references
• Commands being sent & received
• Functions called
• Read Files, Delete Files

The Strings command was used to dump ASCII and UNICODE strings for svhost.exe
Strings Requiring Further Review

Possible IRC communication
WoW? is that really you... what the hell where you drinking :D
 
Shell Command to Open w6.exe
shell\open\command=
[autorun]
open=
w6.exe

DLL References/API Calls
kernel32.dll
GetProcAddress
GetModuleHandleA

Strings review of svhost.exe identified entries requiring further review

• BOT commands
• IRC Traffic
• Shell Command to open w6.exe (Could be PPID of svhost.exe)
• svhost.exe requires further review
• w6.exe requires further review

Identify Parent/Process Relationship

Command Line: python vol.py userassist -f exemplar4.vmem
Strings review of svhost.exe identified file requiring further review, w6.exe
UserAssist key will identify content recently executed by the user account of interest.Note your process load time 2009-01-08 02:01:52 and review against entries identified within UserAssist key.

Entry requiring further review: 

Summary of Findings
User account of interest: “foo”
w6.exe is executed on the device from C:\Documents and Settings\foo\Desktop
w6.exe is executed “run” at 2009-01-08 02:01:51
Based on timeline, w6.exe appears to load svhost.exe

Identify Mutexes
Command: python vol.py mutantscan -f exemplar4.vmem
A mutex is used to ensure that only a single instance of process is running on a system. Worms or malware will use a mutex in order to determine if the system is already infected. 

Preliminary findings: A mutex object with the string ‘uNk’ is identified at 0x01abec30 with a thread address of 0x00000000. The PID associated with the mutex is 1936, the svhost.exe process.

Preliminary Summary of Findings

• User account of interest: “foo”
• Suspicious/Malicious PID: 1936
• Process Name: svhost.exe
• Using similar Microsoft process name
• PPID 1888 has exited
• svhost.exe was loaded last (2009-01-08 02:01:52)
• Path to executable: C:\Windows\msagent\
• DLLs loaded into process address space related to networked functionality
• wsock32.dll is used to handle internet connections
• svhost.exe is connecting out to 66.249.128[d]230 over 9989/TCP
• A mutex object with the string ‘uNk’ is identified at 0x01abec30 with a thread address of 0x00000000.
• The PID associated with the mutex is 1936, the svhost.exe process.
• Strings review of svhost.exe identified entries requiring further review
• BOT commands
• IRC Traffic
• Shell Command to open w6.exe (Could be PPID of svhost.exe)

Process relational context:
w6.exe is executed on the device from C:\Documents and Settings\foo\Desktop
w6.exe is executed “run” at 2009-01-08 02:01:51
Based on timeline, w6.exe appears to load svhost.exe


Indicators of Compromise

File System

• C:\Documents and Settings\foo\Desktop\w6.exe
• Creates svhost.exe on the volume
• C:\Windows\msagent\svhost.exe

Registry

• UserAssist Entry C:\Documents and Settings\foo\Desktop\w6.exe

Memory

• Process name: svhost.exe
• Path: %Windir%\msagent\svhost.exe
• Mutex Object Created: ‘uNk’

Network Traffic

• svhost.exe opens outbound TCP channel to 66.249.128[d]230
• svhost.exe connects out to destination port 9989/TCP
• Port 9989/TCP is associated with the Ini-Killer remote access Trojan

Enterprise Detection

• Review firewall logs for built/established TCP based connections to 66.249.128[d]230
• Correlate discovered IP addresses to other compromised hosts
• Enterprise sweep for discovered files.
• C:\Windows\msagent\svhost.exe
• C:\Documents and Settings\%User%\Desktop\w6.exe
• Triage identified systems
• Enterprise sweep for registry artifacts
• UserAssist entry for w6.exe
• Triage identified systems

After Action

• Acquire Registry Hive Files and parse with Reg Ripper to identify persistence mechanism.
• ‘Run’ Key, Active Setup, etc.
• Data is then feed back into IOC collection and enterprise sweep