Unsung tools - Raptor Forensics

Every so often you come across tools that get very little press. One such tool in my humble opinion is Raptor Forensics bootable CD from the fine folks at Forward Discovery. In short, this cd needs to be in your toolkit if it isn't already.

One of the most popular questions I see is "How do I acquire a macbook air?". While I'll try to address that question specifically, I want to widen the scope because it applies to any mac system that need to be imaged.

When dealing with a macbook air your options are somewhat limited.

• There's no firewire
• There's no network card (unless you use the usb port)

What's an investigator to do?

Well obviously if the box is on you can use F-response to acquire it rather quickly. You can only do this however if you have the proper credentials.

What if you're going in clandestinely? What if the system is handed to you and it's off? This is where Raptor Forensics bootable CD comes in.

Burn the iso
Attach a powered USB hub to the macbook air.
Attach a USB target drive formatted however you see fit(though you can do this within Raptor).
Attach a USB cd drive.
Insert the cd.
Boot the mac while holding down 'c'.
The environment will boot.



After the system boots click on the Raptor Toolbox. When it opens you'll see the following.



This is where my biggest problem with tool originates. The workflow from left to right is all out of whack. In order to acquire an image, you need to mount the target drive. In order to mount the target drive it needs to be formatted. In order to be formatted it should be wiped. Now, you've probably already done this but in my opinion, and in terms of workflow in this toolkit it should be changed.

That said, let's format and mount a target drive. First, click the 'format' tab.



Next, Click the 'mount' tab and select your target device. You'll want it to be read/write.


Great! Now that it's formatted and mounted let's acquire something!

In this case I'm imaging a USB key, but it works just fine for the macbook air and other macs. Since everything is point and click it's a pretty straight forward process. Just select the source, target, name and make sure you select 'verify' and then Start.


An imaging window will appear as well as a verification window (which looks the same) when the time comes.

Once acquisition and verification complete you'll see a nice log window appear that shows the acquisition command line and hashes.


And it's just that simple. Hopefully this helps those in need. Raptor Forensics is a great utility to include in your kit and there are 239 reasons it's better than helix for this purpose.

What do you seek?

If you work in this field long enough you will come across a situation where you need to justify your methodology. You will be asked to show why you need to look at all of the data points you look at. It's par for the course. When I get asked to do this I respond simply by asking the following question in return.

Do you seek an answer or do you seek the truth?

This question tends to make the doubter pause. When you are staring a potentially damaging case in the face, do you seek an answer or do you seek the truth? More importantly do the decision makers seek an answer or the truth?

There is a school of thought out there that says if any file containing sensitive data is accessed after the system is compromised, then analysis should stop right there, a line should be drawn and anything accessed post compromise date should be notified upon. I talked about it back in December when discussing footprints in the snow. Think on that for a moment. If a system in your organization is compromised and you run an antivirus scan and trample on Access times, it means you're done, you're notifying, and you're going to have a lot to answer for when your customers get a hold of you. You will not have given the case its due diligence.

In just a second you'll see a graph that I generated. It shows file system activity based on a mactime summary file. Take a few moments to analyze the graph. *I did have to truncate the data set. There were hundreds of thousands of files touched on 5/12*



Does it tell you anything? Imagine the system were compromised on 5/5/09. There are a few things that should stand out almost immediately; Such as the dramatic increase in file system activity beginning on 5/11 and continuing through 5/12. Or how about more simply that there is a story to be told here.

Do you seek an answer or the truth?

A person in search of an answer is going to get a response of "ZOMG the attacker stole a lot of data and you're notifying on every single file contained on the system that contains PII data". If you seek an answer you are not interested in the story that needs to be told, you are not interested in any of the details of the case. You want simply to put the matter to rest, get it behind you and move on to the next case that will be decided by the uninformed.

A truth seeker will ask what happened on 5/11 and 5/12. A truth seeker will interview key individuals, a truth seeker will evaluate the log files present on the system and many other data points to determine what the cause was. A truth seeker will want to hear the story based on your expert opinion, which you reached by examining all sources of data.

A truth seeker will take interest upon hearing that the system administrator not only scanned the hard drive for malware, but he copied hundreds of thousands of files from the drive. A truth seeker will want to see the keystroke log files. A truth seeker will thank you for decrypting the configuration file and output used by the attacker to determine intent and risk. A truth seeker will ask you to look at network logs and a variety of other sources of data to reach a conclusion and render an opinion.

So, the next time someone questions your methodology ask them if they want an answer or the truth. If all they want is an answer, more power to them, ignorance is bliss after all but there is always a story to be told.

Windows Forensic Analysis 2E - a review

In ancient times, when philosophers and scientists gathered to discuss and debate important topics, people would travel for weeks and months to arrive, just to hear the debates. To listen to the great minds of the time, to learn from them, and on occasion ask questions. In 2009 that trend continues though in a different fashion.

In the case of Windows Forensic Analysis we are fortunate enough to have Harlan Carvey. He has a deep well of knowledge to pull from and he continues to pull buckets of information out of the well to keep us all well hydrated. I was honored to read this book, and it's my privilege to write a review. It's the least I could do.

It's a text book, it's a field manual, it's reference material. This is Windows Forensic Analysis Second Edition and it's the best damn book on the planet for Windows Forensics. I thought I liked the first edition and then I read the second.

It's been updated to be sure, but it's also been expanded. There's current information contained in the over 400 pages of content. There are case studies, there are details you won't find elsewhere.

Want to know how to dump memory and collect volatile data? It's in the book.
Can't recall which tool has certain limitations or what the tool can do? It's in the book.
Want to know how to analyze volatile data? It's in the book.
Want to learn how to registry works? It's in the book.
Want to know how to do Windows Forensic Analysis? Read this book.


I've watched the forums and mailing lists since the first edition of the book was released two years ago. Time after time I read the questions being asked and went to the book. In an overwhelming majority of cases, the answer was there. To those of you that asked these questions, do yourself a favor. Go to the bookstore, or online store and buy the book, read it, highlight it, dog ear pages for reference. Make use of the knowledge that has been shared, your clients deserve it.

In ancient times, people would travel for weeks or months to listen and learn from the greats..all you have to do is spend a little money and open the book.

The need for speed

When it comes to incident response we are still struggling to close the gap. It's been mentioned here before, and other places. When a compromise occurs, how quickly do you get to analyze the compromise? Hours, days? Some time even weeks!

And when you do get your hands on a system what are you left with? A lot of trampled data points and an incomplete data set. And..what kind of time frame are we talking about to conduct the analysis, just to make a cut as to whether or not it passes the "who cares" test? Consider the time it takes to acquire and process an image in FTK or Encase. This is commonly referred to as machine time, and it's not uncommon to have too many systems locked up in machine time while the analyst waits for the case to process. And then of course you have the report writing part of the process. All told this takes an Average of 20-40 hours per case, often times more. This equates to two bottlenecks in the process.

The two primary bottlenecks are

1. The time it takes to get to the point where analysis data points are collected, processed and analyzed. There is a lot of time wasted when the analyst is waiting for "machine time" to complete.
   
2. The time it takes to generate a report.
   

This is the traditional model and its inefficiencies. If this doesn't make sense, perhaps the picture below will help.


So now let's look at a model that involves a triage phase.

By including a triage process that collects primary analysis datapoints while the system is live we increase our efficiencies by multi-tasking. Collection of primary data points can be largely automated. The analyst can then focus on analysis of the collected datapoints while the traditional acquisition and case processing takes place. Essentially what this does is take advantage of all available resources - human time and machine time by changing the model.

The benefits of this model are

1. Not always having to acquire a disk image. If the "who cares" test isn't passed with the datapoints that are collected early, then you can easily move on.
2. This is a one-to-many relationship. An analyst can quickly collect datapoints from several systems and conduct triage analysis instead of waiting for a linear acquisition process to progress.
3. It uses all available resources at the same time instead of waiting on one component to complete.

Here is another illustration.

Again...it's not like this is built around F-response or anything. I'm not saying..I'm just saying.

What are your thoughts? I *am* looking for feedback.

Active Directory Snapshots

With Vista, Microsoft finally made proper use of Volume Shadow Copy and the Volume Shadow Copy Service. A lot of great work was done to help others use this during analysis. Server 2008 continues this model but it applies it to Active Directory. Sounds cool eh?

First off, let me say that this is well known to sysadmins, but I'm fairly certain it's not well known in this part of the industry. I've not seen it discussed on any list or forum I pay attention to at least.

For background - Read these pages here and here...I'll wait.

And now, go read this page here....I'll wait for you again.

So, now that you've read about creating Active Directory Snapshots and how to mount a VHD file in windows, let's discuss it.

When performing incident response in an Active Directory Environment, you're most likely going to want to look at a domain controller, especially if the domain controller is compromised, or there is something funky happening in the directory itself. Any self respecting sysadmin is going to have a regular system state backup of the domain controller. This is done so restores can occur if objects are inadvertently deleted, and also as a good practice. In server 2008, this backup is stored as a .VHD file. In a response scenario involving AD, we want to maintain our methodology of not modifying the system any more than we have to, so, we don't want to work on a live copy of Active Directory, we want to work from a snapshot of it.
Here's a pseudo scenario.

A compromise is believed to have occured in Active Directory.
Logging was disabled by the attacker on the domain controller, or the attacker covered his tracks in the logs.
You have been tasked with figuring out what was changed.
You have a recent system state backup.
You mount the system state backup and recover the AD core files.
You create an Active Directory Snapshot.
You load up Sysinternals Active Directory Explorer
You load the snapshot and the AD core files and Diff them in AD explorer.
You now have a smaller dataset to work with and you have a point in time diff of "what changed".

I'll be putting this together in a more formal manner..but I wanted to throw this out there for anyone that deals in Active Directory Compromises, especially with server 2008 domain controllers.

Memory Acquisition for First Responders

Not long ago I sat down with a group of First Responders to discuss triage of security incidents. I discussed leaving the network connection up so I could remotely access the drive and physical memory. Their response is one that I expect many to have come across.

"If we leave the system up, even if we tell the user to not use the computer, the minute we walk away, the computer will be used."

That was kind of interesting to me considering what's at stake but I completely understood their point of view. Too many organizations can't trust their users. So then I thought hmmm....well memory acquisition has come so far so fast that I can simply teach tech staff at any level to collect physical memory. With targeted training and proper documentation it's a fairly straightforward process to follow on contained systems.

Here's a sample from a doc I drafted detailing use of mdd from mantech.

ManTech DD (MDD)

Limitations:
Less than 4GB memory
32 bit Windows Operating System

Installation
Download mdd from Mantech
You can download the standalone executable (recommended) or a .zip file.
Copy the file(s) to a directory on your USB key
Rename the mdd executable to mdd.exe

Usage
Log in to the compromised system
Insert USB drive
Create a directory for the incident on the USB key or SMB share
Open the trusted command prompt for the operating system
Change directories to where mdd is installed
Execute mdd

Command line
E:\IR\mdd>mdd.exe –o E:\00000\memorydump.img

Where 00000 is the case number you've been given.

Notes
Mdd creates an md5 hash of the output of the memory dump. It’s important to capture this information. You can take a screenshot of the window using Ctrl+Alt+Print Screen or copy/paste from within the command line to a text file. Both forms of output are acceptable. Save this file as memorydump.md5


Training first responders to do a memory acquisition is much easier these days.

START methodology

START is a methodology applied to Mass Casualty Incidents or triage centers and frequently it is applied to battlefield medicine. START stands for Simple Triage and Rapid Treatment. I will focus primarily on Mass Casualty Incidents and triage centers. This methodology has a direct tie to The Golden Hour.

It is my humble opinion that START can be applied easily to Computer Security Incidents; Those of both the mass casualty and triage center variety. In a Mass Casualty Incident you are typically confronted by several potential issues ranging from sensitivity of data to criticality of the resource and the threat posed by the compromise. These casualties come from all sides of the organization. The same holds true when you have an influx of dissimilar incidents and you need to prioritize them - think the ER at a major hospital on a warm Friday or Saturday night.

That said I humbly present my adapted START methodology.


Stage 1 Triage
Stage 1 triage is completed on a live system. This stage requires a network connection.

Conduct Rapid Triage

• Collect Volatile Data
• PII search non system created directories
• Limited malware scan
• FLS & MACTIME

Conduct Rapid Assessment

• Preliminary memory analysis
• Review PII tool logs
• Review Antimalware logs
• Review FLS & MACtime logs
• Establish Time of Compromise

Influential factors in Stage 1

MADtime

• MAD time is the Maximum Allowable Downtime an organization can withstand the loss of a resource. Or more the point…the time it takes for someone to get pissed off(MAD).

Initial Threat assessment

• Is it known
• Identify any knowns
  
• Is it attacking other systems
• Is it spreading

Initial Risk assessment

• Sensitive Data presence
• System Profile

Stage 2 Triage

Stage 2 triage is completed on a disk image either after Stage 1 has been completed, or in place of Stage 1 in the case of a physical drive being delivered or acquired from an unpowered system.

Conduct Rapid Triage

• PII search disk image

• Data point collection

1. Network Logs
2. Prefetch
3. Registry
4. Browser History
   
5. MACtime data
6. Malware scan
7. Event Logs
8. Application Logs

Log the case and turn it over for analysis. The combination of the above data points is more than enough to get an examiner started.


This sure looks like a case for F-response especially if you combine Stage 1 and Stage 2 triage...I'm not saying I built this around it or anything...I'm just saying.