A good threat hunting hypothesis is key to identifying weak spots in an organization’s digital infrastructure. Just learn to ask the right questions, and you will get the answers that you’re looking for. In this blog post, we review a proactive threat hunting methodology: Hypothesis-Driven Threat Hunting. Let’s dive right in!
Detect & Hunt Explore Threat Context
A threat hunting hypothesis is an informed assumption about a cyber-attack or any of its components. Just like in scientific research, in hypothesis-driven threat hunting, Threat Hunters make hypotheses the foundation of their investigations.
Once a hypothesis is made, a Threat Hunter must take steps to test it. It is in the strategy for testing the hypothesis that most of the threat hunting work is completed (e.g., forming a useful query often takes longer than its execution). This often includes identifying related data sources (security events, system logs, etc.), relevant analysis techniques (querying, stack counting, etc.), and then taking action on this strategy.
Threat hunting hypothesis facilitates a proactive cyber defense routine. One of the many variants of the latter consists of:
Overall, the success of threat hunting greatly depends on an insightful hypothesis, so let’s see how to make one.
To make it easier at the beginning, you can think of threat hunting hypotheses as kind of user stories but from malware’s perspective.
- As a [malicious script], I want to [send a request via TCP port 50050] so I can [establish connection].
- As an [infected zip], I want to [use WMI] so I can [maintain persistence].
Alternatively, let’s make a hypothesis from an attacker’s perspective.
As an APT37 (North Korea), I want to attack the US government for political reasons, so I’ll use Cobalt Strike in T1218.011, planting rundll32 for proxy execution of malicious code.
However, there is no single template of a “right” format for a threat hunting hypothesis. For example, they can also be more complex than just one sentence. For malware that executes a multi-stage kill chain, a threat hunting hypothesis might also include a few points.
Executes a command via EXE file
Imports and executes PowerShell cmdlets from an external source
Runs a local .NET binary
Uses setenv() function to add the variable to the environment
Now let’s move on to more complex examples.
Threat hunting hypotheses can be operational, like the examples above, or tactical and strategic. Seasoned Threat Hunters can formulate broader hypotheses that can nevertheless result in finely targeted tests. To do that, they need to include:
Apply all of the above to formulate a deeply analytical hypothesis about what systems attackers will target and what they will try to achieve.
For example, a Threat Hunter Bob has been researching some IOCs obtained through a threat intel feed. Having done a Crown Jewels Analysis (CJA), he knows that their company’s jewel in the crown is the place where they store proprietary algorithms. His experience with previous hunts and a talk with a fellow researcher Alice allow suggesting the most likely adversary behavior in a given situation. So he formulates a hypothesis.
Attackers that tried to gain initial access through a phishing email will do lateral movement and privilege escalation to get to the heart of the system and exfiltrate data.
Hypotheses can also be targeted not at predicting the future steps of the attackers but at understanding patterns, dependencies, and so on. In other words, seeing the whole picture.
Where do they have their C2 servers? How do they obfuscate them? How do they maintain persistence? What’s the relationship between specific servers and various attack campaigns?
In this case, cybersecurity is not just about seeing issues and quickly remediating them. It’s also necessary to ask questions. A bit like investigative journalism with its 5W rule:
Because often the situation is like this. There are multiple events in multiple places. Millions of scripts, scheduled tasks, files, and user actions. They all do something. Those various events might be stages of a kill chain. But you don’t know that because a malware piece encrypted itself and hid somewhere in a legitimate file. It also stole certificates, so it executes as part of the reputable software that the company bought. You might’ve taken care of IOCs, but it was not enough. The company might be spied on, but there’s no hard evidence of that. So on the surface, nothing catastrophic happened. A hypothesis will help to identify such a sophisticated attack or prove an absence of it.
A state-sponsored threat actor A uses the same C2 servers as threat actor B, so they might be part of the same botnet. They use a software pipeline infection and plant malware with a 1-2 weeks dormant period before triggering reconnaissance which lasts 2-6 months. If our scan shows obfuscated data inside legitimate binaries, we should look for signs of establishing a connection with a C2 server so we can conclude that those files are malware.
Practice makes perfect, so don’t worry if things like threat reports and raw data look a little gibberish to you at the start. Learn computer science subjects like networks, low-level languages, and application architecture to feel more comfortable with specific terms and numeric values (like port numbers, etc.) Anyway, there’s always lots of information to deal with – don’t feel discouraged if you don’t understand everything you come across. It’s barely possible to know it all, so using Google sometimes helps a lot, too.
A good threat hunting hypothesis allows one to arrive at valuable conclusions and prevent possible attacks. Moreover, it helps Threat Hunters to examine the right data at the right time instead of having to search through millions of logs for millions of likely reasons. Join our Detection as Code platform to gain access to near real-time detection algorithms compatible with 25+ SIEM, EDR, and XDR solutions and instantly search for the latest threats in your environment.