Human Behavior In Digital Forensics, pt III

So far, parts I and II of this series have been published, and at this point, there's something that we really haven't talked about.

That is, the "So, what?". Who cares? What are the benefits of understanding human behavior rendered via digital forensics? Why does it even matter?

Digital forensics can provide us insight into a threat actor's sophistication and situational awareness, which can, in turn, help us understand their intent. Are they new to the environment, and trying to get the "lay of the land", or are their actions extremely efficient, and do they appear to be going directly to the data they're looking for, as if they have been here before or had detailed prior knowledge?

Observing the threat actor's actions (or the impacts thereof) helps us understand not just their intent, but what else we should be looking for. For example, observing the Samas ransomware threat actors in 2016 revealed no apparent interest in data collection or theft; there was no searching or discovery, no data staging, etc. This is in contrast to the Non-PCI Case from my previous blog post; the threat actor was apparently interested in data, but did not appear to have an understanding of the infrastructure they'd accessed (searching for "banking" in a healthcare environment).

Carrying this forward, we can then use what we learn about the threat actor, by observing their actions and impacts, to better understand our own control efficacy; what worked, what didn't, and what can work better at preventing, or detection and responding to, the threat actor?

Per the graphic to the left, understanding human behavior rendered via digital forensics is thought to provide insight into future attacks...but can it really? And if this is the case, how so?

Well, we've known for some time that there's really no single actor or group that focuses solely on one type of target. Consider this blog post from 2015, making it almost 9 yrs old at the time of this writing. The findings presented in the blog post remain true, and are repeated, even today. 

So, "profiling" a threat actor may not allow you to anticipate who (what target infrastructure) they're going to attack next, but within a limited window, it will provide a great deal of insight into how you can expect them to conduct the follow-on stages of an attack. The target may not be known, but the actions taken, particularly in the near term, will be illuminated by what was observed on a previous attack.

In 2016, the team I was with responded to about half a dozen Samas ransomware attacks, across a wide range of verticals; they were targeting vulnerable JBoss CMS systems, regardless of the underlying business. What we learned by looking across those multiple attacks allowed us to identify other potential targets, as well as respond to and shut down some attacks that were underway; we saw that the threat actors took an average of 4 months to go from initial access to deploying the ransomware. During this time, there was no apparent interest in data staging or theft; the intent appeared to be to identify "critical" systems within the infrastructure, and obtain the necessary privileges to deploy ransomware to those systems.

Reacting to Stimulus

Additional insight can be found by observing how a threat actor reacts to "stimulus". There may be times when a threat actor's activities are unfettered; they proceed about their actions without being inhibited or blocked in anyway. They aren't blocked by EDR tools, nor AV. From these incidents, we can learn a good deal about the threat actor's playbook, and we may see how it evolves over time. However, there may be times where the threat actor encounters issues, either with security tooling blocking their efforts, or tools they bring in from the outside crashing and not executing on the endpoint. It's during these incidents that we get a more expansive view of the threat actor, as we observe their actions in response to stimulus.

While I was with Crowdstrike, we'd regularly "see", via the EDR telemetry, the actions taken by various threat actors when the Crowdstrike product blocked their processes from executing. In one instance, the Crowdstrike agent stopped the threat actor's process, and their reaction was to attempt to disable and remove Windows Defender. They then moved to another endpoint, and when they encountered the same issue, they attempted to remove an AV product that was not installed anywhere within the infrastructure. They finally moved to a third endpoint, and when their attempts continued to be blocked, they ran a batch file intended to remove several AV products, none of which were installed on the endpoint. Interestingly, they left the infrastructure without ever running a command to see what processes were running, nor what applications were installed.

We saw threat actors on endpoints monitored by the Crowdstrike agent doing queries to see if Carbon Black was installed. To be clear, the commands were not general, "...give me a list of processes..." commands, but were specific to identifying Carbon Black.

In another instance, we observed the threat actor land on a monitored endpoint, and begin querying other endpoints within the infrastructure to see if they were running the Falcon agent. They reached out to 15 endpoints, and while we could not see the responses, we knew from our dashboard that the agent was only on 4 of the queried endpoints. The threat actor then moved to one of the endpoints that did not have an agent installed. The interesting thing about this was that when they landed on the monitored endpoint, we saw no commands run nor any other indication of the threat actor checking that endpoint for the agent; it was as if they already knew. 

Even without EDR or AV blocking the threat actor's attempts, we may still be able to observe how the threat actor responds to stimulus. I've seen more than a few times where a threat actor will attempt to run something, and Windows Error Reporting kicks off because their EXE crashes. What do they do? I've seen ransomware threat actors unable to encrypt files on an endpoint, and running their tool with the "--debug" command switch, multiple times. They may also attempt to download newer or different copies of their tools, and try running them again. 

In other instances, I've seen commands fail, and the threat actor try something else. I've also seen tools crash, and the threat actor take no action. Seeing how a threat actor responds to the issues they encounter, watching their behavior and whether they encounter any issues, provides significant insight into their intent.

Other Aspects of the Attack

There are other aspects of an attack that we can look to to better understand the threat actor. For example, when the threat actor initially accesses an endpoint, how do they do so? RDP? MSSQL? Some other application, like TeamViewer?

Is the access preceded by failed login attempts, or does the source IP address for the threat actors successful access to the system not appear on the list of IP addresses for failed login attempts?

Once they have access, what do they do, how soon/fast do they do it, and how do they go about their activities? If they access the endpoint via RDP, do they use all GUI tools, do they go to PowerShell, do they use cmd.exe, etc.? Do they use WSL, if it's installed? Do they use native utilities/LOLBins? Do they use batch files? 

Did they create any additional persistence? If so, what do they do? Create user accounts? Add services or Scheduled Tasks? Do they lay any "booby traps", akin to the Targeted Threat Actor from my previous blog post?

During their time on the endpoint, do they seem prepared, or do they "muck about", as if they're wandering around a dark room, getting the lay of the land? Do they make mistakes, and if so, how do they overcome them? 

Do they use LOLBins? Do they bring tools with them, and if so, are the tools readily available? When the Samas ransomware actors were attacking JBoss CMS systems in 2016, they used the JexBoss exploit, which was readily available. 

When they disconnect their access, how do they go about it? Do they simply break the connection and log out, or do they "salt the earth", clearing Windows Event Logs, deleting files, etc.?

An important caveat to these aspects is we have to be very careful about how we view and understand the actions we observe. There have been more than a few times where I've worked with analysts with red team experience, and have heard them say, "...if I were the attacker, I would have...". This sort of bias can be detrimental to understanding what's actually going on, and can lead to resources being deployed in the wrong direction. 

Conclusion
As Blade stated during the first movie (quote 3), "...when you understand the nature of thing, you know what it's capable of." Understanding a threat actor's nature provides insight into what they're capable of, and what we should be looking for on endpoints and within the infrastructure.

This also helps us understand control efficacy; what controls did we have in place for prevention, detection, and response? Did they work, or did they fail? How could those controls be improved, or better implemented?