Threat Hunting, Operationalized: Why Proactive Detection Matters — and How to Scale It

Threat Hunting

What is threat hunting?

Most security operations are built to react to an intruder. An EDR agent flags a suspicious process, a SIEM correlation rule fires, an analyst triages the alert — the entire model assumes the attacker will eventually exploit a honeypot. Threat hunting starts from a different premise: assume some of them won’t. Instead of waiting for an alert, a hunter forms a hypothesis — “if a specific adversary or technique were active in this environment, what evidence would it leave behind?” — and looks for the evidence across live endpoint telemetry, registry state, process history, and network activity. It’s proactive rather than reactive, and it’s built to catch the behavior that’s meant to blend in: living-off-the-land binaries, credential theft via legitimate admin tools, encoded PowerShell that looks like routine automation.

How is this related to how attackers think?

Nation-state groups and organized ransomware crews cannot rely on known malware or their signatures— they use what’s in the system like built-in Windows tooling, valid stolen credentials, and techniques deliberately chosen to sit below alerting thresholds. The longer that activity goes undetected, the more an attacker can achieve: lateral movement into more systems, credential compromise that outlives any single incident response, and ransomware deployment or data exfiltration before anyone notices a problem. This isn’t only a SOC-analyst concern. It’s a CISO concern (risk exposure and breach cost), a compliance concern ( industries expect evidence of proactive detection capability, not just passive monitoring), and a board-level concern, as breach disclosure and incident cost add to enterprise risks.

The problem is that threat hunting has historically been expensive to scale. It depends on a small number of experienced analysts who know the MITRE ATT&CK framework cold, can translate “APT29 might be here” into a dozen concrete, technically correct queries against live endpoint data, and can turn a pile of raw findings into something a CISO can actually act on. That expertise doesn’t doesn’t scale linearly and is on analysts to learn quickly, but a company cannot wait for people to become experienced in this.

That’s the gap this project is built to close. The Threat Hunt Platform takes the threat-hunting workflow — map evidence to ATT&CK techniques, generate hypothesis-driven queries for a given adversary, execute them against Velociraptor (an open-source endpoint visibility platform), score the results, and report on them — and turns each step into something repeatable rather than tribal knowledge. A retrieval system maps raw findings to the specific ATT&CK techniques they represent. A library of production-ready VQL hunt queries contains the hypotheses analysts return to again and again — persistence, lateral movement, credential access, exfiltration — so nobody starts from a blank query editor. Given a named threat actor, the platform pulls that group’s documented techniques and either reuses existing coverage or drafts new queries in the same style. Findings get rolled up into an auditable per-endpoint risk score. And the whole cycle ends in an ATT&CK heatmap and an executive-ready report, so the output of a hunt isn’t just an alert to a SOC analyst— it’s something that closes the loop back to leadership.

The value to a company isn’t abstract. It’s fewer days of undetected time in a system, a junior analyst who can run a credible hunt on day one instead of year three, hunt coverage that’s documented and improves over time instead of evaporating when someone leaves the team, and reporting that doesn’t require a separate week of PowerPoint-building after every hunt cycle. Threat hunting starts being something any organization with endpoint visibility can actually run.

---

Threat Hunt Platform - 5 capabilities

Github repo - https://github.com/cybersecbella/threat-hunting-platform.git

(1) ATT&CK RAG — vector store of all ATT&CK techniques — ‘Given these Velociraptor findings, which TTPs are active?’

TTP stands for Tactics, Techniques, and Procedures — MITRE’s ATT&CK framework categorizes adversary behavior at three levels

tactic is the “why” — the adversary’s immediate goal (ex. persistence or credential access)

technique is the “how” — a specific method for achieving that goal (abusing Registry Run keys – technique T1547.001)

Procedure – specific real-world implementation of an attack

Threat hunting platform returns: “T1003.001 LSASS Memory, tactic: credential-access,“
What it means? finding shows an adversary pursuing the credential-access goal, specifically via the LSASS-memory-dumping technique — extract auth secrets, NTLM password hashes, and Kerberos tickets from the Local Security Authority Subsystem Service (lsass.exe)

(2) VQL library — 29 production-ready VQL hunt queries across persistence, lateral movement, exfil, discovery, execution, credential access, C2, and impact

Velociraptor is an DFIR (digital forensics/incident response) tool.

How it works? A small agent gets deployed to every endpoint in your fleet, and from a central server you can ask all of them questions at once: show me every running process, list every registry Run key, search this directory for files modified in the last hour…

A threat hunting platform should have a fleet-wide capability which is why velociraptor is the natural backend for this hunting platform.

VQL (Velociraptor Query Language) is the language you use to ask these questions. It’s similar to SQL— SELECT … FROM … WHERE … — but the FROM clause pulls from live endpoint states instead of a database table. It has the information of process lists, registry keys, event logs, the filesystem, and network connections.

Examples in the repo: every query in vql_library/library.yaml

The persistence hunt selects registry Run-key entries and filters for ones pointing at suspicious binaries like PowerShell or files sitting in a Temp folder.

After running the VQL query against the fleet, a velociraptor finding is returned.

It’s a concrete piece of evidence tied to a specific host — “on WKS-EXEC-005, regsvr32.exe was executed with a remote .sct URL” is a finding.

(3) Hunt generator — generate-hunt —actor APT29 (also Lazarus, APT41, FIN7, Sandworm) pulls known TTPs, matches library coverage, and drafts new VQL for gaps

hunt hypothesis = proactive threat hunting

Instead of waiting for an alert, analysts can start from an assumption — “if APT29 were in this environment, I’d expect to see WMI event subscriptions for persistence and encrypted C2 over HTTPS” — and then actively look for evidence that would confirm or refute it.

“I wonder if we’re compromised” → specific, testable VQL query

Now the five sections, in the order data actually flows through them:

---

Platform Architecture

velociraptor/ is the entry point

• ingest.py loads real hunt exports (JSON/CSV/JSONL) from a live Velociraptor server
• client.py can execute VQL directly against a live server over its gRPC API

attack_rag/ answers “given these findings, which TTPs are active?”→ starts a hound hunt for any relevant findings → retrieves relevant techniques → writes a justification tied to a specific finding

vql_library/ and hunt_generator/ work together on the hypothesis side

library — static shelf of 29 pre-written VQL queries (specific hunt hypothesis + tagged with the technique IDs it covers)

generator takes a threat actor name → looks up which techniques that actor is known to use (from attack_groups.json) → does the library cover ALL the techniques → if not, drafts a new VQL in the same style: “APT29” turns into a concrete, runnable list of hunt queries targeting exactly the behaviors that actor is known for

(4) Risk dashboard — aggregate hunt results, score endpoints by risk, surface top 10 for analyst review + static HTML dashboard

risk_scoring/ takes raw findings → scores them 0–100 score, using a transparent formula (severity of technique hits, volume of findings, distinct tactics performed)

• dashboard.py renders that as the static HTML view with the top-10 table

reporting/

• heatmap.py turns the technique-hit counts into the ATT&CK matrix visualization (and an ATT&CK Navigator-compatible layer file)

(5) Executive report — findings → ATT&CK heatmap → executive PDF

pdf_report.py assembles all of it — executive summary, KPIs, heatmap, top-10 table, recommendations — into a PDF

Final process: velociraptor/ produces findings → attack_rag/ tells you which TTPs those findings represent → vql_library/+hunt_generator/ tell you what to go hunt for next (including actor-specific hypotheses) → risk_scoring/ and reporting/ turn everything into something you’d actually hand to an analyst or a CISO

---

Demo

Velociraptor hunt exports looks like:

WKS-SALES-004 — highest risk with 96.1 score

Math behind that decision:

1. Severity-weight for each technique

Every finding contributes points based on its severity: critical +14, high +8, medium +4

WKS-SALES-044: 3 critical findings (LSASS dumping, shadow-copy deletion, Defender tampering) + 4 high findings (SMB lateral movement, encoded PowerShell, DNS beaconing) and 1 medium →→→ 3(14) + 4(8) + 4 = 78

2. Finding volume, log-dampened = 3 * log1p(finding_count) Host has 8 findings →→→ 3 * log1p(8) ≈ 6.6

3. Breadth of distinct ATT&CK tactics = 5 * log1p(distinct_tactic_count)= 11.5

The kill-chain-progression signal: looks up each finding’s technique(s) → collects every unique tactic they map to

This host hit 9 of 12 possible tactics: persistence, execution, defense-evasion, credential-access, lateral-movement, exfiltration, impact, and more

78.0 + 6.6 + 11.5 = 96.1 raw score

what makes it the top? the combination of severe findings and activity spanning nearly the whole kill chain

Results:

If we want to specifically look at APT29 (Russia–Cozy Bear or Midnight Blizzard) and the techniques they use:

python run.py generate-hunt - actor APT29

All endpoints are analyzed and related TTPs are found. Understanding a threat and the open avenues an attacker can take to enter is vital to stop an exploitable threat. Before a threat becomes an alert on a SIEM, the signs can be identified and an attack can be prevented.