Threat Hunting Thoughts: Basic Pivot Questions

Introduction

A critical component of Threat Hunting involves utilizing available Threat Intelligence to create hypotheses that can then be tested using available data. However, it has become increasingly common for security researchers to review Threat Intelligence, create rules that detect the exact activity described, and then test only those rules against their environments. The question, then, is what differentiates Threat Hunting from Detection Engineering (DE) in these situations? And how can security researchers move beyond DE to Threat Hunting when starting from Threat Intelligence specifically? This blog will address both questions with a greater focus on establishing foundational pivoting questions that security researchers can use to jumpstart their Threat Hunting processes.

The folks at Splunk have previously discussed the general differences between DE and Threat Hunting in their blog. Our primary distinction for the purposes of this blog is that DE works to identify known threats in as much of an automated way as possible while Threat Hunting seeks to identify unknown threats typically relying upon manual effort in the initial research stages. With that distinction clarified, the remainder of this blog will focus on how security researchers can use Threat Intelligence to generate hypotheses for Threat Hunting rather than just signatures for known activity.

?

Sample of Interest

For a concrete example, this blog will use indicators from early DarkGate reporting as a basis for pivoting from DE to Threat Hunting. More specifically, we will focus on malicious AutoIT usage and a few pivot questions we can use to find additional malicious activity even if that activity doesn’t directly relate to DarkGate. An excellent write up of a DarkGate sample was done by 0xToxin here and is worth reading for background information. We will also reference the behavior noted in VirusTotal for this sample as well for more context on process executions.

In the process tree section of the referenced example, we can see AutoIT execution occur in a few cases:

From a DE standpoint, we could write detections based upon AutoIT executing out of ProgramData or AppData\Local. Or even AutoIT executing a script out of ProgramData or AppData\Local. These are relatively straightforward detections and would likely require only basic tuning for a given environment before the false positive rates become acceptable.

?

Some Foundational Pivot Questions

With the DE portion complete, we can now turn to Threat Hunting research. Given that we are focused on process execution, we will limit our initial scope of questions to process execution related data and save questions related to file system changes and network activity for later. Below is a summary of three sample questions that we will cover in more detail shortly. The questions are presented in no particular order of importance.

1. Is it likely that an adversary will use a masqueraded version of the executing process?
2. Is the parent process of this activity consistent with legitimate executions of the process?
3. Are there additional binaries that have the same or similar functionality compared to the executing process?

These are clearly not exhaustive questions even when reviewing just process execution events, but they serve as consistent examples to review activity and start generating hypotheses for Threat Hunting. The main goal here is to try and predict future permutations of the same activity while also attempting to catch any similar techniques that might be used by other threat actors in their malware. Let’s look at each question individually now and see how they might lead to discovering other attacks.

?

Is it likely that an adversary will use a masqueraded version of the executing process?

If an adversary is using a well-known binary or perhaps even a Living Off the Land Binary (LOLBin) in their attack chain, then it is worth considering whether or not the adversary may resort to simple masquerades of the same binary in future attacks. In the case of AutoIT, we must consider if there is a legitimate reason to expect AutoIT to use different binary names in operations and, if so, how often that occurs on our systems or how easy it might be to exclude known good names from our queries.

As it turns out, a hunt for this exact technique resulted in the rapid detection of compromises that involved Handala wiper when they occurred sometime later. In those compromises, the threat actor manually concatenated multiple files together on a victim host to create an AutoIT3 executable under a false name that was then executed. You can review a more complete analysis of Handala here.

The snippet below also shows the same behavior with the assembling of an AutoIT file and eventual execution under the filename “Succeed[.]com”(sample). So, in addition to basic masquerading, you should also pay attention when file extensions are changed in filenames. A common mistake in Threat Hunting is to overly specify indicators like file extensions when the adversary has numerous ways to hide them or actually change them.

Is the parent process of this activity consistent with legitimate executions of the process?

Part of the Threat Hunting process often involves baselining the environment. The PEAK Threat Hunting Framework specifically mentions methods for approaching these types of hunts in greater detail, but starting with Threat Intelligence provides us with an easy way to focus on a specific process to baseline. In other words, Threat Intelligence can help us prioritize hunting efforts even when we’ve already started baselining an environment by helping us choose which aspects to baseline first given limited resources. Even more specifically for this example case, we can focus on which processes spawn our process of interest: AutoIT.

If AutoIT never executes in your environment, then a rather simplistic threat hunt is possible as any execution might be suspicious. However, if execution is fairly routine then the parent process becomes a good indicator for Threat Hunting. In our referenced DarkGate sample, we can see that MSIExec is the parent process for the malicious AutoIT executions. Again, DE might include MSIExec as a parent process to AutoIT as a specific indicator in a signature, but a threat hunter can broaden scope and look across all possible parent processes to see what might be abnormal even if existing Threat Intelligence doesn’t indicate widespread use of any other alternative parent process yet.

?

Are there additional binaries that have the same or similar functionality compared to the executing process?[T(1]nbsp;

The most common binaries that relate to this question are the LOLBins wscript and cscript. Both have extremely similar functionality and are often included interchangeably in many signatures. In our sample, we need to determine if any binaries have similar functionality to AutoIT and determine if the adversary might switch to that similar binary in the future to avoid initial signatures. In some cases, a simple internet search for “alternates” to a specific binary name will be sufficient to start the research process. If you are the type to test AI assistants, then you could also ask the AI to generate a list of binaries with similar functions to a target binary. ?A similar search and review of results regarding AutoIT reveals that AutoHotKey has similar functionality.

The exact differences between AutoIT and AutoHotKey are beyond the scope of this blog, but we now have a second binary to review. Keep in mind that we should apply the previous two questions to AutoHotkey as well and look for possible masquerades as well as conduct a baseline review for any executions on our systems. The inclusion of AutoHotKey in hunts proved to be pivotal as DarkGate eventually did switch to using it instead of AutoIT as described here.

Another example is shown below. The below example is also of interest because this particular chain shows execution of pwsh.exe (PowerShell) which is often overlooked in more simplistic signatures (i.e., some signatures still overly specify ‘powershell.exe’ and do not properly trigger on ‘pwsh.exe’ for the same activity).

While researching AutoHotKey you will likely also discover other attack chains that made use of the binary for malicious purposes. Those findings would also lead to additional Threat Hunting opportunities once completed with the current focus.

There are many more possible questions to pivot on when starting from Threat Intelligence, but to maintain a concise post we limited ourselves to just three for this blog and may explore more in the future that are just as common.

?

Data Limitations

We have discussed three basic pivot questions in this blog, but the types of questions you can meaningfully ask will depend upon the data available to you. In some cases, the questions might also depend upon publicly available samples, particularly in instances when Threat Intelligence itself lacks some technical details that you may need for Threat Hunting.

Remember that Threat Hunting is meant to feed back into other processes in the security environment. Any data shortcomings should be documented and discussed with the person or team in charge of data collection for possible resolution. Any new findings should be shared with your team as well and potentially shared publicly when appropriate so that Threat Intelligence can also begin their processes for handling and sharing new information with the community.

?

Closing Remarks

This blog very briefly covered the difference between Detection Engineering and Threat Hunting before providing three basic pivot questions that researchers can ask when reviewing Threat Intelligence that involves process execution data. ?We provided examples of how those questions helped successfully capture changes in attack chains as well as catch completely unrelated malware in some cases. Clearly there are far more foundational questions in Threat Hunting, but this blog sought to be a bit more manageable. It is possible that this could become a min-series in the future, but, for now, the hope is that this was helpful to newer Threat Hunters or those looking to jump into the community.