Once an alert has passed the classification filter, it doesn’t immediately become an incident. First, we need to understand exactly what happened! This is known as the investigation step.
Follow the Investigation Trail
The final goal is to answer the questions that will determine which actions to take to resolve the issue:
How did the attacker enter the system?
Which machines and accounts have been compromised (i.e., what the attacker has accessed or what can they access)?
When it comes to processing compromised assets, has the attacker created a backdoor access to re-enter the IS?
To answer these questions, you’ll have to put yourself in the shoes of an investigator, formulating hypotheses and searching for clues to prove them.
Investigate Using the Tools at Your Disposal
Investigate the State of the System in SIEM
The starting point for your investigation is the overview provided by the SIEM. Along with system and directory logs, this allows you to identify the actions of users or programs and then determine the state of the system at the time of the alert.
As an investigator, you can see the SIEM as a tool that can answer very specific questions. For example:
For the user mentioned in the alert, where is the list of their logins between a start and end a date?
Who logged onto the system mentioned in the alert during this period?
What are the most recent programs installed on the machine?
What events affect the system or the user at the directory level during this period: privilege escalation, password changes, etc.?
How many connections have been made to a particular address?
Look for Malicious Behavior With EDR/NDR/XDR
If you’re looking for unusual behavior, you can also use EDR, NDR, or XDR. The advantage is that you can search directly through the alerts in EDR, NDR, and XDR, whereas with SIEM, you must search through the logs. Does it allow you to identify alerts related to your investigation?
View Logins in Network Tools
To find clues related to logins, you can also search all of the network tools, including VPNs, firewalls, WAF, and NDR. Again, proceed by formulating precise questions that you then transform into queries for these tools.
Monitor Actions in Applications and Services
If the alert involves applications or services, such as office applications or cloud environments, you’ll find the cause of the alert in the application logs. They can be viewed in the SIEM or directly on the servers involved. You can also search for suspicious behavior in these applications with the NDR.
Manually Deepen Your Investigation
How can I find information on machines that are not yet supervised by the SOC? And when compromised machines are found, how can we trace the attacker’s actions on these machines to identify potential backdoors?
In both cases, the machine will have to be analyzed manually. This is known as forensic analysis.
Recover Artifacts Without Altering Them
A good criminal investigator wears gloves to avoid tampering with the crime scene when looking for clues.
The same applies to forensic analyses. To avoid altering the artifacts you collect, there are a few guidelines to follow:
Copy the contents of the hard disk or RAM to a storage medium to be analyzed, rather than performing your analysis directly on the system.
Once you’ve made a copy, you need to use a write-blocker, which is a tool that prevents you from writing to the storage medium. In other words, it prevents you from altering evidence in your investigation.
Keep a record of all actions taken when collecting evidence, along with their precise dates!
Perform a Memory Analysis
The memory is full of useful information about the services and processes that are currently running. If possible, leave the machine running and copy the contents of its RAM to a memory dump file. To be clear, your goal is to identify a malicious process. For each process you should ask yourself whether that process is usually launched with this command line. You should also determine whether the parent process is the standard one.
Analyze a Windows Hard Drive
If the system is shutdown, you can analyze the hard drive for traces of malicious activity.
In addition to event logs, Windows machines contain a large number of artifacts created by the system to make things easier for users. They are used to shorten startup times, monitor performance, display the most recently opened files, and more. Analyzing them will provide you with a lot of highly relevant information.
Analyze a Linux Hard Drive
On a Linux system, your analysis will focus on the various logs, particularly the application logs and command history. There are also some useful artifacts, but these may vary based on the version of Linux you’re using.
Analyze a Malicious File
If the alert is triggered by a suspicious program, your first step is to analyze the program.
If it can’t be recovered, the EDR allows you to retrieve a cryptographic fingerprint (or hash) of this file so that you can search for it in a malware database, such as VirusTotal.
Feed Your Investigation With New Information
Investigate Through Iterations
In the real world, an investigation is not a linear process. As an investigator, you start with the clues. Based on these clues, you formulate realistic hypotheses about the events that occurred. These hypotheses represent paths of investigation for you to follow. By following them, you’ll encounter other clues that will allow you to either validate or invalidate the hypothesis—or to consider new ones. In other words, you will always have another path to validate.
Therefore, this process involves successive iterations. Each new piece of information we find increases our knowledge of the incident, allowing us to constantly evaluate the extent of the damage, the attacker’s ability to cause problems, and the severity of the incident.
How do you know when to stop looking?
In reality, the various phases of incident response take place simultaneously—and by different teams. As soon as your investigation has identified issues to be addressed, the containment and resolution actions begin.
Continue to Enrich the Incident
To communicate as effectively as possible with your colleagues and the various teams involved, you need to enrich the investigation with all the contextual elements you have identified, including IoCs, logs, investigation alerts, and so on. You should also consider the context beyond the organization.
If the investigation reveals any IoCs that have previously been identified in another organization, you should also include all past analyses on this group of attackers. The incident may also be part of a larger ongoing attack campaign. If this is the case, any information identified by other teams of defenders is worth adding to the investigation!
Communicate With Other Teams
Communicating with other teams involves exchanging information back and forth through the SOAR. This only stops when the investigation provides sufficient answers to the initial questions allowing us to deal with the incident.
What caused the incident?
What has been compromised?
Has the attacker left a way of getting back into the IS?
In practice, this is why you won’t be alone! The first level of analysis is carried out by the SOC, and if necessary, further analysis is carried out by other analysts or by CSIRT, CERT, etc.
Record Your Findings and Continue to the Next Step
Once you have enough information to confirm that an incident has occurred and that you need to respond, you must then trigger an incident response.
To achieve this, you’ll need to change the status of the investigation in the SOAR to create an incident response and link the investigation to it.
Using the answers to your questions collected during the investigation, assign a priority to the incident and develop an action plan.
Over to You!
Following the alert you classified in the previous chapter, you must investigate the detection of suspicious software, known as somekatz.exe , on a Méditronique server that is critical to the company’s backup infrastructure.
What are the most important questions to answer in order to identify whether or not the program is malicious?
Once you’ve proven that the event is malicious, you’ll need to know more about it so you can plan the first steps to limit the threat.What data do you look at to organize an incident response?
Let’s Recap!
Once the alert has been classified, the next step is investigation, where you’ll find out what exactly the attacker has done.
The final goal of the investigation is to answer the questions that will determine which actions to take to resolve the issue. For example, how did the attacker gain access? Which machines and accounts have been compromised? Did they hide backdoors to get back into the network?
To conduct an investigation, you need to find information about the attacker’s actions in the traces that are centralized in the SIEM, EDR, NDR, XDR, or network tools.
This investigation work is carried out through iterations, just like a detective would do, starting with clues that provide new information. As you follow these trails, you’ll find new clues that lead to additional trails, and so on.
You may find that certain machines are not yet supervised by the SOC. If this happens, you’ll need to search these systems manually, taking care not to modify anything that could damage the evidence.
We can also analyze suspicious software in a sandbox or a malware knowledge base.
As soon as the investigation answers these questions, remedial actions can be taken in tandem with the investigation, thereby preventing the incident from spreading.
You’ll learn how to contain the incident in the next chapter.
