Modern security operations are under pressure. Attackers dwell inside enterprise networks for an average of weeks or months before they are discovered, and automated detection tools alone are not closing that gap. Cyber threat hunting exists to address exactly this problem: it is the proactive, human-led practice of searching through networks, endpoints, and data to find adversaries who have already bypassed your controls and are operating silently inside your environment.
This post breaks down what threat hunting actually involves at a technical level, how it is structured as a repeatable workflow, which tools practitioners rely on, and why it is fundamentally different from the detection capabilities most organizations already have in place.
Threat hunting is the practice of iteratively and proactively searching for indicators of compromise, attacker behaviors, and anomalous activity that automated systems have not flagged. The key word is proactive. A threat hunter does not wait for an alert. Instead, they begin with a hypothesis rooted in threat intelligence, adversary knowledge, or observed environmental anomalies, and then go looking for evidence that the hypothesis is correct.
The SANS Institute and MITRE ATT&CK framework are the two most important reference points for structuring this work. ATT&CK in particular gives hunters a shared vocabulary for adversary tactics, techniques, and procedures (TTPs), allowing hunts to be built around specific attacker behaviors rather than signatures or known-bad indicators alone.
Threat hunting is not a product. It is not a feature you turn on in your SIEM. It is a discipline that requires skilled analysts, structured methodology, good data, and the right tooling.
This distinction matters because organizations frequently conflate the two, leading to gaps in coverage they are not aware of.
Threat detection is reactive and automated. It is the process by which your security tools, SIEM rules, EDR heuristics, and network monitoring platforms generate alerts when observed activity matches a known pattern, signature, or behavioral baseline. Detection depends on something being known or at least modeled in advance.
Threat hunting is proactive and human-led. It begins before an alert is generated. Hunters operate on the assumption that an attacker may already be present and that existing detection logic has not caught them. The outputs of a hunt are either confirmed findings or improvements to detection logic, closing the gap for the next iteration.
The relationship is complementary rather than competitive. A mature security program needs both. If your team only reacts to alerts, you are permanently at least one step behind adversaries who specifically design their tradecraft to avoid triggering those alerts. If you want to assess where your organization currently sits in that maturity curve, the security services offered at Redfox Cybersecurity include adversary simulation and detection gap analysis that can inform where hunting efforts should begin.
Living-off-the-land (LotL) techniques illustrate the detection gap clearly. An attacker using native Windows binaries like certutil.exe, wmic.exe, or mshta.exe to move laterally, download payloads, or execute code will often evade signature-based detection entirely. The binaries are legitimate. The process is trusted. Only behavioral context, looked at across time and across multiple data sources, reveals the abuse.
Threat hunters find these patterns. Automated tools frequently do not.
Effective threat hunting follows a structured cycle. Ad hoc exploration without a framework produces inconsistent results and makes it nearly impossible to improve over time.
Every hunt starts with a hypothesis. Hypotheses come from several sources:
A well-formed hypothesis is specific and falsifiable. "Attackers may be using scheduled tasks for persistence" is a workable hypothesis. "Something bad might be happening" is not.
The quality of a hunt is bounded by the quality of available telemetry. At minimum, hunters need:
Sysmon is one of the most important free tools for enriching Windows endpoint telemetry. A well-tuned Sysmon configuration captures exactly the events that matter most for hunting: process creation with full command lines (Event ID 1), network connections (Event ID 3), driver loads (Event ID 6), and file creation timestamps (Event ID 11).
With a hypothesis and data in hand, the hunter begins analysis. This is where tooling matters most, and where the difference between a productive hunt and a dead end is often decided.
Every confirmed or suspected finding gets documented. Unconfirmed findings that were ruled out also get documented, because they inform future hunts and help tune out false positives. The terminal output of any hunt should be either a confirmed incident handed off to IR or a new detection rule added to the SIEM, EDR, or both.
Map your hypothesis to a specific ATT&CK technique. For example, if you are hunting for T1059.001 (PowerShell execution), you might query your endpoint logs for:
-EncodedCommand or -enc flag)# Hunting for encoded PowerShell via Sysmon Event ID 1 in Splunk
index=sysmon EventCode=1
| search CommandLine="*-enc*" OR CommandLine="*-EncodedCommand*"
| table _time, Computer, User, ParentImage, CommandLine
| sort -_time
[cta]
Stack counting is one of the most powerful and underutilized techniques in a hunter's toolkit. The idea is simple: count how often a particular value appears across your environment. Rare values deserve attention. Attackers trying to blend in often succeed against signature detection but fail against statistical rarity analysis.
For example, count all parent-child process relationships across your fleet. A process like svchost.exe spawning cmd.exe is rare and worth investigating. explorer.exe spawning chrome.exe thousands of times is normal.
# Stack counting parent-child process pairs with Python + pandas
import pandas as pd
df = pd.read_csv("process_events.csv") # columns: timestamp, hostname, parent_image, image
pair_counts = df.groupby(["parent_image", "image"]).size().reset_index(name="count")
rare_pairs = pair_counts[pair_counts["count"] < 5].sort_values("count")
print(rare_pairs.to_string(index=False))
[cta]
Credential access is one of the most targeted phases of the attack lifecycle. Hunters looking for T1003 (OS Credential Dumping) should look for LSASS access patterns from non-standard processes, which is a strong indicator of tools like Mimikatz or similar credential extraction utilities.
# Querying Windows Security Event Log for LSASS access (Event ID 4656)
# Cross-reference with Sysmon Event ID 10 (ProcessAccess)
Get-WinEvent -LogName Security -FilterXPath `
"*[System[EventID=4656] and EventData[Data[@Name='ObjectName'] and Data='C:\Windows\System32\lsass.exe']]" |
Select-Object TimeCreated, Message | Format-List
[cta]
This is exactly the kind of hunt that complements penetration testing. If your red team has already demonstrated they can dump credentials undetected, the hunter's job is to find the telemetry trail and build detection logic around it. Redfox Cybersecurity's adversary simulation services are designed to produce exactly that kind of actionable output for your blue team.
Command and control (C2) communication is often hidden inside seemingly normal DNS traffic. Hunters look for:
# Hunting for high-entropy DNS domains using zeek + python
# Zeek dns.log parsed to identify potentially DGA-generated domains
python3 - << 'EOF'
import math
import csv
def entropy(s):
prob = [float(s.count(c)) / len(s) for c in set(s)]
return -sum([p * math.log(p, 2) for p in prob])
with open("dns.log") as f:
reader = csv.DictReader(f, delimiter="\t")
for row in reader:
query = row.get("query", "")
if query and entropy(query) > 3.5:
print(f"{row['ts']}\t{query}\t{entropy(query):.2f}")
EOF
[cta]
Lateral movement leaves footprints in authentication data. Event ID 4624 (successful logon) with Logon Type 3 (network logon) appearing across multiple hosts from a single source account in a short time window is a classic indicator worth hunting.
# Splunk query: detecting rapid lateral movement across multiple hosts
index=wineventlog EventCode=4624 Logon_Type=3
| stats dc(ComputerName) as unique_hosts, values(ComputerName) as hosts by Account_Name, _time span=30m
| where unique_hosts > 5
| sort -unique_hosts
[cta]
Velociraptor is an open source endpoint visibility and DFIR platform that is purpose-built for threat hunting at scale. It uses a query language called VQL (Velociraptor Query Language) to run hunts across hundreds or thousands of endpoints simultaneously.
-- VQL: Hunt for scheduled tasks created in the last 7 days across all endpoints
SELECT Hostname, Name, Command, CreationTime
FROM hunt_results(artifact="Windows.System.ScheduledTasks")
WHERE CreationTime > now() - 7 * 24 * 3600
ORDER BY CreationTime DESC
[cta]
Velociraptor's ability to collect artifacts, run remote queries, and triage endpoints without deploying heavyweight agents makes it one of the most operationally flexible tools available to threat hunters today.
SIGMA is a generic signature format for SIEM systems, allowing hunters to write detection logic once and convert it to queries for Splunk, Elastic, Azure Sentinel, and others. Hayabusa is a fast Windows event log analysis tool that applies SIGMA rules locally against collected logs.
# Running Hayabusa against a collected Windows event log directory
./hayabusa-2.x.x-linux-x64 csv-timeline \
--directory /mnt/evidence/evtx/ \
--rules ./sigma/rules/ \
--output hunt_timeline.csv \
--min-level medium \
--no-wizard
[cta]
This combination is particularly powerful during incident response scoping or when hunting across collected logs from an environment you do not have live access to.
The Elastic Stack, specifically Elasticsearch, Logstash, Kibana, and the Elastic Agent, is a common platform for centralizing the telemetry that hunts depend on. Elastic's EQL (Event Query Language) is purpose-built for expressing temporal sequences of events, which is critical for hunting attack chains rather than individual events.
/* EQL: Detect PowerShell spawned by Office applications followed by a network connection */
sequence by host.name, process.entity_id [maxspan=2m]
[process where process.name == "powershell.exe"
and process.parent.name in ("winword.exe", "excel.exe", "outlook.exe")]
[network where process.name == "powershell.exe"
and not cidrmatch(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")]
[cta]
EQL sequences allow hunters to describe multi-stage behaviors with timing constraints, which is something traditional SIEM queries handle poorly. This is one of the reasons organizations building mature hunting programs often gravitate toward Elastic as a core platform.
Zeek is a powerful network analysis framework that transforms raw packet captures into structured logs covering DNS, HTTP, SSL, SMTP, and dozens of other protocols. For hunters without full packet capture infrastructure, Zeek provides the next best thing: rich, queryable network metadata.
# Hunting for SSL certificates with unusual subject fields using Zeek ssl.log
cat ssl.log | zeek-cut ts uid id.orig_h id.resp_h server_name subject |
awk '$6 ~ /[0-9]{5,}/ || length($5) < 4' |
sort -k1,1 | head -50
[cta]
Network-level hunting with Zeek is particularly valuable when you are hunting for C2 infrastructure, data exfiltration, or protocol abuse that endpoint telemetry alone would not surface.
ATT&CK Navigator is a browser-based tool for annotating and planning coverage across the ATT&CK matrix. Before beginning a hunting program, mapping your current detection coverage against the full ATT&CK matrix makes it immediately clear where your gaps are. Those gaps become your first hunting priorities.
This planning step is often where organizations benefit from external expertise. If you want a structured assessment of your detection and hunting maturity, the team at Redfox Cybersecurity can provide a coverage mapping exercise tied directly to the threats most relevant to your industry and infrastructure.
A single hunt is valuable. A program built around repeatable hunts, shared documentation, and continuous detection improvement is transformative. The key elements of a mature hunting program include:
Hunt libraries: Documented hypotheses, queries, and findings organized by ATT&CK technique so that hunts can be reused, refined, and shared across the team.
Feedback loops: Every hunt should produce either a confirmed finding or an improvement to detection logic. If a hunt repeatedly produces nothing, either the hypothesis was wrong, the telemetry is insufficient, or the detection is already solid enough to catch that behavior automatically.
Metrics: Track the number of hunts conducted per quarter, the number of new detections created as a result of hunting, and mean time to detection improvement. These metrics demonstrate the value of the program to leadership and identify where investment is needed.
Threat intelligence integration: Hunting hypotheses should be informed by current threat intelligence. Subscription to threat intel platforms like Recorded Future, Mandiant Advantage, or even open-source feeds like MISP enables hunters to focus on the adversaries most likely to target your organization.
Cyber threat hunting is not a feature or a checkbox. It is a structured, human-led discipline that finds what automated detection misses. The most capable adversaries specifically design their tradecraft to blend into normal activity, and the only reliable way to find them is to go looking before they achieve their objectives.
The technical foundation of an effective hunting program is solid telemetry, structured methodology built around frameworks like ATT&CK, and tools such as Velociraptor, Elastic Stack, Zeek, and Hayabusa that give hunters the visibility and query power they need to test hypotheses at scale.
For organizations that are building or maturing their security operations capability, threat hunting is one of the highest-leverage investments available. It closes detection gaps, surfaces attacker tradecraft your tools cannot see, and forces continuous improvement in your defensive posture.
If your organization is ready to move beyond reactive detection and build a proactive security capability, the team at Redfox Cybersecurity works with security programs at every stage of maturity to design hunting workflows, close coverage gaps, and operationalize the kind of continuous adversary simulation that keeps detection logic current.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
