Driving threat hunting with cyber intelligence
In the previous article of the series, we discussed how indicators of compromise help detect threats. Now, let us shift our focus to threat hunting and examine how to uncover attacks that evade automated security solutions.
Before we dive in, we need to address a fundamental question: Is threat hunting truly proactive? In his video Threat Intelligence is a Fallacy, but I May be Biased, Andy Piazza argues that it is not.
At first glance, that makes sense. Threat hunting often relies on known tactics, techniques, and procedures (TTPs)—in other words, it is driven by intelligence about previously observed threats. However, from the standpoint of security solutions, the answer is less straightforward. The modern threat landscape comprises a wide range of methods that can stay under an organization’s radar, either through sophisticated obfuscation or by abusing legitimate tools and services.
Approaches
One of the most widely recognized threat hunting models today is the PEAK Threat Hunting Framework.
It defines three primary approaches:
- Hypothesis‑driven hunting. Relies on knowledge of attacker methods and tools (threat intelligence) to formulate threat hunting hypotheses.
- Anomaly‑based hunting. Rather than focusing on TTPs, identifies atypical system behavior within the IT environment, such as unusual network connections, unexpected file creation, registry modifications, suspicious process execution, etc.
- Model‑based hunting. Automates the previous two through technologies like machine learning (ML) and artificial intelligence (AI).
Huntable attack life cycle stages
Threat hunting can be applied to nearly every stage of the attack life cycle, except for the disruptive impact on the IT infrastructure. By the time adversaries reach this stage, the opportunity for proactive detection has already passed.
The following stages are particularly well suited to threat hunting:
- Execution. Involves various command interpreters, scripts, malicious files, attacker‑controlled legitimate tools, etc. At this point, threat actors are often not yet taking overt steps to advance, reducing the likelihood that their malware or tools will be detected.
- Persistence. Often closely tied to the execution stage. Threat actors typically rely on the same mechanisms as legitimate software, including startup utilities, task schedulers, and other services. If malware or attacker‑controlled tools stay undetected, these persistence methods allow adversaries to maintain covert, long‑term access to the environment.
- Lateral movement. Presents numerous opportunities for threat hunting because attackers often rely on legitimate remote access services that rarely trigger security solutions.
- Exfiltration. Occurs in the vast majority of attacks, regardless of actor motivations. Although it typically takes place during the later stages of an intrusion, it remains an important focus for threat hunting. In some cases, it may be one of the few stages where suspicious activity is visible, particularly when adversaries gain access using legitimate credentials.
Hunting in practice
Before exploring specific hypotheses, it is important to understand what makes threat hunting different from detection logic development.
When creating rules based on such logic, the goal is to minimize false positives. Here, we are talking about events—or sequences of events—that reliably indicate malicious or potentially malicious activity.
Threat hunting, however, follows a different approach. Search queries are designed to return a broad set of events, some of which may ultimately prove benign. The objective is to uncover activity that, for one reason or another, has evaded security solutions and content‑based detection.
Let us look at a few examples to see how threat intelligence is applied to threat hunting in practice.
In one of its campaigns, Silent Werewolf used MSBuild.exe to compile and execute C# code.
Based on this observation, we can formulate the following hypothesis: The attacker abuses MSBuild.exe to execute malicious files from suspicious directories.
It can then be translated into the following search query:
event_type: “processcreatewin” AND proc_file_path: “msbuild.exe” AND NOT cmdline: [exclusions]
Since MSBuild.exe is a legitimate utility, such events should be identified and added to the exclusion list, refining the query for future use.
Lenient Wolf employed wget to load archives containing malicious tools to compromised systems.
For this case, we can formulate the following hypothesis: The adversary uses wget to load tools from a C2 server.
The search query will be similar to the previous example:
event_type: “processcreatenix” AND proc_file_path: “wget” AND NOT cmdline: [exclusions]
As in the Silent Werewolf case, the first step is to build a list of exclusions. In most IT environments, wget is used way more often than MSBuild.exe, and individual executions are unlikely to trigger alerts in security solutions. This makes wget a perfect target for threat hunting.
To gain persistence, Fairy Wolf—like many other threat actors—uses jobs created in Windows Task Scheduler.
The hypothesis here is as follows: The attacker creates jobs in Windows Task Scheduler to gain a foothold in a compromised system.
When building the search query, it is helpful to incorporate parameters employed by adversaries to narrow down the results, since schtasks.exe is a commonly used executable:
event_type: “processcreatewin” AND proc_file_path: “schtasks.exe” AND cmdline: (“mo” AND “60”)
Although this query includes an attacker‑specific parameter, it may still return some false positives. This is entirely consistent with the principles of threat hunting.
Threat actors often need to determine the location of a compromised system. For instance, Cavalry Werewolf used IPinfo for this purpose.
The hypothesis here is as follows: The adversary uses ipinfo[.]io to determine the location of a compromised system.
In this case, we can limit the query to suspicious network communication with the service:
event_type: “dnsreqwin” AND dns_rname: “ipinfo.io” AND NOT proc_file_path: [exclusions]
The next step is to identify which processes are accessing ipinfo[.]io. Legitimate use cases can then be added to the exclusion list for future searches.
The final example focuses on network communications, specifically those involving a C2 server. For instance, Rainbow Hyena employed .space domains (TLD) like msnetsec[.]space.
The formulated hypothesis is as follows: The attacker uses .space domains for C2 communications.
The query will look as follows:
event_type: “dnsreqwin” AND dns_rname: *.space AND NOT dns_rname: [exclusions]
Because legitimate web resources rarely use the .space TLD, the query is likely to generate relatively few benign results.
Evaluation
When evaluating the effectiveness of threat hunting, it is important not to focus solely on identified incidents. While it can uncover events that have evaded existing security controls, its value extends far beyond detection.
More often, threat hunting enables organizations to:
- Create new detection rules or refine existing ones.
- Gain a deeper understanding of their IT environment, making anomalous behavior easier to uncover.
- Identify telemetry gaps and infrastructure misconfigurations.
Threat hunting enables early detection of malicious activity, including attacks that evade existing security solutions. Threat intelligence provides the foundation for hypotheses and helps organizations keep pace with the evolving threat landscape. The BI.ZONE Threat Intelligence portal provides ready‑to‑use threat hunting recommendations, enabling security teams to begin hunting without first having to manually analyze attacker TTPs.
Beyond uncovering hidden threats, this practice also helps identify flaws in detection rules, telemetry, and IT infrastructure configurations.
In the next article of our series, we will discuss how to use threat intelligence to test security solutions and conduct cyber exercises.