Investigation Framework

• Incident Scoping
• Evidence Collection
• Analysis
• Correlation
• Timeline Analysis
• Intelligence Correlation
• Reporting

Analysis

Now we’re in the good stuff! We got an incident, we’ve scoped it perfectly and collected evidence to start our analysis. If you know the theme now, say it loud “DON’T JUST JUMP IN”. Part of analysis is also organizing your evidence and having a plan to determine how to analyze it. To do that we will have a plan, start writing, find some evil, and present our findings.

Have a Plan

Blade always has a plan; you never want to ice skate uphill. If you “jump in” you will spend some time doing just that. So, we need to take some time to create and preferably write down a plan.

1. Organize and document the evidence you have collected.
   • Once, you’ve done that it will be much easier to determine when you are “done” by going through evidence one by one.
2. Assign analysts to each piece of evidence so everyone is on the same page.
   • Don’t do it alone if you don’t have to, ask for help.
3. Remember your objectives.
   • Are you trying to figure out the source of the malware or ensure the server is back up and running ASAP?
4. Create a task list.
   • If one of your tasks is to research, include that as well.
   • Be specific, make sure you can answer yes or no.
   • If you’re looking at Windows Event Logs, which Event Codes should I start with?

I can hear you already, “that’s a lot of writing before we even look at any evidence”. Yes, it is and that’s what makes good reports which leads to good analysis. But, don’t fret dear reader because I have more templates to help you out. I will discuss this template in more detail within the Correlation stage, but I will introduce you to the Incident_Evidence_Timeline.xlsx.

Incident_Evidence_Timeline.xlsx

This is a spreadsheet to help you track an incident timeline, affected hosts and evidence sources. This will give you a spot to start tracking the things I mentioned above and feel free to change it however you want. I really don’t care if it’s not pristine, I just want to give you a starting place.

Last note on having a plan, several of the tasks you will create come with experience. You may not know exactly where to start, so what’s the task? The task is research “event log analysis” or whatever evidence you have. There are tons of resources out there. I will try to give some suggestions below, but it’s perfectly okay for you to not have all the answers right away. This is why I stress writing the tasks down so you can refer to them in the future for similar scenarios.

Start Writing

This one is simple, get your documents together and start writing BEFORE you start analyzing. Get a plan in place and better yet share your plan with your team to divide and conquer. I am a big fan of using a central area for all analysts to take notes, whether it’s a Sharepoint, Google Doc, OneNote, etc. Just make sure you are still being compliant since you may be looking at sensitive data.

RELEVANT TEMPLATES:

• Incident_Evidence_Timeline.xlsx
• TEMPLATE_InvestigationNotes.docx
• Don’t forget your Scoping Notes, they will help guide where to look next

Once you have your notes and references ready, you can start doing the “analysis” and look for some baddies.

Finding Evil

Analysis is a lot harder than you’d imagine, and I will be the first to tell you that you can burn out quick without realizing it. So first and foremost, remember to take and/or give breaks. I know you don’t want to lose your train of thought, but you will waste a lot more time looking through data with a dead brain than just taking a moment to step away.

SCOPED INDICATORS

So, what’s the first search? Where do you begin? Keep it simple, look at your Scoping Notes and see if there are any indicators mentioned. Here’s a few examples of indicators you may hear about:

• Hostnames
• IP address / domain
• User account

Just take a quick look and see if there is any data within your assigned evidence source related to the mentioned indicator. In addition, don’t forget to look at external sources. Try searching intelligence reputation to determine if the indicator has any connection to known adversaries or additional indicators.

Useful indicator reputation websites:

• VirusTotal
• Talos Intelligence
• X-Force Exchange

NOTE: Just because it’s marked “bad” doesn’t always guarantee it is, so don’t solely rely on this and investigate what the indicator is associated with.

LEADS

Now it’s a matter of determining if the indicators provide any leads. LEADS are perhaps the most important thing in an investigation, a lead is simply a piece of data that may guide you to answer the objective.

One thing to keep in mind, is you will find tons of “leads” and “pivots”. Therefore, a task list is important, make sure you note any “leads” but don’t forget to focus on your objective. Several times I’ve seen analysts start looking at firewall logs but then pivot to a forensic image and never finish looking at the firewall logs. Don’t drop the first lead to pursue another shiny lead without finishing the first.

BASELINE

Another key term in finding evil is establishing a baseline. A BASELINE is a set of known information that you can ensure is expected or safe. For example, you know users in your organization commonly use MS Word, Chrome, and SQL Explorer. This means you can start to “filter” out those known pieces of information. Keep in mind this doesn’t mean adversaries won’t abuse common tools, but it provides a starting point to reduce the noise.

Another great way to baseline is identify a near-identical system or user that was not suspected to be compromised. This allows you to compare activity on the suspect system or user to determine if it is common or expected.

Finally, don’t be afraid to ask others “Have you seen this before?”. This is an overlooked question for investigators and many times you need someone else to confirm. Try to have a good relationship with folks like system administrators, network engineers, developers, and helpdesk because they are the number one source in understanding the technical baselines without even realizing it.

HUNTING

Unfortunately, it is common for you to not have many indicators, leads or baselines when entering an investigation. Therefore, you need to do a little bit of hunting of your own. If you want to be good a DFIR you need to also get good at Threat Hunting, since you cannot rely on tools to do everything for you.

I won’t jump into all the intricacies of threat hunting, for that I recommend looking at this list. However, here are a few scenarios to start hunting and I recommend using SANS posters to guide you as well:

• Rogue Connections
• Unusual Processes
• Unusual Services
• Rogue Accounts
• Unusual Files
• AutoStart Locations

You can see why baselines are helpful since it is up to you to determine if something is “unusual” or “rogue”. You simply cannot do that without having some context about the indicator you identified. Don’t forget to use the hypothesis approach:

1. Observe something “suspect”.
2. Form a question if it is truly “suspect”.
3. Hypothesize if you think it is truly “suspect”.
4. Take steps to answer whether it is or is not.
5. Write down your conclusion.

Findings

 Once you’ve concluded that something you’ve observed is suspect, you now have your first finding. Congrats! No seriously, what you just did is not easy! However, you are not done, now you need to write down your findings. I always recommend writing down findings as you find them, don’t wait to start writing otherwise you may miss something or need to go back later.

You should already have your TEMPLATE_InvestigationNotes.docx so you know exactly where to type your notes. Simply update your heading to the evidence source you are investigating and make sure you include the following details EVERY TIME:

• Timestamp (ISO-8601 format)
• Event Description
• Evidence Source
  • Including query or procedure
• Context (Who, what, where, when, why)
• Code (Filepath, registry entry, command)

Please make sure you include all of these point every time you note a finding. It may feel tedious and that you are going too slow, but I ensure you are doing things the “right” way. Finally, don’t forget to write down your findings in a “report format”, this means write it as a paragraph instead of just bullet point. Why? Because eventually you will be writing a report, so why not start writing in that format now to save you sometime later when you prep your report.

EXAMPLE

“Blue team identified seven failed logons within the Windows Event Logs on DC1 at 2022-01-01T12:00:00Z. The failed logons included the username “noble6”, which is a local administrator on the system. Blue team confirmed the end user did not initiate the logons after conversing with the account owner in person. Additional details around the logon attempts can be found in Figure 1”

Conclusion

Analysis is a longggg phase, it will take a lot of time to get through all the evidence. I’m also not here to say you NEED to follow every step to perfection. Incident response is messy, sometimes you may not have much of a choice in the way you need to accomplish things. I hope this at least gives you an understanding on how to do it well and consistently.

So, I stress again take your time, take some breaks, and don’t be afraid to ask for help. Just because you have the capability to do the analysis, it doesn’t mean you always have the time or mental commitment to do so. Getting through analysis is the most mentally taxing phase of incident response, so if you can do it as I described the remaining phases should feel much calmer.

Again, I appreciate you all and I’ll see you on the next on to talk about Correlation.

Twitter: @CyberCoat

Mastodon: @ChocolateCoat@infosec.exchange

LinkedIn: terrynvalikodath