Stop Destroying Evidence: Why Understanding the Entire Attack Chain Before Responding is Critical

Tier 1 SOC Analysts are often referred to as triage specialists. With so many alerts to handle, they need to pick the most severe cases to deal with first and get to the others when they have time. Many SOCs provide their Tier 1 analysts with runbooks—a set of standard procedures they can refer to when resolving common incidents—to help them work more efficiently.

While that may seem like a prudent process, runbooks can have a detrimental impact, one that might resolve a particular alert but end up destroying evidence that might be needed to investigate a more serious security incident. Understanding why requires a little bit of background on how modern attackers are infiltrating networks.

Seeing the Whole Attack Chain

Often security teams rely on telltale signs to spot attacks. These signs are known as Indicators of Compromise (IoCs). Typical IoCs include blacklisted IP addresses, malicious URLs, file names, or file hashes. Analysts typically take action against a discrete IoC, say blocking an IP address or quarantining a computer, then close the ticket and move on.

But approaching an attack this way is too simplistic because each IoC is likely just one step in a more intricate attack timeline. The first mistake a security analyst can make is focusing on the resolution of individual security incidents as opposed to understanding the full scope of the incident. An attacker is not done once the machine is infected with malware; that’s just a foothold toward larger goals.

To help understand how attackers work to steal your data or resources, a new framework from MITRE called ATT&CK was created. The framework lists the tactics an attacker might use toward their ultimate goal, and the specific techniques used. You can think of ATT&CK as the complete array of tools an attacker has at their disposal and the matrix as a kind of map that will help you figure out each step in the attack chain. When a Tier 1 analyst is only focused on resolving individual alerts as per the runbook, they are probably missing the bigger picture that a more experienced Tier 2 or Tier 3 analyst would recognize. But it gets worse.

Destroying the Evidence

It’s bad enough that your triage specialists are missing the bigger picture, but what’s worse is that they may be making the jobs of your skilled incident responders and threat hunters more difficult—and in some cases, impossible. It’s not the fault of the analyst. In addition to the runbook procedures, SOC managers often goal their teams on median time to response (MTTR), so there is pressure to resolve quickly. Getting back to our analogy, it’s like a detective trying to solve a case quickly and close it out, but in the process missing clues that might lead to the real perpetrator.

Think of a laptop infected with malware. A common SOC runbook procedure is to remove the threat by re-imaging the machine. Threat removed. MTTR low. But in addition to the threat being removed, all of the artifacts on that machine that would have helped a more skilled Tier 2 or Tier 3 analyst are also gone. Kind of like someone inadvertently destroying evidence at a crime scene—they have just made solving the crime that much more difficult.

To help understand this more deeply, let’s take a look at a common attack sequence, and how investigating malware on a laptop could provide the clues needed to help understand and respond.

Uncovering a Compromised Insider

Here’s our scenario. An attacker wants to steal the source code for a new product from the leader in the market. They’re going to compromise the machine of an engineer inside the company’s network and use that as a jumping off point to search the network and find code repositories with product software. We’ll use the ATT&CK framework to illustrate the tactics and techniques used by the attacker.

First, the attacker sets up a watering hole attack, knowing that an engineer at the target organization is likely to visit the website of an upcoming user conference. This falls under the ATT&CK technique T1189, aka a Drive-by Compromise (Initial Access). Once the engineer visits the website, the malicious code on the webpage is triggered and executed by the browser of the engineer’s machine. At this point, the attacker achieves code execution, aka User Execution, technique T1204 (Execution), to gain a foothold on the targeted machine.

After this initial execution, the attacker then covers their tracks by deleting a portion of the malware on the system through File Deletion (Defense Evasion), technique T1107, in an attempt to avoid detection. Think about what the attacker has achieved so far, and the effect of reimaging the machine. When a Tier 1 analyst wipes the machine, evidence of the Drive-by Compromise, User Execution, and File Deletion will be gone. You might even go so far as to say the analyst is helping the attacker by deleting all the evidence for them!

At this stage, the attacker controls the machine and looks to locate the sensitive data to steal. By using technique T1083, File and Directory Discovery, the attacker locates an SMB share that may contain the desired data (Discovery). As it turns out, the data the attacker is after requires privileged credentials, so the attacker escalates privileges by using the Pass the Hash technique (T1075) to gain access to a user account with administrator credentials (Lateral Movement). Now the attacker has proper privileges, they can access the file share and copy over the sensitive data.

In order to get this data out of the network, the attacker will gain access to a server in the DMZ. To accomplish this, the attacker uses a technique known as Access Token Manipulation T1134 (Privilege Escalation), by stealing a token from a login script that was run with a privileged domain account. Now that the attacker has the ability to access a server in the DMZ, the data can be copied to the server and compressed in preparation for transfer over the internet. The attacker then connects from the server in the DMZ to an attacker-controlled web server over port 818/TCP—this maps to technique T1048, Exfiltration Over Alternative Protocol. Table 1 below summarizes the multiple steps the attacker used to steal the source code.

In the sequence listed above, many of these tactics and techniques would have at some point set off alarms in most SOCs. But while the alerts may get investigated, too often the response by lower-tier analysts ends up incomplete and the attacker has already gained deeper access into the organization’s network and systems.

This point deserves emphasis. SOCs that focus on resolving individual incidents miss the bigger picture. Reimaging a system is just one example. As you can see, seven techniques were used by the attacker to accomplish their end goal. Security teams must change their mindset to start looking at entire attack sequences instead of individual steps.

Back to our example. After the attacker has gained additional credentials and starts to move laterally, that is the point that the trail goes dark for many security operations personnel, since it is very difficult to distinguish between activity driven by the real user of an account and an attacker using that account.

Using Behavior to Detect Complete Attack Chains

SOC teams need to be able to compare a user’s behavior to their normal patterns in order to understand if compromised credentials are being used by an attacker. A new technology known as User and Entity Behavior Analytics (UEBA) allows security analysts to do just that. UEBA products, such as Exabeam, do this by taking a thumbprint of what activities are normal for each user and then comparing that to activities the user performs in near real-time. Coupling that with tactics and techniques known to be risky from the MITRE ATT&CK framework, Exabeam then highlights the activity as being both atypical and risky. The more of these tactics and techniques that an attacker uses, the higher the risk score within Exabeam and the more this stands out to SOC analysts.

So, let’s look at how the Exabeam platform detects these techniques used in this example attack and how these techniques are called out through tags in the Exabeam interface.

As you recall, the attack began with a drive-by download to the target’s machine. Notice the “Rule Tags” section on the right side which shows the corresponding ATT&CK technique used. The arrows indicate risky behaviors identified by Exabeam’s UEBA technology and corresponding points added to the user’s risk score.

Figure 1: Drive-by Compromise technique shown in Exabeam Smart Timeline rule tags.

Next, the attacker executed code on the machine to gain a foothold.

Figure 2: User Execution attack technique shown in connection with barbarian.jar file at 14:21.

In order to hide evidence on the compromise, the attacker deleted the original malware from the machine.

Figure 3: The attacker attempted to evade defense by using the File Deletion Technique at 14:32.

Next, the attacker looks for the sensitive intellectual property to steal. These events are unusual because the user does not normally access these assets and Exabeam assigns risk points to this activity as a result.

Figure 4: The attacker shown searching for files using the File and Directory Discovery technique at 16:20.

Now the attacker finds that the sensitive data is on a share that the existing user account does not have access to, so the attacker pivots to an account that does have access.

Figure 5: The attacker moves laterally at 16:43 using the Pass the Hash technique.

The attack found the data the attacker was looking for, but now needs a way to move it out of the network. In this case, the attacker decides to gain access to a DMZ server to send data out of the network and blend in with normal traffic flowing in/out of the organization via a high traffic server. In order to achieve this objective, the attacker steals an access token from an elevated account, then uses these credentials to access the DMZ server and exfiltrate the stolen data.

Figure 6: The attacker escalates privileges using the Access Token Manipulation technique at 17:04

And for the ultimate step, the attacker transfers the source code for the new product.

Figure 7: The attacker is detected transferring product source code at 19:10 using the Exfiltration Over Alternative Protocol technique.

Putting these all together, Figure 8 below shows the attack in Exabeam’s Smart Timeline, which succinctly shows the attacker’s activities stitched together across various log sources and tied back into a single, easy-to-read timeline.

Figure 8: Exabeam Smart Timelines show the entire attack sequence, allowing response to the entire incident. The numbers denote the phase of the attack, as outlined in Table 1.

Gone are the days of so-called smash and grab attacks. Cybercrimes are now sophisticated sequences that take place over hours or days. Resolving the attack sequences requires SOC analysts to see the complete picture. By tying together the behaviors identified as anomalous and risky in Exabeam, with the techniques identified in the ATT&CK framework, responders can now trace the steps an attacker has used and where they may be heading next. Only once the attack chain is fully understood can the SOC analyst then take appropriate remediation steps to preserve evidence instead of re-imaging the system and possibly destroying key evidence needed to perform additional forensic examination of the compromised system.

To be successful, security analysts responsible for triaging events need to have the right tools to give them proper situational awareness to the activities of modern attacks, rather than relying on manual processes and disjointed alerts. Given the gravity of the compromises depicted here, every piece of evidence in this crime scene needs to be preserved for the duration of the investigation. Each incident needs to be seen as part of a bigger picture. Closing a ticket is not the same thing as solving a crime.

Editor’s Note: The screenshots above are from a forthcoming release of the Exabeam Security Management Platform.