Sunday, February 5, 2012

Technical mentoring and training is equal parts essential and challenging. Turning highly technical concepts into simple statements that can be interpreted and adopted takes effort and focus . A recent mentoring session resulted in an "ah-ha" moment that inspired me to go back, re-visit my approach by extending the context, and then share it with all of you. By dedicating additional focus to the attack baseline, the output of sophisticated TTPs applied in support of cyber network defense (CND) becomes more valuable.

Part of the recent session included a basic introduction to offensive computing with the Metasploit framework. Defenders must understand attack phases and patterns to perform effectively and mature technically. I set up a vulnerable web server, provided an attack node, and provided a predefined mission for the peer assigned the role of attacker:

Identify running services

Exploit vulnerable service(s)

Deliver a payload (Meterpreter)

Interact with the device (victim)

Then we stepped through a client-side attack analyzing a weaponized PDF file I pulled from a popular malware dump. This attack technique comprised of exploiting both a person and an application instead of a just a service:

Identify victim

Exploit user and vulnerable application

Deliver a payload (Trojan backdoor program)

Interact with the device

I think the current approach adds value to an analyst. We review a sample of current attack patterns and the basic principles of exploiting vulnerable services and applications to deliver a payload. The payload provides the communication channel to interact with the victim.

Taking a step back and reviewing my approach, I realized that I wasn't providing enough context. While this was an effective first step, I needed to extend my approach by adding real world context and applicability to the current environment to make this more cohesive.

Disclaimer, statements are my own and do not necessarily rep those of my company. My opinions are based on inferential analysis of open source reporting; including documented attack patterns and TTPs used against cyber network exploitation (CNE) victims that have disclosed data breach; most don't. Again, I'm inferring the life-cycle of targeted attacks carried out by structured adversaries to paint a broader picture of the targeted attack life-cycle up to the point of initial interaction. Providing attacker activity post initial interaction is not within the scope of this article; however if you need pointed in the right direction for open source reporting let me know.

Extending the Attack Phase:

Our first Client-Side attack model:

Identify victim

Exploit user and vulnerable application

Deliver a payload (Trojan backdoor program)

Interact with the device

This provides a baseline. We need to extend the attack framework to include attack motivation, recon, and goals. This illustrates the notion of a structured adversary and provides context to the delivered payload. This is not just a piece of malicious software, this is a tool used to carry out a mission predetermined by intelligence collected by the adversary. It's important to understand what you're up against.

Real World Attack Model of Basic Phases of CNE as Per Adversary View Up to Interaction

Use what we know about the victim to get them to click through attachment

Craft email/deliver exploit

Exploit victim and vulnerable application

Go back to step 6, change file format if initial attempt is unsuccessful

Developed code isn't always required. Repeat until you find a vulnerable application. If the user clicks once, they will click twice.

Deliver a payload (Provides mechanism for interaction)

Interact with compromised device (victim)

Establish persistence

Take actions to facilitate mission

Download tool set

Establish presence on different device(s)

Perform intended operation as defined by mission

Supported by intel of target, and practiced intrusion/CNE techniques

Establishing a baseline applying the Metasploit framework and then extending the attack baseline per inferential analysis of real world scenarios provides a solid foundation and understanding of the current threat landscape. From this baseline, we can now "build up" the more technical details and target more focused areas for skill development. Registry artifacts and event logs become indicators not only of process creation, but of attacker presence. A suspicious file started during Windows Logon from %Temp% is not only identified as malware, but a tool used by a sophisticated attacker for interaction and an established point of presence within our network boundary.

Now, from a cyber network defender perspective, initial questions to ask and answer (getting answers to these questions is wishful thinking, important to understand why we would want these answered)

Know WHO you are protecting. What does the company produce, design, manufacture?

Define (continuously) WHAT your most critical data is. Hard

Know WHERE that data lives, where it's stored, how it's stored, how it's accessed and by who?

Know HOW to monitor access/connections to those resources. What are my logging sources? What is my visibility? What are my current TTPs as a defender? How can I increase my level of visibility?

Know WHEN new projects will be introduced, where that data will live, sensitivity of the data, and logging/monitoring/visibility to potential resources hosting that data. Hard

What is the value of the data? (Not just monetary value)

When do you reach a threshold of assigning the data a value that indicates that it should NEVER be accessible on a network.

While working with malware samples and identifying the presence of indicators are essential to any internal training program and TTP development, it's equally important that greater context of the attack structure and motivation is understood to facilitate analysis performed in support of CND.

Tuesday, January 31, 2012

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:

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.

Wednesday, January 11, 2012

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 ExcelApply 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

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.

Svhost.exe Process Creation -PID 808 (w6.exe) creates process 256 by running "C:\Windows\msagent\svhost.exe" from a command lineThis 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.

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?

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

List running processes and applicationsCommand Line: python vol.py pslist -f exemplar4.vmemThe “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 diagramCreating
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 interestCommand Line: python vol.py dlllist -p 1936 -f exemplar4.vmemList DLLs for svhost.exe. The dlllist command identifies the location of the binary on the physical disk.

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

Identify MutexesCommand: python vol.py mutantscan -f exemplar4.vmemA 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.

Process relational context:w6.exe is executed on the device from C:\Documents and Settings\foo\Desktopw6.exe is executed “run” at 2009-01-08 02:01:51Based on timeline, w6.exe appears to load svhost.exeIndicators 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