Rapid Response & Assessment of a Suspect Device – Part 2

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: 

Redline - https://www.mandiant.com/resources/download/redline

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

Link: http://www.nirsoft.net/utils/win_prefetch_view.html

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

Link: https://github.com/dkovar/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

Link: https://tzworks.net/prototype_page.php?proto_id=5

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: 

Blog Post - http://journeyintoir.blogspot.com/2013/05/unleashing-autorip.html

Tool - https://code.google.com/p/regripper/downloads/list

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 

https://docs.google.com/file/d/0B0Mr40VSsJozSXFSdm1lcTBJZk0/edit?pli=1

 

Step 8 – SYSTEM, SOFTWARE, SAM, and SECURITY Hive Analysis.

Analysis Tool: Auto_rip.exe 

Link: http://journeyintoir.blogspot.com/2013/05/unleashing-autorip.html

See STEP 7 above and then the mentioned procedure.

Step 9 – Security Event Log Analysis

Analysis Tool: Event Log Explorer

Link: http://www.eventlogxp.com/

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

 

Rapid Response & Assessment of a Suspect Device - Part 1

Now the holidays are out of the way I can get back to posting. This post will be a two part series. I tried to get it out in one part, however, time and commitments are not allowing it.

As the title suggests, this topic is on Rapid Response & Assessment (RR&A) . When a suspect device comes your way, how do you respond to get the answers you need quickly? The two posts will discuss a given approach that has evolved within my environment based upon the influences I am exposed to.

I hope you enjoy the read and I encourage feedback. I want to know how your organization deals with RR&A.


PART1

Preface

Rapid Response & Assessment (RR&A) is exactly that. A quick response by IT Security personnel assessing a potential concern they have been alerted to. Get it right; by implementing the correct program, you will be in a good position to fend of the bad guys and minimize the potential damage that will undoubtedly unfold. Get it wrong, well, no need to explain that outcome! 

Depending on the tools, resources (head count & money), talent, company culture, management support, Corporate Security & HR Support, priorities, policies, processes, internal politics, significance in the global economy, regulations, and the sense of urgency that individuals within the organization place on Rapid Response & Assessment, some, or all of these influences may contribute to how individual organizations respond to suspect devices that appear on their radar for one reason or another. No two organizations are alike, and so goes their RR&A approach. My organization is no different. We execute our existing Rapid Response and Assessment procedure based upon the vast majority of the above-mentioned items. Is it perfect? No. Is it driven by a person with a passion for doing this stuff who is continuously tweaking it and fine tuning it, always trying to do the right thing for his employer? Absolutely. 

In no particular order, let’s take a cursory look at the above-mentioned items. 

RR&A – Recipe for Success 

1. Tools – Do you own tools that can give you rapid unfettered access to remote hosts to perform assessments?

2. Resources – Do you have the people and money to operate?

3. Regulations – Are there any regulations setting minimum requirements for on-site full time Incident Response and Digital Forensic personnel?

4. Talent – Do you have the right people with the required skill sets?

5. Culture – What is the cultural attitude within the organization on this issue?

6. Management Support – Do the correct management within the organization support your efforts?

7. Priorities – Where does RR&A stack up on the priority list?

8. Policies – Do you have policies in place to guide your response?

9. Processes – Do you have tested & mature processes to execute RR&A? 

10. Politics – Are there any inter group politics inhibiting your RR&A program?

11. Significance – What is your company’s significance within the global economy?

12. Urgency – Does your organization have an inherent sense of urgency to deal with these matters?

13. Corporate Security & HR Support – This one is an absolute must, however, you need to have all your ducks lined up to leverage ongoing support for your program. Do you have support from the folks in Corporate Security and Human Resources when you send them reports that require them to issue a slap on the wrist when employee misconduct is the cause? After all, do you want to see your report that details a virus outbreak as a result of an employee policy violation disappear into a black hole on the HR Managers desk after you have spent many hours putting it together? You must partner with these folks and make them clearly understand what it is you are bringing to them. Your concerns and recommendations must emphasize the seriousness of the mater and lay out the potentially devastating consequences based upon the users actions. For example, this could have been much worse and here’s why.

Any one of the above items can impact the level of success you enjoy with your RR&A program.  

The purpose of this post is to detail the RR&A approach and methods used by my organization, in particular, my group, in hope that other individuals who may be struggling in this area may get some ideas on how they might be able to address RR&A in their own organizations, or I may get some feedback and suggestions on how to improve my own program. Even if this approach cannot be replicated due to specific constraints (see recipe for success), there may be pieces of the approach that can be utilized. It boils down to sharing knowledge, ideas, and varying methods/approaches in achieving a goal. Responding to an incident as quickly and as efficiently as possible to determine if there is a problem or not? I would like to hear how other organizations perform RR&A.

Shown below is high-level view of my environment. The end node environment is made up of end user devices such as desktops and laptops and then there are servers of various types. In this particular environment the Rapid Response & Assessment resides with the Forensic Response Team.

The Environment

30,000 Windows desktop devices (PC’s/Laptops) spread across multiple continents

4,000 Windows servers spread across multiple data centers

The Monitoring and Response Teams

Security Operations Center  - First Alert, Triage & Incident Response Coordinators

Threat Management Team – Net Flow Analysis, Packet Analysts, Malware RE

Forensic Response Team – Host Assessment and Disk Forensics

The whole point of RR&A is to be in a confident position (see recipe for success) with mature and tested procedures (test and trust your procedures) that can quickly confirm or deny if a problem exists. You will need to determine very quickly if a reported incident will require additional follow up, or if you can stand down because it was a false alarm. My group typically responds to devices where the SOC had detected an anomaly based upon output in the SIEM (Security Information & Event Management). To be able to respond effectively and efficiently, you need the right tools deployed into the environment. For a large enterprise that is spread over multiple continents, an agent-based tool is best suited to give the responder instant access to the end node under question.

As the saying goes, there is more than one way (and tool) to skin a cat. The information here in one example of how a given organization performs RR&A. Again, see the Recipe for Success noted above that can influence your program and approach.

Tools & Procedures

Today’s response tools need to be as capable and versatile as the malware we are encountering. What does this mean? Well, the first thing that comes to mind is a tool that can perform remote RAM dumps (aka Volatile Data) and bring back the volatile data for analysis. Additionally, you need to be on a position to cherry pick the files of interest that will be reviewed during your assessment. For example, during incident response you need to be able to perform a RAM dump, start processing the dump via a tool such as Mandiant’s Redline, or Volatility, while at the same time collect and process other parts of the system activity. The particular tool used by my group to achieve the remote collection is EnCase Enterprise. 

Analysis Tip: Use the 32-bit version of EnCase to acquire RAM dumps on 32-bit target devices.

At a high level, the RR&A goes something like this…Alert, Respond, Pull Data, Analyze, and Decide.

Alert

The Alert will come from the SOC. They have seen something suspicious, deemed it a concern, and opened up an incident ticket.

Respond

Once the incident ticket hits us, RR&A personnel are engaged to act.

Pull Data

The device is identified, attached to with our Enterprise Tool; a procedure is followed to start pulling Volatile Data and select files. The data of interest that is pulled is listed below in the order it is acquired.

Step 1 - Attach to target machine with EnCase Enterprise

Step 2 - Perform a Sweep Enterprise (a very useful EnCase feature)

Step 3 - Perform a 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.

The collection of the above data does not actually take that long. The forensic platform design and the placement of equipment throughout the environment facilitate the expeditious collection of the data and deliver it to the examiner to start analyzing.

Analyze

After pulling the data outlined above, we need to quickly parse it with our tools in an attempt to identify any notable concerns. Of note, the Sweep Enterprise feature built into EnCase is an incredibly useful feature. By entering the IP address of the target machine into Sweep Enterprise and executing it, we gain much visibility into the device activity on a number of levels. For example, it allows you to see running process, network connections, open files etc.

Decide

A decision is made on whether to pursue the device further. False alarms do happen and this allows the SOC to fine tune their alerts.

In part two of this post I will be discussing the actual procedures used to parse the collected data looking for indicators of compromise. The post will detail the tools and approach based upon the data points we want to analyze.