A documentation-first methodology repository that turns threat hunting from ad hoc investigations into a gated, auditable pipeline with SMART hypotheses, feasibility gates, and Jira-tracked outcomes for authorized blue teams.
| Tool | sims718718/UnifiedThreatHunting — a unified, structured threat hunting process synthesizing Sqrrl, TaHiTI, PEAK, AIMOD2 and OTHF into one repeatable workflow |
| Category | Threat hunting methodology / blue team documentation framework |
| Primary Use | Standing up and running a threat hunt program: Environment Profile capture, trigger-driven SMART hypothesis development, GO / NO-GO / CONDITIONAL feasibility gating, and outcome reporting inside a SIEM/EDR-driven SOC |
| Safe Use | Entirely defensive: designed for authorized security teams hunting threats inside their own or contractually covered environments; the README explicitly enforces RoE/contract checks before any multi-tenant hunt |
| Telemetry Note | Purely defensive and read-only by design — hunts consume existing SIEM/EDR telemetry (e.g., Windows Event ID 4768/4624) rather than generating it; its footprint is analytical queries and Jira artifacts, not host modifications |
Most repositories covered here are code you install; sims718718/UnifiedThreatHunting is something rarer and arguably more valuable — a complete, opinionated process for running threat hunting as a program rather than a series of heroic one-off investigations. The author, writing as a Lead Threat Hunter who built a hunt program from scratch, documents the result of synthesizing several established frameworks into what they call a Unified Threat Hunting Process. With 109 stars and a structured docs/ layout, it reads less like a side project and more like internal documentation that escaped into the public, which is exactly what makes it worth an authorized blue team's attention.
The spine of the repo is a Mermaid pipeline diagram that defines the full lifecycle: Step 0: Environment Context, then Triggering Event, Hypothesis Development, Initial Assessment, Feasibility Assessment, Define Scope & Objectives, Formalize Hunt Plan, Execute Hunt, Document Outcomes, and finally Report & Iterate — which loops back to the trigger stage. That closing loop matters. It frames hunting as a continuous program function where the output of one hunt becomes an input to the next, rather than a terminal deliverable that gets filed away. The Report & Iterate edge is the difference between a team that hunts and a team that matures.
What elevates this above a personal checklist is the honest accounting of provenance. A table in the README maps exactly which prior art contributes what: the Sqrrl / Hunting Maturity Model from Bianco supplies the core loop and the maturity ladder, TaHiTI contributes the idea of the trigger as the true starting point plus handover to adjacent processes, PEAK brings hunt typing and the outcome-focused close, AIMOD2 adds the assumed breach premise and typed outcome categories, and OTHF provides the operational framing for running hunts as a repeatable team function. The author is explicit that the differentiators — Step 0, the hard feasibility gate, Jira integration with typed outcomes, and a rubric-gated hypothesis — are the only original rows in the table. That citation discipline is a strong signal of maturity.
The hunt-typing model is where practitioners will find immediate utility. Rather than insisting on one canonical hunt style, the process recognizes four types indexed against where you sit in the DAIKI chain (Data → Information → Knowledge → Insight): Exploratory (EDA) hunts start from raw data with no prior hypothesis and focus on baselining, Hypothesis-Based (HBO) hunts test credible attack scenarios from situational awareness, Threat-Informed (TIO) hunts are driven by actionable CTI, and Purple Operations (DPO) hunts use red team insight for joint offensive/defensive validation. The README is refreshingly pragmatic about IoCs too: hunting IoCs across an environment "is not really threat hunting," but actionable and timely indicators can still serve as a legitimate starting point within the cycle.
Step 0: Environment Context is the first genuine innovation, and the motivation is one any experienced hunter will recognize — hunt plans that reference data sources nobody has, or queries written in the wrong dialect entirely. The process requires an Environment Profile block at the top of every Epic documenting the SIEM/data platform (because Splunk SPL, KQL, Elastic DSL, and Chronicle each shape every query), the EDR platform (because CrowdStrike, SentinelOne, and Defender for Endpoint use different telemetry field names), environment type (on-prem versus AWS/Azure/GCP cloud-native or hybrid), industry vertical, log retention windows, and hunt maturity level. If you are moving fast, the minimum viable profile is SIEM platform plus environment type.
The multi-tenant provisions deserve specific praise from a governance standpoint. MSSP/MDR providers or organizations with federated subsidiaries are told to keep one tenants/<id>/profile.yaml registry and have each Epic reference tenant: <id> rather than embedding the profile. Critically, before any feasibility assessment, the process mandates an authorization check: a tenant with no RoE or contract coverage, or a planned action outside its allowed_actions, is flagged as NOT AUTHORIZED and the hunt stops there. Embedding scope enforcement into the workflow itself — rather than leaving it to tribal knowledge — is how authorization boundaries survive contact with operational pressure.
The trigger phase borrows directly from TaHiTI: hunts begin with a triggering event that justifies initiation, whether CTI, incomplete detection use cases, past incidents, red teaming, or MITRE ATT&CK TTPs, extended here with stakeholder-driven requirements and vulnerability disclosures. The author mounts a quiet philosophical defense of this ordering — some frameworks start with the hypothesis, but the README asks where that hypothesis came from in the first place, invoking Newton's apple as the triggering event behind the hypothesis about gravity. It is a small rhetorical flourish, but it fixes a real sequencing problem: without a documented trigger, hunts lack justification and prioritization logic.
Hypothesis development is treated as the most critical and most ambiguous step, and the process attacks it from two directions. First, hypotheses must be SMART — Specific, Measurable, Achievable, Relevant, Time-bound — with "no never-ending hunts" as an explicit rule. Second, it imports Heuer's Analysis of Competing Hypotheses from *Psychology of Intelligence Analysis*, the CIA's classic on analytical rigor, including the seven-step matrix process for enumerating hypotheses, seeking evidence, stripping out non-diagnostic evidence, prioritizing by likelihood, and documenting the comparison. The README supplies a fill-in hypothesis template plus two fully worked defensive examples — one CTI-driven around AS-REP Roasting (T1558.004) evidenced by Event ID 4768 in Splunk logs, one behavior-driven around anomalous privileged interactive logons evidenced by Event IDs 4624/4672 in CrowdStrike telemetry.
The Initial Assessment phase comes with a concrete checklist that operationalizes due diligence: reviewing previous hunts and lessons learned, pulling internal documentation such as network diagrams, asset inventory, and code repos, checking existing detection coverage, gathering external sources including OSINT, vendor reporting, ATT&CK technique docs, and relevant Sigma rules, issuing RFIs to trusted external organizations, and — notably — documenting known-good behavior, which becomes the exclusion list that keeps hunts from drowning in benign traffic. The README also stresses SME interviews where the environment is unfamiliar, with the sensible caveat that the goal is sufficient understanding, not becoming a system expert.
Where the README is truncated in the available material — the Feasibility Assessment section cuts off mid-heading — the earlier synthesis table tells you what to expect: a hard GO / NO-GO / CONDITIONAL gate that decides whether a hunt proceeds at all. This is arguably the most operationally mature idea in the whole framework, because it forces teams to kill weak hunts before they consume analyst weeks, and it pairs naturally with the Jira Epic/Story/Task structure with typed outcomes mentioned in the differentiators row. Supporting material lives in the /Data_Analysis folder with notebooks for the exploration phase, and a dedicated Threat_Intelligence/Intelligence-Led_Threat_Hunting.md document reflects the position that CTI is engrained into the entire process rather than bolted on.
For defenders evaluating adoption, the honest assessment is that this repo gives you scaffolding, not automation. There is no tooling to install and no magic query generation — the value is in the gates, the templates, the checklists, and the governance model, all of which need to be adapted to your stack via the Environment Profile. Teams at lower maturity on the Bianco ladder will get the most from the structure; mature teams may mostly harvest the Step 0 profile pattern, the feasibility gate, and the multi-tenant authorization registry. Either way, git clone https://github.com/sims718718/UnifiedThreatHunting and read it against your own hunt workflow — the gaps it exposes will be the real deliverable.
The defensive character of this project cannot be overstated. Every element — exclusion lists, known-good baselining, detection handoff specifications, RoE enforcement — exists to find adversaries that already bypassed controls, under an explicitly assumed breach premise, inside environments the team is authorized to defend. For security leadership, it is also a rare example of a repo that addresses the organizational layer of hunting: how hunts are justified, scoped, authorized, tracked, and reported. That layer is where most hunt programs quietly fail, and this framework documents a credible answer.
sims718718/UnifiedThreatHunting.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.