In Part 1 of this post I discussed a number of items that can influence the success of a Rapid Response & Assessment (RR&A) program build out. These are items that I believe must be considered, or I have experienced or been exposed to at some level. In Part 1 I termed these 13 items “Recipe for Success”. Anyone of these 13 elements can affect the success you have with your RR&A program.
The bottom line to RR&A is speed and accuracy. Personally, I still need to automate parts of my RR&A program to collect and analyze the data more efficiently than I do right now. I’m never satisfied and want to improve my procedures. I’m working on this and will be reaching out to my “programmer” colleague’s for help.
Just for clarity, as I stated in Part 1, there is more than one-way to skin a cat, or triage a suspect host. I welcome feedback so I may improve my own program. What I have documented here is just one way of triaging a suspect host. This is based upon what is available to me at my organization using my Recipe for Success as a guide. As I improve my procedures (automation) for processing data, identify additional data points to process, along with tools that give the best bang for the buck, I will continue to fine-tune my program. Its an ongoing refinement that never ceases. The available data artifacts should drive your procedures, not the tools you have. For example, although I use EnCase Enterprise for data collection, this tool plays one part, albeit an important one, of the overall process. I utilize tools such as RegRipper (Carvey) and auto_rip (Harrell) to process registry data because they are so efficient and get to the heart of the matter in a targeted fashion with little effort. I know the data I want to analyze, I know where it is, Reg Ripper and auto_rip get me to that data very quickly.
In this Part 2, I am going to discuss procedures I use to analyze the data once it has been collected. Shown below is the list of data sets I collect for analysis during RR&A. We will pick this up from STEP 2, EnCase Sweep Enterprise.
Step 1 - Attach to target machine with EnCase Enterprise
Step 2 - Perform a Sweep Enterprise (a very useful EnCase feature)
Step 3 - Collect RAM dump
Step 4 – Collect Prefetch files
Step 5 – Collect the $MFT
Step 6 – Collect UsnJrnl file
Step 7 – Collect NTUSER.DAT and UserClass.dat for logged on user
Step 8 – Collect SYSTEM, SOFTWARE, SAM, and SECURITY hives.
Step 9 – Collect Application, Security and System event logs
Procedures
Step 2 - Perform a Sweep Enterprise
Collection/Analysis Tool: EnCase Sweep Enterprise
Sweep Enterprise is a very useful tool built into EnCase Enterprise, especially the newer version in EnCase Enterprise v7.09. The tool can provide a very detailed look into the current activity on a given system where the EnCase agent is installed. You simply enter the IP address of the target device into the Sweep console and execute. You get back an incredible amount of data to assist with the triage of your target device. For example, it is possible to receive back Network Connections, Open Ports, Running Processes and Open Files, among many other items that are available.
The items I review to get a quick overview of system activity are Network Connections/Ports, Running Processes, Open Files and Logged on Users. I realize this is specific to EnCase and not all operations have the funding for this product, but as I stated earlier, this is how we are performing RR&A based upon our Recipe for Success influences.
Network Connections
This lets me see current network connections from the target machine. That being connections to both internal and external endpoints. This feature of Sweep Enterprise will also show me the process that has a specific connection established. As you can imagine, this one piece of data is very useful in identifying and evaluating established connections to end points.
Running Processes
The next item up is identifying and assessing processes running on the target device. If you are intimate with Windows processes, or have an approved MD5 baseline to reference, as you start to pick through each running process you can discount normal ones. This should leave you with a short list of processes that require further evaluation as to their legitimacy. Speaking to further evaluation, this would be especially true if a given process is talking to a notable IP address on the public Internet. This is where you can tie in Network Connections to Processes for suspicious activity. As an example, one such obvious concern would be the discovery of Explorer.exe talking to an IP address located in Eastern Europe. That would be highly notable and require additional follow up.
Open Files
The next item that is up is open files. This feature allows the examiner to see what files are currently open by the individual processes. Very useful to see who has what open.
Logged on Users
Another useful feature is “Logged on Users”. Reviewing this data set upfront will provide me guidance on who is currently logged on to the device, thus giving me indication of what user specific registry hive (NTUSER.DAT) to pull.
Step 3 - RAM Analysis
Analysis Tools: Redline, Volatility
Links:
Volatility – https://code.google.com/p/volatility/
EnCase Enterprise gives you the ability to collect the RAM contents from your suspect host. Once the data is collected you can then parse the RAM dump with tools such as Mandiant Redline and Volatility.
I like to use Redline first to see if I have any notable processes that have been “Redlined”. If I do, then off to the races I go with Volatility to analyze the data. Volatility if far more powerful to analyze RAM dumps. Redline is great, but I just choose to use it to triage my RAM dumps and then get down to the nitty gritty with Volatility. I’m still learning Volatility as use it as often as I can. It has proven to be very useful.
Step 4 – Collect Prefetch Analysis
Tool: WinPrefetchView
One of my favorite artifacts is prefetch files. These files, when available, contain a wealth of information when analyzed with a parser. They are the low hanging fruit to see what binary files have executed on a Windows system. If you know Windows systems and your environment well enough, any anomalies should not take that long to identify. Often, when you have identified a notable process via the EnCase Sweep Enterprise results, you can turn to prefetch files to see prefetch artifacts for said process, thus increasing confidence in the data you are seeing.
Step 5 – $MFT Analysis
Analysis Tool: AnalyzeMFT
I collect the $MFT file and then parse with the tool AnalyzeMFT. By doing this I get a timeline of the file system to perform a cursory review around the suspect date/time for any notable entries. I realize that a lot of malware self deletes its own files as it is preparing to install and get up an running, nonetheless, the MFT is essentially the file system and a lot of the goodies are here for review in timeline format. The more artifacts you review, the more you start to notice anomalies. By taking this approach, you start to build a picture in your head of what has possibly gone on here with this suspect host. You still have more artifacts to review, however, a picture is starting to evolve.
Step 6 – $UsnJrnl file Analysis
Analysis Tool: TZ Works Journal Parser
I love this file! Weird to say, yes. But I don’t care. This file is incredibly useful. If you want to see the life cycle of a file from birth to death, you can do that by analyzing this file. This file, if acquired in time, can pick up from where the MFT left off. Meaning, the files that the malware deleted as it was getting itself up and running, and thus possibly no longer identifiable in the AnalyzeMFT results can often be identified in this file. Part of the results from the JP tool will show you the MFT# and the sequence # so you can follow the birth and death of a given file.
Step 7 – NTUSER.dat & UserClass.dat Hive Analysis
Analysis Tool: Auto_rip.exe
Links:
Note: Before I comment on this analysis and tool, I can’t emphasize my gratitude enough to Corey Harrell for creating it. This tool automates the use of Reg Ripper plugins. Reg Ripper was created by Harlan Carvey, even more gratitude to Harlan for creating this tool. Read the blog post by Corey on his site to get an understanding of what the tool does.
The NTUSER.dat and UserClass.dat files we need to analyze are for the logged on user. As far as analysis is concerned, the data we collect from Step 7 and Step 8 below actually go together to be parsed with auto_rip.
When auto_rip is unleashed against the required hives, it parses the hives seeking out data identified in the available plugins. You get back an incredible amount of specific targeted data.
I have already published a procedure for this tool. You can view the procedure from the below link.
Parsing Windows 7 Registry Hives with auto_rip
Step 8 – SYSTEM, SOFTWARE, SAM, and SECURITY Hive Analysis.
Analysis Tool: Auto_rip.exe
See STEP 7 above and then the mentioned procedure.
Step 9 – Security Event Log Analysis
Analysis Tool: Event Log Explorer
In this step I am looking for specific data in the event logs. The first log I pull up and filter based upon my identified timeline is the Security Event Log. I am assuming auditing is turned on, and quite frankly if it is not, then go turn it on now.
Security Event Log
In this log I am looking for “Process Creation”. Many times I have quickly identified rogue processes starting up by simply looking in this log. Typically, the notable process(es) has some funky looking name. That is a clear indication that this device needs additional review to seek out the source of that strange looking process. I may move onto the System and Application log later if need be.
Summary
To summarize, to successfully triage a suspect host, we are targeting very specific data points. We are not waiting 2, 4, 6, 8 hours to image an entire disk. That takes too long, and quite frankly, is not needed to perform RR&A. By targeting very specific data points we can get the answers we need quickly and make decisions even quicker as to the next steps.
As I stated earlier, this is my way of performing RR&A. Other organizations do it differently. I would really like to hear your thoughts on my approach or how your perform RR&A. Please comment if you have a moment.
Regards,
Mr. Orinoco
No comments:
Post a Comment