Chapter 2: Concepts of Digital Forensics and Incident Response

"You know my method. It is founded upon the observation of trifles."

— Arthur Conan Doyle, The Boscombe Valley Mystery – a Sherlock Holmes Short Story

One of the fastest-growing cybersecurity fields is Digital Forensic and Incident Response (DFIR). The impact of cybercrime and the reporting of attacks on individuals and organizations have created a significant demand for specialized professionals in these areas to support the investigation of cases from a legal point of view and to ascertain specific details regarding the attacks' context.

Incident response and digital forensic investigation are two activities that are nearly related and should be done in a coordinated manner. Responding to an incident within 72 hours of a security breach is essential for making decisions and taking actions to identify and collect useful information to assist in threat containment.

A typical posture following a cybersecurity incident focuses primarily on ensuring business continuity and acting within the Recovery Time Objective (RTO). If the company disrupts its operations, it could be significantly affected economically and reputationally. Unfortunately, this can affect the procedures for collecting evidence and reduces the chance of finding indicators and artifacts to help identify attack vectors and activities performed by attackers.

That is why we must look for the middle ground between the urgency of returning to business operations and collecting the evidence necessary for the investigation and align business continuity goals with incident response plans.

Identifying and containing a threat, and having the most information related to the security incident, will make a difference in the organization's final impact.

In this chapter, we're going to cover the following topics.

  • Concepts of digital forensics and incident response (DFIR)
  • Digital evidence and forensics artifacts
  • Incident response standards and frameworks
  • Defining an incident response posture

Concepts of digital forensics and incident response (DFIR)

In this section, we are going to review the basic concepts of DFIR and the main differences between an event and an incident.

Digital forensics

Digital forensics is a field of expertise that integrates components of criminalistics and informatics. According to the National Institute of Standards and Technology (NIST), Digital forensics is the application of science to the identification, collection, examination, and analysis of data while preserving the integrity of the information and maintaining a strict chain of custody for the data.

This definition's basis is relevant as the application of science refers to the use of clear and proven methodologies, procedures, and tools so that the evidence obtained has reliability and validity in the event of a legal process.

Identifying and collecting potential evidence is an essential part of first-response procedures in a cybersecurity incident. Suppose there is no clear identification of incident-related devices or the sources of information that might contain useful artifacts. In that case, there is a risk of not gathering the pieces needed to do the investigation.

Another essential element of digital forensics is preserving the evidence's integrity because digital evidence is fragile by nature and easily manipulated. Therefore, you need to use the right tools and follow established procedures. Part of this procedure is the chain of custody, which retains the integrity in the evidence's management, from acquisition until the processing and analysis.

What is incident response?

Incident response is a series of structured steps that describe the actions to take in the face of a security breach. As I mentioned earlier, threats are continually evolving, and their detection is becoming more difficult. If organizations don't have an efficient identification and response capability, the impact of a cyber attack can be devastating.

Incident response professionals can help organizations improve their maturity level by working with plans to respond to different incidents and align them with the business objectives. The organizations must provide the resources to strengthen their technological capacity and define processes that consider the various attack scenarios they might be exposing.

According to NIST, organizations should build an incident response capacity. This involves the following:

  • Creating a policy and plans
  • Drawing up incident management procedures and reports
  • Establishing communication channels with the internal and external parties involved.
  • Creating a structure and work team
  • Training the members of those teams

The creation of an incident response program should be comprehensive; for example, if you have plans that do not meet the requirements or have no specific plans for incidents, that could affect the organization. An incident management system will not be sufficient. Besides, if different organization areas do not align with program objectives or staff are not trained, any plan or tool will fail.

Difference between events and incidents

Events and incidents can be confused sometimes. An event is a registered activity as part of the organization's systems operation, such as attempts to log in to the network, connect through a port, or access a resource.

A security incident is when unusual behavior is identified or in clear violation of an acceptable security or use policy. However, this unique action alone might not be enough, as sometimes such behavior could be genuine activities; this is known as a false positive.

On the other hand, we should not underestimate threat actors, who sometimes have the skills to go unnoticed with the naked eye and Living off the Land (LotL) themselves to make their activities seem normal and avoid detection. Remember, just because abnormal behavior isn't detected doesn't mean everything's OK.

Digital evidence and forensics artifacts

The main element of any investigation is digital evidence. Digital evidence is information that could be stored or transmitted to other devices. One of the most critical challenges facing a professional investigator is identifying and finding the right evidence that could be relevant to a case.

Edmon Locard, a pioneer in digital forensics, formulated a forensic science principle as this: Every contact leaves a trace, which means that in any contact between two items, there will be an exchange. For example, at a robbery crime scene, a supposed offender could leave their fingerprints on several objects, their shoeprints on the floor, or even some hair; this could be enough to identify and find the suspect.

When it comes to digital devices, we can apply the same principle. We use digital devices every day, such as smartphones, wearables, smart homes, and IoT appliances, and any digital device leaves traces behind. For example, when you connect your computer to the internet, it establishes a communication channel through a router or default gateway before reaching a remote server. During this process, multiple resources interact several times and leave information in the device's memory, disk, and logs.

A digital forensic artifact is an object for storing pieces of data or information; for example, the OSes and applications store essential information to work. If you install an application in the Windows OS, this application could create databases and configuration files, or keep crucial data in the system's registry keys.

However, it's essential to not confuse forensic artifacts with indicators of compromise (IoCs) because they are not the same. Let's take a look at the meaning of forensic artifacts. Forensic artifacts are just the object where you can find specific data relating to an application or system. On the other hand, the IoC is the detailed information stored in the forensic artifact and, from the forensics point of view, could be used to identify the presence of malicious activity.

In this example of research performed by Kaspersky's GReAT regarding a malicious campaign that used a multi-platform targeted malware called Mata, document several interesting IoCs as registry keys

HKLMSoftwareMicrosoftKxtNet

HKLMSoftwareMicrosoftHlqNet

HKLMSoftwaremthjk

The Mata malware uses the lsass.exe Windows process on infected victims, loads the encrypted configuration data from a registry key, and decrypts it with the AES algorithm:

Figure 2.1 – Information decoded from a victim's registry

Figure 2.1 – Information decoded from a victim's registry

This means that if you find those registry keys in a system, indeed the computer was compromised by this malware. Also, if you can decode the content there, you will get other indicators, such as C2 IP addresses and malware configuration data.

Looking for artifacts and IoCs

Imagine you are doing an investigation, and you know that you can find relevant information related to the case in the Microsoft Teams application. You could start researching the information you can get from this application, the paths where this data is stored, its format, and so on.

Microsoft Teams forensic artifacts

According to Microsoft documentation, you can find information related to the Teams application in Windows Systems on the following path: C:Users\%USERNAME%AppDataRoamingMicrosoftTeams.

Please note that this path refers to a Windows installation and may differ in your system, depending on the version of Microsoft Teams you have installed. Therefore, I suggest you consult the official Microsoft documentation to identify the appropriate path:

Figure 2.2 – Content of the Microsoft Teams folder in Windows

Figure 2.2 – Content of the Microsoft Teams folder in Windows

In this folder, you can find metadata information from the specific user and the organization, logs and configuration files, and interesting forensic artifacts, such as calls and message registers. All this is organized and stored in multiple formats such as text, JSON, and binary:

Figure 2.3 – Microsoft Teams telemetry configuration file

Figure 2.3 – Microsoft Teams telemetry configuration file

Each action made when using Microsoft Teams generates information that is recorded in different files. For example, the following illustration shows one of the telemetry files that stores data related to, or associated with, meeting participants, meeting calendars, and the organizations to which they belong:

Figure 2.4 – Microsoft Teams session log file

Figure 2.4 – Microsoft Teams session log file

From the forensic investigation point of view, there is more content that can be discoverable using a Microsoft tool called eDiscovery, such as chat messages and links, meeting IM conversations, and metadata, as you can see in the following screenshot:

Figure 2.5 – Content types to search for evidence using Microsoft eDiscovery tools

Figure 2.5 – Content types to search for evidence using Microsoft eDiscovery tools

You can find valuable information for your investigations identifying the right forensic artifacts from a specific digital device depending on the OS and the applications installed.

Different knowledge bases contain information about forensic artifacts that can be very useful as a digital forensics artifact repository: https://github.com/forensicanalysis/artifacts.

IoCs versus IoAs

As I mentioned earlier, an IoC describes the evidence on a digital device indicating that security has been compromised, but when it comes to an Indicator of Attack (IoA), the goal is to identify the attacker's potential intentions, regardless of the tool they used.

These are two different approaches. From the forensics investigation point of view, the IoCs allow the identification of the traces left behind by the attackers at the time of the attack. On the other hand, IoAs are especially useful in a more proactive approach, such as threat hunting, to identify the threat actors' behavior. IoAs could include unknown attributes, IoCs, and contextual information, including threat intelligence information, even when an attack is still in progress:

Figure 2.6 – Differences between IoCs and IoAs

Figure 2.6 – Differences between IoCs and IoAs

An excellent way to identify IoAs is by using the MITRE ATT&CK framework. This framework describes Tactics, Techniques, and Procedures (TTP) that an attacker might follow when performing a malicious operation. You can find details of this framework on the MITRE ATT&CK official website: https://attack.mitre.org/. We will dig deeper into this framework in Chapter 6, Understanding the Cyber Kill Chain and the MITRE ATT&CK Framework.

For instance, think about this scenario. Imagine that you are responding to a ransomware security incident. During the evidence collection stage, you find the following hashes and IP addresses related to the ransomware VHD attack described in this research: https://securelist.com/lazarus-on-the-hunt-for-big-game/97757/.

6D12547772B57A6DA2B25D2188451983

D0806C9D8BCEA0BD47D80FA004744D7D

172.93.184[.]62                  MATA C2

23.227.199[.]69                  MATA C2

Now, you can start investigating a little more by checking information related to the TTP used by the threat actor and mapping them with the MITRE ATT&CK matrix to search for specific information that identifies those behaviors in the systems, as shown in Figure 2.7:

Figure 2.7 – IoAs of VHD ransomware

Figure 2.7 – IoAs of VHD ransomware

Using this approach, you can not only look for malicious files or malicious network connections; you can also search for specific behaviors in your infrastructure. This is why in incident response, it is vital to use both IoCs and IoAs.

Incident response standards and frameworks

One of the main problems facing organizations as regards cybersecurity incidents is the lack of plans and procedures available to face the organization's threats because every cyber attack has specific characteristics. You need to understand the nature of these threats, their associated indicators, and the measures you need to follow in order to contain and eliminate them.

Adopting frameworks and standards for creating your incident response plans will help you to respond more efficiently and adopt a more proactive posture in the face of cybersecurity incidents. It's essential to adapt these frameworks to the organization's needs because every organization has different business requirements, capacities, and maturity levels in this topic.

The following list includes industry frameworks related to the creation of incident response plans.

NIST Computer Security Incident Handling Guide

This is a practical guide for handling incidents effectively and efficiently, supplying the guidelines to mitigate cybersecurity incidents. This document focuses on these steps:

  1. Preparation
  2. Detection and analysis
  3. Containment, eradication, and recovery
  4. Post-incident activity

These steps can be recurrent. For example, if you have detected an IoC on a device, such as a connection to a particular IP address categorized as malicious, you can apply containment actions by blocking communications or identifying all devices connected to that address. Then you could go back and look for new indicators, as shown in the following diagram:

Figure 2.8 – Incident response life cycle

Figure 2.8 – Incident response life cycle

The document also includes guidelines and recommendations for developing an incident response capacity to create an incident response team, as well as develop policies, plans, and procedures, and the steps for communicating with third parties for coordination and sharing information with third parties:

Figure 2.9 – Communications with outside parties

Figure 2.9 – Communications with outside parties

It also includes appendices that raise different hypothetical scenarios to apply the principles of the framework practically.

SANS incident response process

The SANS Institute has published its document, a handbook that defines six structured steps to respond to cybersecurity incidents:

  1. Preparation
  2. Identification/Scoping
  3. Containment/Intelligence Development
  4. Eradication/Remediation
  5. Recovery
  6. Lessons Learned

The SANS handbook establishes a more detailed perspective regarding the distinct phases to respond to a security breach. Even though it has specific similarities with the NIST Computer Security Incident Handling Guide, it does retain some differences.

One of these differences is that the phases of Containment, Eradication, and Detection are independent processes in the SANS handbook in the same way as Recovery and Lessons Learned:

Figure 2.10 – SANS incident response methodology

Figure 2.10 – SANS incident response methodology

A particularity of the SANS six-step process focuses on the scope and contention of threats in an agile way. According to SANS, there are three critical time frames for responding successfully to a security breach:

  • Time to detect: The length of time between the initial compromise and its detection (How long does it take to find it?)
  • Time to contain: The length of time between detection and containment (How long to limit or control the damage?)
  • Time to remediate: The time between containment and remediation (How long to remove the threat?)

According to IBM, the average time to identify a breach in 2020 was 207 days, so you cannot contain a threat if you don't know that it exists; the faster you detect a threat, the more likely you are to stop it in time and avoid a more significant impact.

It is not just about identifying threats; we need to know how many assets are compromised; this is about defining the scope. There is no point in removing a computer threat if it stays persistent on other devices and allows attackers to stay with access to the organization's network.

Another essential element of the SANS methodology is the integration of intelligence development in the step of contention. Threat intelligence is vital for incident response because it provides actionable information for hunting threats and provides indicators for real-time detection to the SOC.

Once you identify the threats, you can apply the controls to reduce the attack surfaces and limit the compromise's impact.

NIST Guide to Integrating Forensic Techniques into Incident Response

Another interesting document is the NIST Guide to Integrating Forensic Techniques into Incident Response. I find this guide especially useful because this document's approach is from the technological point of view and not a law enforcement view.

The purpose of this guide is to integrate the forensic procedures in the incident response phases and perform forensics activities, providing information about different data sources, including files, OSes, network traffic, and applications.

Like the NIST Computer Security Incident Handling Guide, this document supplies the guidelines to develop a forensic capability in the organization and the forensic process:

Figure 2.11 – The forensic process

Figure 2.11 – The forensic process

The concept and the approach integrating these two disciplines is the basis of the idea of DFIR. To collect the evidence, you need to follow the first response procedures. To process and analyze the evidence, you need to identify the forensic artifacts, and to identify IoCs, you need the threat intelligence information.

Defining an incident response posture

The incident response posture has changed radically in recent years. Today, we should be using more than just a conventional approach to fight these cyber threats. We need to create specific plans to deal with threats; for example, you need to use different methods to respond to an information leak or ransomware incident other than a denial-of-service.

Another important thing is that you need to align the DFIR strategy with the organization's business objectives and vision. Every organization is different. You should not implement generic plans just from a compliance posture; you need to test the plans and be sure that they will work in a real-life cybersecurity incident.

The organizations' size doesn't matter. Even medium-sized or small enterprises can adopt a preventive-proactive security posture that includes incident response plans according to their budget and requirements.

In a world where digital transformation has allowed companies to develop and make them more competitive, the difference between surviving a cyber attack and not having the ability to continue their operations is to have plans to respond appropriately and efficiently to these incidents.

Summary

In this chapter, we covered the basic concepts of digital forensics and incident response and learned the difference between events and incidents. We also learned the concept of digital evidence and the importance of forensic artifacts. We identified the differences between IoCs and IoAs. This will be very useful for conducting forensic investigations and identifying the persistence of a threat actor.

We reviewed three of the most important frameworks and guidelines regarding incident response and digital forensics and learned the importance of defining an incident response strategy.

In the next chapter, we will learn how to perform first-response procedures and collect evidence using triage.

Further reading

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.137.160.137