Incident Response: A Choose Your Own Adventure Exercise

When I was a kid, I loved choose your own adventure books. You made decisions and could become a powerful Sho-Gun warrior—or if you chose poorly, you could end up killed in battle.

When you think about it, incident response (IR) is like a choose your own adventure book; however, you have no idea of what the story is about.

Almost every IR scenario begins the same:

As you awoke this morning, your phone goes off with an alert that there was an incident at Client XYZ. Do you roll over and pull the covers over your head or respond to the message?

However, you have no idea if you have been dropped into the wild adventures of Cobalt Strike or your remote monitoring and management (RMM) tool being compromised. So not only do you have to make the right choices; you have to ask the right questions.

The Ground Rules

Let’s get prepared to win this adventure. By asking the right questions, you will quickly figure out just how adrenaline-filled your day is going to be and what resources you have available.

Whose Rules to Follow

The first thing you need to understand is whose rules you’re following for IR. Does the impacted organization have cyber insurance that covers the incident, and if so, do they have a set of rules you need to follow? Is this client governed by some compliance that dictates how you need to respond? Or is this some organization that is outside of any compliance? Is the incident so minor it does not even need to be reported?

Incident Severity

The second thing you need to understand is the severity of the incident. Is this some foothold on a workstation, or is this Cobalt Strike running on a server? If it is Cobalt Strike on a server, you will be doing your full IR plan and bringing in outside support to assist. If it is a foothold on a workstation, you can use your team to remediate and kick the threat actor out.

Incident Scope

The third thing you need to understand is the extent of the incident. Is this an attack involving every one of your clients? Is it a hands-on threat actor who is leaping from machine to machine in an organization trying to find a dark space to avoid detection? Or is it malware that has detonated on one machine? Part of understanding the extent of the attack is understanding the attack that is occurring. A tool that dumps credentials in an environment will have a much broader impact than a foothold on a workstation.

It is critical to ask clarifying questions so that you understand the scope of the incident you are involved in, can gather the right resources, and act with the appropriate level of response. You don’t want to be that warrior who ran onto the battlefield without his sword. Unfortunately for you, in this adventure, there are no predefined rules. Only by taking the time to ask questions will you figure out where you are.

Choose Your Own Adventure: Huntress Edition

Now let me walk you through some adventures I have seen since my time at Huntress, and I will attempt to provide you with some key questions to ask. Then you can take this experience and thrive.

Scenario 1

Law enforcement comes to a business you support and states workstation X is involved in a cybercrime and they need to collect evidence. What do you do?

Make sure to have a dialog with law enforcement before they leave. If the police came by your house and said we think your car was used in a robbery, you would not hand over the car keys without asking questions, right?

Similarly, don’t just give a PC to law enforcement without getting information. It is imperative no matter how you find out about an event to ask some clarifying questions.

When did this occur?
How widespread was this incident?
What are the indicators of compromise (especially if dealing with law enforcement)?

Is there a specific IP address to be blocked?
What was interesting about this machine in particular?

Who is the technical contact or supervisor if you have additional questions (when dealing with law enforcement specifically)?

Now, you can leverage their resources to help you in this incident rather than starting from scratch.

Scenario 2

Your EDR solution alerts you to credential dumping on a server.

How did the threat actor get in?

Was it through your RMM tool and you have a bigger adventure ahead of you, or was it through an open Remote Desktop Protocol (RDP) port? Root cause analysis is critical for any incident. If you don’t know how it started, how can you make sure it does not happen again? How do you know to which restore point you should roll back the server?

Does this organization have cyber insurance that will cover this incident?

Does that cyber insurance have certain policies or procedures that need to be followed?

How will you go about limiting/mitigating the spread of the attack on the organization?
What else did the threat actor do to ensure continued access? Once a threat actor gets in, they want to give themselves rights to get back in.

The key thing to remember is to take a moment and think through the situation.

I know in every choose your own adventure book, if I stopped and thought about the decision I was presented with, I could run the adventure so that I was the successful hero.

Do the same thing with your incident response. Take a moment, breathe and ask questions to buy yourself information and time.

My next blog will be about practicing these skills so that you are prepared for incident response. Being prepared before you are in the middle of an event will pay off major dividends, and your future self will thank your past self.