Snort Sigs Made Easy w/ Security Onion

Following the April 2011 Epsilon hack, one of my legacy web-mail accounts started receiving a high volume of Spam/Phishing emails. My email address, along with millions of others, was exposed and added to a long distribution list of potential victims of commodity-based malware.
 

You know the flavor, email reports that you have an unpaid traffic ticket or package pending delivery and in order to take action you are to download the attached zip file. The zip file most often contains a compressed executable that presents itself as a PDF file when extracted. The malware is usually a Trojan dropper that when run, will download Fake Anti-virus software, Zeus, Spyeye, or another commodity based sample. That, or I have a lot of unpaid "uniform" traffic tickets in NY and a TON of FedEx, DHL, and USPS packages pending delivery.

These emails represent possible intelligence on the commodity based actors. Most organizations allow access to web-mail and regardless of the threat type, non-targeted/commodity-based, detecting the presence of the related indicators is necessary. 99% of the attachments aren't detected by the AV engine provided by the web-mail provider which allows me to download and perform quick dynamic analysis of the samples. From this I'm able to identify host-level and network-based indicators of commodity-based samples circulating in the wild. I'm able to provide this quicker than the vendors as I'm being provided the samples directly!

What I was missing was the ability to quickly create, deploy, and validate network based signatures to detect the presence of the indicators in a simple virtual lab environment. Enter Security Onion. Thanks Doug Burks. Discussing all the features that Security Onion distro provides is outside the scope of this article, but I highly encourage you to visit http://securityonion.blogspot.com/ for additional info.
 

Security Onion provides a working Snort, Sguil, and Snorby configuration (and many other NSM collection/analysis tools) for alert data and analysis. What's even better is that more and more people are starting to adopt and document some of the Security Onion capabilities. Following this Wiki article, https://code.google.com/p/security-onion/wiki/AddingLocalRules, I was able to quickly write, test, and deploy SNORT sigs to detect the presence of network based indicators pulled from a commodity based sample.

Prelim summary of sample acquired from web-mail account: 

• Trojan dropper delivered via web-mail
• Spam/Phishing email reporting recent "Uniform Traffic Ticket"
• Email sender is spoofed
• Email contains ZIP attachment containing nested/compressed exe
• If exe is extracted and 'run', files are created on the volume within \LOCALS~1\Temp  
• wuauclt.exe process is started and opens external connection out to downtraff[d]ru to download additional payload
• Malware achieves persistence via HKLM run key

Malware communication out to the internet post user click through:

• POST /and/image.php to downtraff[d]ru
• GET /sol.exe to downtraff[d]ru

I then created and added the following Snort rules to the local.rules file and ran the pulled pork update:

• alert tcp any any -> any 80 (msg: "Uniform Traffic Ticket C2"; reference: url, http://jphsecurity.blogspot.com; content: "and/image.php"; flow:to_server nocase; sid:1000001; rev:1)
• alert tcp any any -> any 80 (msg: "Uniform Traffic Ticket Binary"; reference: url, http://jphsecurity.blogspot.com; content: "/sol.exe"; flow:to_server nocase; sid:1000002; rev:1)

(Helpful tip, if your SNORT sig syntax is wrong, the snort process won't restart. Simply cat the snortu.log stored within /var/log/nsm/~/, fix the syntax, and then run the pulled pork update again.)

I then used scapy to generate packets that met the conditions of the newly added local rules and monitored Snorby and Sguil for alert generation.


Snorby: 
I really like the Snorby web interface. It's intuitive and allows for quick alert review and categorization. 

Alert review w/ Snorby

Event Details for Uniform Traffic Ticket Binary Alert. Request for /sol.exe over 80/TCP

Sguil: 

Real Time Events view w/Sguil. Uniform Traffic Ticket Binary Alert. 

Uniform Traffic Ticket C2 Alert

By monitoring the exposed legacy web-mail account, performing analysis on Spam/Phishing messages, and then using Security Onion to create and test Snort signatures to identify the presence of network-based indicators, I am able to provide tested monitoring and network-based counter-measures for the latests TTPs these campaigns and commodity-based actors are using.

The emails provide possible counter-intel, dynamic analysis identifies indicators, and Security Onion provides a simple virtual environment to create content (custom Snort sigs) to detect the presence of the network-based indicators. 

There are so many other non-production scenarios where this TTP can be used:

• Training junior level responders
• Create and test Snort signature for samples being sent to client population
• Classroom environments 
• Testing Snort sigs created from open/closed source reporting

Happy hunting, or in this case, matching. 

Dynamic Malware Analysis w/ Procmon

In a previous article, (http://jphsecurity.blogspot.com/2012/01/developing-baseline-approach-to.html), we reviewed a general approach to analyzing a virtual memory image of a Windows based device using the open source tool Volatility 2.0. Preliminary analysis identified a malicious process named svhost.exe, assigned PID 1936, running from C:\Windows\msagent. The parent process (PPID 1888) had exited.

Note PID 1936, loaded last, started ~ 15 min after system boot:

To provide additional process context I performed the following:

The “pslist” and “pscan” commands were run against the virtual memory image to identify exited processes. PID 1888 was not immediately identified. The “userassist” command was run to print Registry UserAssist entries. A UserAssist entry identified a suspicious file named w6.exe had been executed from %UserProfile%\Desktop one (1) second before the svhost.exe process was created.

Process relational structure:Exited process w6.exe (PID 1888) creates svhost.exe on the volume within C:\Windows\msagent and then runs the file.

Triage identified device compromise and indicators to identify scope; however I wanted to validate my initial assessment that the file w6.exe was responsible for file and process creation of svhost.exe running from C:\Windows\msagent. I obtained a sample of the malware (MD5= 654eef6ff6dbe666c1d9fd1f6049d525) and executed the file w6.exe on a Windows XP VM in an isolated network environment and monitored process/thread activity using Procmon (http://technet.microsoft.com/en-us/sysinternals/bb896645

Protocol for malware execution

• Transfer malware to virtual environment
• Windows XP SP3 VM
• Isolated network environment
• Launch Procmon
• No filters immediately applied 
• Launch AutoRuns
• Save output
• Execute malware sample
• Let malware sample “breathe” for a period of five (5) minutes
• Take a snap shot of the VM pre and post infection
• VMWare saves the snapshot as a .vmem file
• Virtual memory image (.vmem) can be analyzed using Volatility
• Save Procmon output as .csv
• Review using MS Excel Apply filters throughout process
  

Goals of analysis
1. Verify that w6.exe creates C:\Windows\msagent\svhost.exe on the volume
2. Verify that malware sample is responsible for svhost.exe process creation
3. Identify any changes made to the device Registry and File System

Procmon Filter Process
Review overall process/thread activity
Filter on Process Create
Filter on Thread Create
Filter on Load Image
Filter on Reg Create key
Filter on Reg Set value
Filter on Thread exit
Filter on Process exit
 

Process/Thread Activity following execution of w6.exe

Reviewing the overall Process/Thread activity following execution of malware, I identified the creation of our malicious process:

File Name: w6.exe
MD5: 654eef6ff6dbe666c1d9fd1f6049d525
PID: 808
PPID: 324 (Explorer.exe)
PID 808 was executed by Windows user account from Explorer.exe.
Analyst’s Notes: Most user processes are started by Explorer.exe, it’s suspicious when they aren’t.

Within Procmon I then created a filter for Process Name = w6.exe. I wanted to identify all process and thread activity for (PID 808). 

Thread Creation
A process is a container, threads do the actual work. 

Malware loaded into memory 
W6.exe is loaded into memory from %UserProfile%\Desktop - 

Windows Prefetch file created 
This an artifact left on the file system by our malware. Prefetch files contain information regarding path to the executable. Ref: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/appendix/hh/appendix/enhancements5_0eecebea-e58b-4c95-8520-9b1dc2bc6196.xml.asp

Loaded DLLs
Wsock32.dll loaded into process address space for PID 808 (w6.exe) -
Windows Sockets API used to handle network connections.
DLLs loaded can be identified with LoadImage (Filter)
Review all other DLLs loaded

Svhost.exe created on the volume
The CreateFile function is used by PID 808 (w6.exe) to create svhost.exe on the volume. Svhost.exe is written to C:\Windows\msagent.
CreateFile Function (MSDN) - Creates or opens a file or I/O device. The most commonly used I/O devices are as follows: file, file stream, directory, physical disk, volume, console buffer, tape drive, communications resource, mailslot, and pipe. The function returns a handle that can be used to access the file or device for various types of I/O depending on the file or device and the flags and attributes specified.

Windows Registry Modified
Persistence is established via Windows Registry abuse -

• A 'Run' key is created for C:\Windows\msagent\svhost.exe
• svhost.exe will 'Run' from C:\Windows\msagent upon Windows Login

Svhost.exe Process Creation -
PID 808 (w6.exe) creates process 256 by running "C:\Windows\msagent\svhost.exe" from a command line
This is a user process not started by Explorer.exe. This process was started from a command line.
Most user processes are started by Explorer.exe
It’s suspicious when they are not
Process started from command line parameter? In this case, yes. 

PID 808 and TIDs 1404 & 584 exit 

Summary of Process/Thread Activity for PID 808

• PID 808 (w6.exe) creates two (2) threads 584 & 1404
• Windows Prefetch file created by PID 808 within %SYSTEMROOT%\Prefetch
• C:\WINDOWS\Prefetch\W6.EXE-1DA168E3.pf
• File System artifact
• DLLs loaded into process address space for w6.exe identified by LoadImage
• Wsock32.dll loaded into process address space for PID 808
• Windows Sockets API used to handle network connections
• PID 808 creates svhost.exe on the volume.
• Svhost.exe is written to C:\Windows\msagent
• PID 808 sets Registry ‘Run’ Key for svhost.exe within Software Hive File (HKLM)
• PID 808 (w6.exe) creates PID 256 by running "C:\Windows\msagent\svhost.exe" from a command line
• PID 808 and TIDs 584 & 1404 exit five (5) seconds after file execution

What about Process/Thread Activity for PID 256 (svhost.exe)?
Following our baseline process, we are able to quickly obtain a basic understanding of Process/Thread activity for PID 256 (svhost.exe).

Summary of Process/Thread Activity for PID 256 

• PID 256 (svhost.exe) is created by PID 808 (w6.exe)
• PID 256 (svhost.exe) creates four (4) threads: TIDs 1296, 196, 1096, 1312
• Windows Prefetch file created by PID 256 within %SYSTEMROOM%\Prefetch
• C:\WINDOWS\Prefetch\SVHOST.EXE-01E779D2.pf
• File System artifact
• DLLs loaded into process address space for w6.exe identified by LoadImage
• Wsock32.dll loaded into process address space for PID 808
• Windows Sockets API used to handle network connections
• PID 256 modified Windows Registry settings within the Software Hive file and NTUSER.dat of the logged on user
• PID 256 (svhost.exe) and TIDs 1296, 196, 1096, 1312 did not exit after five (5) minute time period
• Snap shot of VM taken post infection

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