Episode 16 - Mastering the Basics: Key Strategies for Cyber Investigations

Kicking off 2025, we're getting back to basics with something every cyber investigator needs to master—starting an investigation the right way. Too often, investigations get derailed because the right questions weren’t asked at the outset, evidence wasn’t properly handled, or reporting lacked clarity.

In this episode, we cover how to build an investigation plan that keeps you on track, ensures consistency, and leads to better results. We talk about evidence volatility, log retention, structuring reports that make sense to non-technical stakeholders, and how to ask the right questions from the start.

Transcript

 Well, hello. It has been a very, very long time since I've recorded a podcast and a few things have changed. I've just finished up. I had my last day at my old job yesterday, and now I'm back. Really keen to get started. Really keen to continue on  releasing more podcasts, and this is the first for 2025. 

The topic of today's podcast  is going back to some basics, an area that I'm really actually quite passionate about,  and that's cyber investigations.  Where do we even start?  And what I wanna do today is diving  headfirst as you do. You can't dive if you're not diving headfirst into.  The fundamentals of every  DFIR investigation or every DFIR case, and that is defining the questions that drive an effective investigation. 

Many investigations I've seen, I've been involved in, I've conducted,  haven't been effective,  I'll admit,  and the reason for that is I didn't have the ideas that I have now. I didn't have the experience that I have now. When running an investigation, 

every DFIR job  starts.  Well,  every good DFIR job  starts with some clear investigative  goals.  Without a clear goal,  the investigation takes longer to run,  it can get sidetracked,  and most importantly,  the potential for the investigation  to get out of hand  is magnified.  And the reason I really wanna emphasize that one. 

It is because in the early days of an investigation,  there's a lot of unknowns.  We don't know whether the attacker has  come and gone, achieved their action on objectives  and are no longer there. 

We may not know if we've interrupted them  and they're actually in the middle of the attack, and if we don't handle this correctly.  It could go really pear shaped.  Having consistency in that investigation  helps so much  from a few different angles.  And one of those angles is training new staff.  But when someone new joins the team,  they might already come with experience in  DFIR  investigations. 

And if that's the case.  Excellent.  If they don't have experience in  DFIR  investigations,  where will you point them? What? What have you got  in your internal wiki in your documentation that  gives them something to land on?  Consistency is really important to the director level, to the board,  and when investigations happen,  the report that they get at the end.

Means so much. It demonstrates how the cybersecurity team operates. It demonstrates your capabilities. It can be used to get budget for  headcount, forensic tools, projects to improve the security posture of the organization, 

but to write a good report.  You need consistency in the investigation. You need a team who are across all of your tools. You need log retention as well so that you can perform a proper investigation and you really need an investigation plan  because there are so many different types of incidents, it can be really hard in the same way  that you would create a playbook.

And find that it is hard to account for every type of incident.  It's a little difficult  to try and plan for every single incident that is gonna occur  from an investigation plan to form an investigation plan.  So you might make it  a little bit broad  as you are running through that investigation plan. 

Use what you need to use.  Discard what you don't or is not relevant.  The more that you use the investigation plan,  the more experience and exposure you have to the environment  will dictate how comfortable you are in  discarding things that aren't relevant. And at the start, it's probably easier to try and capture everything as much as possible. 

One of the biggest challenges that can happen. And I'm still learning this in my  forensics career and in incident response career  is that just because I didn't find anything doesn't mean that the evidence doesn't exist.  So at the start of the investigation, because we're competing with things like we dunno whether the attack is still here,  we don't necessarily know our log retention, we don't know thinking about the volatility of evidence,  we dunno what the volatility of evidence is. 

That's looking at memory or ram that's looking at other artifacts on disc. Things like prefetch, things like shim cash, AMC  on Windows Systems,  the temp directory on Windows or on Linux. It's probably too broad to go into here,  but the volatility of evidence gives you a bit of a framework when you're capturing evidence of what order you should do things in. 

So, because Ram. Is volatile, which means  when the machine is shut down, you lose access to it. That's the first thing that should be captured during an investigation.  This is gonna be a static thing That would be across all of your investigation plans,  if it's relevant,  if you're dealing with something in the cloud, and this would be  an investigation plan that wouldn't necessarily  contain. 

Step one, capture ram,  because if it's a SaaS platform  or if you just don't have access to the system,  you don't need it, so don't worry about it.  Having defined  investigative goals  will guide you on what needs to be done 

and the time to define your investigative goals is not at the time of the incident.  This is pre-work. This is work that's done really well before an incident happens,  and there are different questions that must be answered.  So if we begin with the end in mind,  the end being  the release and writing, or the writing and the release of a forensic report,  what needs to be in that report? 

You've got an executive summary. You've got an intro.  Findings,  detailed findings,  appendices,  things that are too big to fit in. The main body of the report  should go in The appendix.  Here is might where, where you might include big spreadsheets, big log exports,  big raw data samples that  to the reader  may not be relevant.

They may not need to know all of that information because the report.  Is designed  to distill the findings of the investigation.  It's so easy to get bogged down in writing these forensic reports  that are academically amazing  and make a lot of sense to forensic people to incident response. People who also happen to love a lot of detail.

Not everyone is gonna want that level of detail,  but if we get too bogged down.  And including all this extra fluff.  It makes us feel good when writing it, but at the same time, we need to take a bit of a step back and look at it through the lens of who is our intended audience. We can geek out at the end  in the appendix, as well as the recommendations,  but especially in the executive summary  that really needs to be written.

For an audience and for a reader  that we would consider not  interested in, or not technical enough, not interested in the, in the deep technology side, or not technical enough to understand the nuts and bolts of what has occurred.  And so we've gotta really get good  at writing in simple language and being able to articulate  what has occurred without. 

Using jargon  and pitching it in a way that makes sense to the business.  Then we can get into the  introduction and the findings  and we, we can start to peel, peel that back a little bit, telling the story,  and the only way to do that is to build a timeline.  Where do we even start in.  Cyber investigations. 

Once we've acquired the evidence  and made a few copies of it on different platforms,  we've gotta start with the timeline.  If you build the timeline first  and  do it in a spreadsheet  date time,  the artifact where it was located, so the, you know, is it a log source? Is it a memory dump? Is it a USB stick? Is it. 

An MFT file record, is that a journal?  And then the description of  the artifact  and your findings, what you have found  working from a spreadsheet.  You now have a chronological timeline of events  that you can then work from in writing the report  on this date, at this time, this occurred  and the story.  Or the investigation  rights itself. 

One of the main challenges that people have when  writing a report though,  is that there are gaps in the reporting,  and as an investigator,  sometimes an unintentional thing that occurs because our mind is filling in the gaps  as we are reading the report. Our mind is filling in the gap of  what is missing in the words.

The way to combat this is when you're writing the report,  read it out loud from page one to the end.  It's not the kind of activity where when you're reading a normal book  that sometimes you are reading and your eyes kind of glaze over,  and before you know it, you're halfway through the page and. You say to yourself, what did I just read?

You need to take your time,  read it out loud intentionally,  and listen to the words that you are saying.  And from a proofreading aspect, this is incredible. You will pick up sentences that don't make sense. You will find that where there are gaps  in the way that you're describing it. And after about the fifth time that you've gone through and read.

Through the report, you will get a good feel for the incident. And if you really think about it  and put on this lens of, does this make sense?  If I was not the investigator, would I be able to make sense of this?  This is the best way to review your reports with that critical lens.  Sometimes you might look at it in with a different lens, a risk lens. 

Are you making assertions that are either unjustified, not supported by evidence, or are you making assumptions? Assumptions are made because there are gaps? Where do the gaps come from? The gaps come from an incomplete investigation.  As hard as it is when you're writing the report,  if you're finding, no pun intended, that there are gaps in the report. 

What this means is that you'll need to go and reprocess that evidence, and in some cases  acquire the evidence that has not been obtained already.  And that's the danger of  not having an investigative plan and not understanding  what you are trying to capture when you first get an incident.  Because by the time that you have processed your evidence,  written out your timeline. 

Chased a few rabbits down holes.  You then discover that you don't have all of the evidence. You might unfortunately have discovered volatility of evidence.  Logs may have been overwritten, systems have been shut down, or rebooted  evidence has been destroyed by the attacker, and  that is not a good place to be in. 

You'll need to rewrite the report to deliberately exclude that information. Would deliberately exclude the conclusion that is leading  to a dead end, and it's a dead end because the evidence doesn't exist and that doesn't feel good.  So the takeaway here,  where do we even start?  Remember the volatility of evidence? 

Build a timeline,  or should I say,  remember the volatility of evidence, have an investigation. Plan,  capture as much evidence as possible. 

Then read your report out loud to identify gaps.  Another way to describe this  is understanding the why behind the investigation.  What is the end goal here? 

There are generally several angles required for an investigation.  Even if it's a data breach,  the goal of the investigation is not one-sided.  It is not just identify whether there was personal information stored in the database that was exfiltrated.  It's also  how did they get in? Are they still here?

What have they accessed? 

And finally,  how do we prevent this from occurring? Again,  having those questions in mind at the start of an investigation  helps to lead the investigation as well. 

The best way to ask questions is of the people who manage the system,  the business system owners, the system administrators.  The technical contacts, the product manager,  whoever you can get your hands on  to speak with them.  It's an amazing step,  and it's for two reasons,  maybe more.  The first one  is that they know the system inside and out. 

It's their product  on the occasions where they dunno the system inside and out, they know who to direct you to to get that information.  So if we understand the why behind the investigation,  we then formulate a hypothesis based on the available evidence.  And this is a starting point.  The hypothesis is not always  true, and we have to keep an open mind  and follow where the evidence takes us so often.

I'll start with a hypothesis. I have a bit of an idea.  They are my leading questions.  How did they get in? Are they still here? What are they stolen? What accounts are affected?  Have they moved laterally? 

But then as time goes on, the investigation changes.  What I thought initially was the problem  is not the problem. Who I thought initially would be, would be the particular contacts that I have.  To help me in the investigation turn out that I need additional contacts because the system  is connected to other cloud systems. 

So as you keep pulling threads, as you keep following the investigation, you will have to build more connections. You will have to speak with other people. 

Then it comes down to having an interview plan.  So an interview plan  is a formal way of recording  questions based on the investigation,  and it just allows you to gather your thoughts  in a non-confrontational way. So you do this before you meet with the person who you are speaking with,  and then you can run through. 

These questions to understand more about the system or the incident itself.  And the key to a good interview  is ask the question  and then shut up  because you need to let people speak  and if you interrupt them,  they will stop. It blocks the flow of them thinking,  but as an investigator.  It doesn't give you what you need, which is information. 

Let them finish.  Give them a few more seconds.  If there's nothing more, great, then you can move on.  If you have a great idea  while they're speaking, while they're responding to your question. If you have a follow up question, write it down  and come back to it later.  Coming back to it later.  Continues on the investigation flow continues on that interview plan so you can just keep working through.

The second reason is that it can help them jog their memory because as they start talking about other topics, it will pop up for them.  And the third bonus reason  is that if you're dealing with someone who is deliberately trying to misguide you,  this can assist in catching them in a lie.  And I would caution you  when you are doing these interviews  to not take on the role of an interrogator  and not  come across as a tough nose person,  because that's not helpful, because that just puts people into a defensive state. 

What you want to be is curious and relaxed and friendly and calm.  Because you'll have better results  from an insider threat.  Or if you're doing an investigation where you're talking to a CIS admin who has had their system compromised,  they're now dealing with the cleanup. If you think about it from their side, there's a lot of thoughts that could be going through their head when someone from cyber is talking to them, someone from cyber is interviewing them. 

They could be worried that they'll be held responsible for the compromise because they're the owner of the system, or they're the, there's, they're the CIS admin.  Maybe they implemented the code 10 years ago that facilitated the attack and, and they didn't do it knowingly.  And so being kind in these moments is really helpful  and you will get more information. 

If you remain friendly and curious, instead of being abrasive and arrogant and rude and pushy and tough,  it doesn't help anyone. But the end goal of these interviews  is you've got more information to include in your report. You can get additional context,  and also you can understand on that context piece, you can understand how the system is plumbed together if it's complex.

Maybe there's a cluster  of servers and they all work in concert.  There could be databases and getting technical documents, getting build documents,  architecture diagrams. Those kinds of things are great to include in the report as reference material. It also helps you to maybe map out the attack and how it occurred,  but it also gives you new evidence sources as well.

Maybe the database isn't installed. On the server that was compromised,  and that means that the attacker has had to access that system remotely. That introduces a whole lot of other artifacts on a different system. So by keeping an open mind,  having an investigation plan, having an interview plan,  this will broaden the investigation scope, but it leads to a better report. 

And a more thorough investigation  and using  this structured approach for every investigation as appropriate.  Not all investigations will end up in a post incident report or API R, but using that structured approach in the long term  saves time.  You'll be more consistent in the approach,  which makes the exec team and the board happy.

Because they know what they're getting. They know what to expect when there's a report that has been written.  It helps the privacy team  because they can submit their reporting to the government. They have everything that they need.  I now wanna talk about some different investigations that might help, and  some questions that you might ask when starting these investigations. 

And I wanna start with one that's been a hot topic for a long time  at ransomware.  With ransomware, you might ask at the start of the investigation,  how did initial access occur? What devices have started being encrypted? Are backups compromised for an insider threat?  What unusual activities has the suspect account performed?

Are  there patterns that are appearing in the way that they access online resources,  file shares, SharePoint.  Other internal systems,  are they accessing systems that would not normally be considered normal for their job? If someone works in payroll,  why are they now accessing  engineering document shares and engineering file shares, or why are they attempting to access it or why are they requesting access to access those types of areas. 

This is a security culture thing.  You might not know about this unless someone reports it to you.  When they do report it, use that as a pivot point  to then look into their accounts and look even further back  to see how long has this behavior been occurring?  This is before the interview would occur.

Build that body of evidence.  Remember the volatility of evidence. If  you don't have a substantial log retention time,  capture as much as you can right now, as soon as you've made aware.  And then what about credential compromises?  Asking questions like,  where was the first sign of unauthorized access? From what country?

From what source IP address?  Does the account that was compromised have multifactor authentication?  What kind of multifactor?  If there's malware on a system, some questions might be,  what process started the suspicious activity?  Was it a web server that led to a command prompt to PowerShell  that would indicate that  the web server has been compromised? 

That might lead you to ask what version of the web server is running on the system  that might take you down the path of what exploits are currently available, which would then lead you to root cause.  You might also think. Is the malware persistent  or is it a one and done?  Having these questions ready to go gives you a starting point, gives you a bit of a North star for what the investigation could be. 

The idea is that you would have  different investigative questions depending on the type of incident, and over time you would build that investigative plan.  So that depending on the type of incident, you know, what evidence to acquire, what questions to ask, and what should be included in the PIR or in the report at the end.

So before  you even open a tool,  bring up the investigation plan, bring up the playbook, and if you don't have playbooks, the  best time to start is now,  even if they're not  huge flow charts, sharing amongst the team.  Having some workshops, some brainstorm sessions, get the whiteboard going.  What are the processes that you run through during an incident? 

Everyone's got a different process. Everyone's got a different way of doing things,  so that's the best thing to do. Get the team in a room  and document everyone's process, and then combine it into one big playbook, one big process. Then split it out.  Split it into cloud. Split it into local,  split it into insider threats.

Ransomware,  understand the environment, understand the volatility of evidence, your log retention,  where your logs are. Have a plan at practice obtaining the logs. Don't just go for the easy stuff, go for the hard ones. Get the logs from the routers, get the logs from the switches, get the logs from the firewalls, get the logs from the system that no one wants to touch because it's running Windows 3.11  because it's an x-ray machine.

When those systems get popped, you're gonna want to have it practiced. You're gonna want have a process to do it, and you're gonna wanna make sure that the entire team knows how to do it, because if people are off, if they're sick. If they're busy, maybe it's a multifaceted incident. Maybe there are multiple incidents going on all at once, and the person who normally does it is unavailable.

Build the skills matrix,  identify who's good at what in the team, and then cross train to ensure that everyone can do the same job. Build that resilience.  That is the best way  to run investigations.  And that wraps up  cyber investigations.  Where do we even start?