IR Playbooks: TryHackMe Writeup

IR Playbooks

Task 1: Introduction

Knowing what actions to take in case a specific alert is triggered can often become confusing when dealing with alerts in a SOC. Incident Response playbooks help reduce some of the confusion arising from such scenarios. But what are IR playbooks, and how do one create them? Let’s learn in this room.

Objectives

In this room, once comleted you will be able to answer the following questions:

• What are IR playbooks, and how are they used?
• How do we capture the different steps of the IR process in a playbook?
• What roles and responsibilities are assigned to the different members of the SOC in a playbook?

No answer needed.

Task 2: The Incident Response Documentation Universe

The Need for Playbooks

Since organisations already have an incident response process, why are playbooks required? The difference is mainly in the granularity of the response process. The IR process defines the high-level steps needed during an incident. It superficially mentions the stages of the IR process and does not dig into details about what steps must be taken during each stage. For example, the IR process might mention that containment and eradication actions will be taken at a particular stage without going into details about containment and eradication.

Use Cases and Playbooks

When monitoring is set up in a SOC, one major part is building use cases. Since most organisations produce terabytes of logs daily, it is impossible to properly view and analyse them manually. So, use cases are built to flag suspicious activity that needs further investigation. Once the use case is triggered, the analyst analyses the logs which triggered the use case and decides what actions must be taken. These actions are written in the playbooks. Therefore, we can reasonably assume that every use case created by the detection engineering team needs to have a playbook assigned to it. However, while the detection engineering team might develop hundreds of use cases, only a dozen playbooks are created for them. While there is a unique playbook for every use case, multiple use cases might trigger a single playbook, making it a one-to-many mapping.

#2.1 Can multiple use cases trigger a single playbook? y/n

Answer: y

Task 3: IR Process and Playbooks: Preparation

Prerequisites of Playbooks

Like the IR process, the prerequisites of playbooks are created to ensure that the capability of detecting, investigating, and responding to an incident is available. Without this capability, the playbook might never trigger. As described previously, each playbook refers to a few use cases that will be the starting point of the playbook. Therefore, triggering use cases also need to be noted in the prerequisites of the playbook. In short, the following points should be ensured before a playbook is created, and these prerequisites can be indicated at the start of the playbook.

• All relevant logs are present and integrated into the SIEM.
• The logs are appropriately parsed, and the required fields are extracted and searchable.
• The logs contain all the required fields, such as machine information, IP information, process name, and more.
• Use cases are created on the specific behaviour that needs to be flagged and responded to.
• The recommended security controls are applied, representing the organisation’s policies.

#3.1 What stage of the IR process can be translated into prerequisites for the playbooks?

Answer: Preparation

Task 4: IR Process and Playbooks: Detection and Analysis

Detection and Analysis Checklist

As a checklist, we can ensure the following points are considered in the detection and analysis part of the playbook:

• Alert trigger
• Initial verification of data from the logs
• Verify potential IOC data (hashes, IP addresses, domain names, etc.) from e.g. OSINT, threat intelligence feeds, internal documentation
• Verify metadata of the IOCs (parent process, command line instructions, domain age, open ports, etc.) to understand the context
• Depending on the results of the above investigation, either close the incident or escalate it for containment, eradication and recovery

#4.1 What steps should we follow if the incident is a False Positive?

Answer: Close incident

Task 5: IR Process and Playbooks: Containment, Eradication, and Recovery

Checklist for Containment, Eradication, and Recovery

The IR process’s containment, eradication, and recovery phase is only triggered when the incident is a True Positive. Therefore, the checklist here will focus mainly on limiting and reversing the impact of the incident. We can chalk out the following checklist for this phase of the IR process:

• Identify the root cause of the incident.
• Identify the impact and the affected assets.
• Contain the threat by isolating the affected assets and limiting connectivity.
• Perform actions to remove the impact of the threat from the affected assets.
• Bring the assets back to the last known good configuration.
• Resume services as usual for all the affected assets.

#5.1 To recover systems affected by an incident, which configuration should we bring them back to?

Answer: last known good configuration

Task 6: IR Process and Playbooks: Post-Incident Activity

Post-incident activity is the last stage of the IR process. The steps to be taken at this stage vary from incident to incident and will depend on the gaps identified during the process. The following questions are addressed during post-incident activity.

• Why did the incident happen (or using the 5 Whys method, which help reach the root cause)?
• What gaps were identified, which, if plugged, would have helped avoid the incident?
• How can we improve People, Processes, and Technology to avoid such incidents in the future?
• What steps, if taken, could have minimised the impact of the incident?

#6.1 What is the last stage of the IR process?

Answer: Post-incident activity

Task 7: Putting It Into Practice

IT IS TIME TO PRACTICE:

Start and let the VM load for around 3 minutes, as it will run in the background.

To access the dashboard, you can do it in one of the following ways:

1. Connect via OpenVPN (more info here), then type the machine’s IP http://IP-addr in your browser's address bar.
2. Follow the link https://IP-addr.p.thmlabs.com/ using your browser.

You’ll be presented with the Kibana login screen. Enter elastic for the username and elastic for the password.

Scenario

Deer Inc. is working on research that is of national importance. Therefore, they remain in close contact with the national CERT, which also has a sensor in its network. The sensor can identify network anomalies, which are then communicated to Deer Inc. They have received a communication from the national CERT regarding suspicious network activity detected in their network. The following are the details shared by the national CERT:

We have an instance of Elasticsearch and Kibana in the attached VM, which will act as an SIEM solution in this investigation.

Once you are logged in go to Discover and enter the Destination IP in the search bar and set the date as “2024–08–28" and in the to field add the time as “now”. This step is demonstrated in the image below:

Expand the result that you get and look for “process_exec” and you will find the answer to 1st question:

#7.1 What is the name of the process that initiated this communication?

Answer: taskhsvc.exe

#7.2 Is this process malicious, as per VirusTotal? y/n

Answer: n

#7.3 What is the name of the parent process of this process?

Answer: @WanaDecryptor@.exe

To get this answer, on left side in the panel expand the “Available fields” and click on “parent_process_name” and you will find the parent process as shown below:

#7.4 This process’s parent was launched by another process, which is a notorious ransomware. Which ransomware is that?

Answer: Wannacry

To get this answer, search process’s parent list of taskhsvc.exe as shown below:

#7.5 Which playbook should be followed to respond to this incident?

Answer: Malware Playbook

As, WannaCry is a malware we have to use a malware playbook.

#7.6 Is this incident an FP (False Positive) or a TP (True Positive)?

Answer: TP

#7.7 In case the incident is a TP, what will be the next step in the IR process?

Answer: Containment

In the “PICEARL” (Preparation, Identify, Containment, Eradication, Recovery, Lesson’s Learned) process of Incident response once you have identified the root cause the next step is to contain the malicious process.

Task 8: Conclusion

And that’s a wrap. In this room, you learned about playbooks, especially:

• What playbooks are, and what their place in the documentation and processes hierarchy of an organisation is.
• How the different stages of the IR process are mapped to action items in a playbook.
• How we can use a playbook to investigate an incident.

No answer needed.

Yaaayyy! Now you are ready to create IR playbooks.