- Incident Scoping
- Evidence Collection
- Timeline Analysis
- Intelligence Correlation
Firstly, we need to understand the goal. The goal is simple, we need to preserve and prepare evidence for analysis.
DISCLAIMER: In some cases, you may need to preserve evidence for a legal investigation. I will go on the record and say the steps I outline are not legal advice. I’m not saying the information I provide ignores legal considerations, but always defer to your legal team if that’s what you’re working with.
Timing is Everything
Alright, you are now aware of some additional details around this incident, and everyone is on the same page. How do you start figuring out how far back you need to look? Detecting malicious events is tough, you can’t expect to catch everything right at the start. Often, you will detect the incident after an adversary has run around for a bit. No shame in that, security is tough what matters is how you respond.
While collecting evidence, you should always preplan for analysis. Do you want evidence of your detection OR should you gather evidence for the entire adversary lifecycle. If you detect ransomware, the adversary likely took numerous steps before getting to ransomware. So, you should always gather evidence knowing you are late. Instead of a few days of logs, always try to obtain at least 90 days of logs. Ideally, you’d like to be able to go back a year, but 30 to 90 days has been a more reasonable expectation.
Keep in mind the farther back you go, the larger the evidence will be and the longer it will take to analyze. This is why we stressed establishing a timeframe while scoping to narrow the focus of evidence collection.
Who has the keys?
One of the largest hurdles to come across during an incident is getting access. In fact, if you need to take one piece of advice from this, this is it! Make sure everyone who needs access to the evidence, can easily obtain it. This doesn’t mean everyone has access to everything all the time, however anyone authorized should know the process to get access.
If your security team needs access to the firewall, make sure they know how they would access it. I know everyone and their mother wants Zero Trust these days, but make sure you limit access while also provide pathways to obtain access properly. Locking someone out of access that enables them to do work is not security. Security is finding the best way for that person to have access securely without major intrusion.
Similarly, as an investigator you will likely need access to a lot of different things, and the last thing you want to do is send nine different emails to get access to the proper tools. Within an organization you will also need to establish the approval chain early so you know exactly who you need to ask when the roof is on fire. Communicate early, try not to surprise folks in the middle of an incident that you need access, they are just as stressed as you are.
In addition, don’t forget about external entities. DFIR firms, vendors, or law enforcement may need access from the outside so make sure you have a way to provide it. Access doesn’t just mean login access, it could simply be a way to transfer specific files, reports, or logs.
In the Evidence Sources section below, I’ll give a few ideas on what you should expect.
For the sake of clarity, when I refer to evidence, I mean any relevant data retrievable in an investigation. Evidence sources continues to expand with all the different technologies and tools available. However, generally these are the types of evidence you will typically come across.
- Forensic Image
- Security Consoles
- Log Files
- Virtual System Files
- Triage Script Outputs
A forensic image is a bit for bit copy of a suspect system which includes all the contents of it’s hard drive(s). The benefit of an image is having the full access to everything that was on the drive. However, you will not have memory so you may not have the full picture of what was active on the system. So, how do you obtain a forensic image? Well, here are a few options.
- Running forensic imaging software (ex: FTK Imager, dd) on the live system.
- You can also mount a physical drive to your analysis system and run the software.
- Cloning the physical hard drive after shutting off the system with physical tools (ex: Falcon-NEO).
- Grabbing a full backup of the system.
- This is not common, so refer to how backups are being maintained at your org.
- Forensic imaging remote agent (ex: Encase).
There are several options and many of them may not cost anything, however, use whatever works best for you. You may not have the resources purchase a tool, but you also may not have the personnel resources to figure out a free tool.
Whatever method you use, please document it as thoroughly as possible. YOU may know how to capture a forensic image easily, but the person on the other side of the country may not. It is also very common for you to forget specific steps or where you saved that bookmark in the heat of the moment. Take a little time to write it down, and for any managers out there, make some time for your folks to document appropriately.
A console is simply a frontend interface to interact with your various tools, appliances, and software. I say security consoles, but really you will be looking across several types of consoles. Here are a few examples of consoles that are most beneficial during an incident:
- Asset Management
- Email Security
- Netflow, PCAP, etc.
There shouldn’t be too much to “collect”, however make sure you check the following for each of these consoles:
- What access and role to view all relevant data?
- How long events are retained in the console?
- How to export necessary logs and if they contain more/less than the console?
- What type of data is and is not available?
- Who manages the tool/appliance?
If you do any kind of DFIR, you will learn to love logs. Logs are the best bang for buck when considering evidence. They are “relatively easy” to enable, and most software provides some level of logging. For DFIR, there are more useful logs, for example performance logs will not provide the same value as security event logs. Often, you can also simply export events from security consoles and then you have your full set of relevant logs.
Today, you probably have logs enabled however default logging is usually not enough. Windows Event Logs are probably the most common form of evidence I will come across, but default Windows Event Logs does not provide the full context. Always check to see if logging can be expanded and preferably forwarded to a SIEM or log aggregation tool.
The other problem you will come across is retention of logs. Default retention is typically 24 hours or a specific size before writing over older events. Ideally, you want to aim for 30 to 90 days, but space is limited for everyone. This is where a SIEM is helpful, not only do you not need to retain logs on the system for an extended time, but you also have redundancy in case the system is corrupted or shutdown.
So, where do you look for logs during an incident, if your SIEM is still “in progress”.
- Security Consoles
- Domain Controller
- Remote Services/VPN
- Network appliances/devices
- Software specific logs (ex: applications)
Hopefully, this gives you somewhere to start, but keep in mind every organization is unique and has all kinds of unique devices. This is why asset management is key to strong security and investigations.
I will also give my special shout out to Sysmon. Sysmon is an extension to monitor and log additional events on a Windows or Linux system. It does a fantastic job of providing additional context beyond what Windows event logs typically provide. If you use it and store the logs properly, I am sure your investigations will be easier.
Virtual System Files
I am sure several systems in your environment are likely virtualized. Meaning there is no physical system you interact with other than the virtual machine (VM) host which will not have information about the virtual machines themselves.
Even if it is a virtual system, you can still use any live capture methods mentioned in the Forensic Image section. However, virtualized systems provide some additional methods to analyze them much quicker.
A VM will produce a virtual disk typically with the extension VMDK. The beauty of this file is that it can be treated as a forensic image with most forensic analysis tools. The only consideration you need to make is ensure you “PAUSE” the VM instead of “SHUT DOWN”. This will preserve the memory which can be collected from the VMEM and VMSS files. Just be sure to copy the files instead of analyzing them live.
What about the cloud? The cloud operates a little different, typically you need the proper commands to pull things like a VMDK, logs, or any other relevant evidence. I won’t go too deep into this now, but maybe in the future.
Triage Script Output
This is probably my personal favorite way to obtain evidence some a live system. A triage script is a set of preconfigured commands to collect specific forensic artifacts that an analyst would typically look at with a forensic image. The advantage is that you can only pull specific artifacts instead of the entire drive which will save quite a bit of time. The disadvantage is you may miss some pieces of data depending on what the triage script collects. However, the triage scripts will get you the “essentials” of DFIR and is only getting better. Triage scripts typically can obtain a copy of the memory for further live analysis at the same time. The only limitations of using a triage script for collection is
Don’t get it twisted! Using triage scripts does not mean you don’t need the forensic image. Often, the triage script output is used to find leads so you can efficiently collect forensic images as needed, instead of blindly.
Triage scripts are still relatively new compared to forensic imaging software, but they are quickly evolving and becoming more robust. Here’s a few solid options to check out.
So now you should have some ideas on how to get that evidence that you need. Next, we’ll go through some tips for Analysis.
One thought on “Investigation Framework | Part 2 – Evidence Collection”
Pingback: Investigation Framework | Part 7 – Reporting | DFIR & Ramblings