One of the keys needed for a sniper to successfully complete a mission, is target identification. They do not simply put “something” in their cross hairs, pull the trigger, watch the target go down, and call it a day. They are after a specific target. Applying the sniper forensics methodology to digital forensic casework is no different at its core – you are going after something specific. So what does that look like…exactly? Well…get ready…cuz I am going to break it down for you in 3 easy steps.
Step One: Define the Target
In the world of incident response, we are engaged for a very specific purpose. There is some problem that needs to be addressed, or some “mystery” that needs to be solved. Before anything can logically be done to work towards a solution, we have to know what it is that we are there to do.
This is a very important and frequently overlooked step. On many occasions, both during my tenure at IBM/ISS and now at TrustWave our customers are usually going through one of the worst experiences in their professional lives. They feel like they are calling in the experts, and they we should be able to “find evil” with little or no direction. That is simply not the way it works. We have to something to work with. To quote Dr. Evil, “Throw me a frickin bone here”.
To facilitate this process, we developed a “Triage Worksheet” that helps us to extract information that will be meaningful to us from the customer. For example, we want to make sure we understand thing like:
- When was the incident first noticed?
- Who noticed it?
- How did they notice it (Alert? System degradation? Third party?)
- Which systems were affected?
- What Operating system(s)?
- How are those systems related?
- What (if anything) has been done since the incident was first noticed to address the problem?
Our internal worksheet has several other questions that we ask the customers, but you get the idea. Once you have answers you can start to develop an investigation plan. One important thing to remember is that your initial triage worksheet and resulting investigation plan WILL LIKEY change after you get onsite. The reason fro this is pretty simple…you are an incident response expert…the customer is not. I have been on enough cases to have learned this valuable lesson, so I feel it’s my duty to pass it on! The sooner you learn to plan the best you can, and be flexible when you get onsite, the better off you will be. Semper Gumby!
Step Two: Clarify The Target
While this may sound basic, and unnecessary, I assure you, it is not. Once you have spoken with the customer, and feel like you have a decent understanding of what your goals are going to be, repeat them back to the customer. No kidding…this goes back to my High School communications class with Mr. Grunsfelder (amazing I can remember his name…totally irrelevant to this post, but an accomplishment nonetheless). Use your “I” statements…for example…”I heard you say that you would like me to find BLAH”. Use them for each and every goal the customer has defined. This will accomplish two things…first, it will set targets for you so that you can set parameters for your investigation, instead of willy nilly wandering around hoping to find something gof value. Second, and perhaps more important, is that it will provide you with deliverables that the customer has already agreed upon!
Several of my fellow investigators have shared such experiences with me and told me just how messy it has been for them! Here is a brief example:
Customer: You failed to tell me that 20 of my workstations were infected with Conficker!
Investigator: You hired me to determine if company data leaked out of your corporate network.
Customer: Well…I thought you would have found that! After all, you are supposed to be a security expert!
Investigator: If you refer to our statement of work, that you signed, you can see that you asked me to identify if company data leaked out of your corporate network. Nothing more. At price we are billing you per hour. I was trying to be efficient and responsible with your money by delivering precisely what you asked me to deliver. If you would like, we can amend the contract, and I would be happy to run AV scans on all of your systems, and even remove the malware.
Customer: Argh…OK…well…if it’s in writing, I supposed that is what I asked for. But I will want this virus removed! Send me an addendum! And Get back to work!
Can you imagine how this scenario could have played out if the investigator had NOT clearly defined the goals of the investigation and followed up with the customer! Oye…you do NOT what to be there…I promise!
Step Three: Apply Logic
As investigators, much like our pentesting brethren, we have more tools that we could ever hope to use. Truth be told, I do 99% of my forensic work with about five tools…and NONE of them are commercial…all open source baby! Why you may ask? For one very simple reason…I know how to use the tools that I have! But I digress…
Once you have the target, and after the customer has agreed to the statement of work, it’s time to get busy! THIS is question I get the most from fellow investigators. How do I go from a written contract, to actually starting the investigation? What evidence do I gather? Why? What do I do with it once I have it? This is actually, a very simple step if you the answer…which is…gather what you need!
Here is an EASY example:
The customer has asked you to determine if a specific system has accessed their internal network. The system is a laptop, and was stolen from an employee’s car on March 7th, 2010 and his VPN credentials were revoked on March 10th. The employee states that he did not have a boot up password, and that his VPN password (along with every other password he has) was stored in a spreadsheet on his desktop. The VPN concentrator has logs. There IS a firewall AND it was logging (don’t get used to this…this is rarely ever the case), and the Windows servers are logging.
Cake right!? You get the VPN logs, the firewall logs, and the local system logs. OK, so you get on site, and find out that there are 120 systems that the attacker COULD have made it on to once inside the internal network.
OK…so you VPN logs DO show that this MAC (which the network admin actually had mapped in an asset tracking spreadsheet! Yay admins!) logged in on March 8th from 0600 to 0800. The BAD news is that the firewall only shows access on the external interface…no logging on the internal subnet…thanks! So you have two choices, you can either take forensic images of 120 systems, or you can think of a better solution!
Logically, what happens when a user interactively logs into a Windows system? His NTUSER.DAT file updates right? Yes…it does (in case you were wondering)! So, all you would have to do, is write a small batch file that queries the NTUSER.DAT files from all of the systems (giving it domain admin creds) and sort by last access time. Then, you will have the NTUSER.DAT files that updated (indicating an interactive login) during the two hour window. So your 120 potential targets were just reduced to four! Nice…now you can logically image only four systems instead of the 120, and have solid data to back up your actions.
In conclusion, we have talked about the three steps needed to start rolling on a case. In Step One we covered identifying what is that you are there for, Step Two covered clarifying that information with the customer, and Step Three covered applying logic to get you started. By implementing these three easy steps into your investigations you can build efficiency, clarity, and confidence into your work, your customers, and your investigation plan.