The Agentic Threat Hunting Framework gives hunt teams a markdown-based memory layer that documents investigations with the LOCK pattern and lets AI agents recall, research, and build on past hunts.
| Tool | Nebulock-Inc/agentic-threat-hunting-framework — memory and automation layer for threat hunting programs, MIT-licensed Python package on PyPI |
| Category | Threat hunting program management and agentic AI workflow framework |
| Primary Use | Documenting hunts with the LOCK pattern, maintaining a searchable hunt repository, and letting AI assistants generate research and hypotheses in authorized defense operations |
| Safe Use | Purely defensive: for authorized SOC, hunt, and detection-engineering teams operating within their own environments or contractual assessment scope |
| Telemetry Note | ATHF generates no offensive traffic; it writes markdown hunt records, research docs, and GATES YAML verdicts locally, leaving an audit trail of defensive analysis rather than artifacts on targets |
Most threat hunting programs die of amnesia. Notes rot in Slack threads, queries get written once and forgotten, and the lessons from last quarter's investigation live only in one analyst's head. ATHF, the Agentic Threat Hunting Framework from Nebulock-Inc, attacks exactly that problem: it is not another hunting methodology but the persistence layer that sits underneath whatever methodology you already run, whether that is PEAK, TaHiTI, or a homegrown process. The framing matters for operators evaluating tooling — this is infrastructure for institutional memory, not a detection engine itself.
The core abstraction is the LOCK pattern: Learn → Observe → Check → Keep. Learn gathers context from threat intel, alerts, or anomalies; Observe forms a hypothesis about adversary behavior; Check tests that hypothesis with targeted queries; Keep records findings and lessons learned. The README is candid about why this particular loop was chosen — it is small enough that humans will actually use it, yet strict enough that an AI agent can parse and act on it. That dual audience is the whole design thesis: every hunt captured in LOCK format becomes machine-readable history an assistant can recall when proposing refined queries later.
Technically, ATHF is a markdown-based framework wrapped in a Python CLI, distributed on PyPI as agentic-threat-hunting-framework and requiring Python 3.11+. Installation is conventional: pip install agentic-threat-hunting-framework followed by athf init to scaffold a workspace. For teams that want zero dependencies, there is a pure-markdown path — clone the repo, copy athf/data/templates/HUNT_LOCK.md into a hunts/ directory, and customize AGENTS.md with your SIEM, EDR, and data sources. That flexibility to run with no tooling at all is a deliberate architectural choice worth noting.
The CLI is where the operational value concentrates. athf hunt new creates hunts with structured metadata — --technique T1003.001, --platform windows, --hunt-type baseline — while athf hunt list and athf hunt search provide full-text recall across the repository, with filters for --status, --directory (test versus production), and --output json for scripting. A athf hunt validate command enforces structural consistency across hunt records. The design keeps hunts as plain files, which means version control, grep, and any AI coding assistant all work against the corpus for free.
Version 0.3.0 added what the README labels AI-powered research and hypothesis generation. athf research new --topic "LSASS dumping" --technique T1003.001 runs a documented pre-hunt research pass (the README estimates 15–20 minutes at full depth, with a --depth basic quick mode for urgent hunts), and athf agent run hypothesis-generator --threat-intel "APT29 targeting SaaS" turns an intel note into candidate hypotheses. The explicit time expectations are a nice touch — they set realistic operator expectations rather than promising magic.
The maturity model is one of the more honest pieces of the documentation. Five levels run from 0 (ad-hoc hunts scattered across tickets) through 1 (documented with LOCK, operational within a day), 2 (searchable by AI, within a week), 3 (generative — AI executing queries via MCP tools and conducting research, 2–4 weeks), and 4 (fully agentic autonomous monitoring, 1–3 months). The README explicitly states most teams will live at Levels 1–2 and that everything beyond is optional maturity. That restraint is rare in the agentic-AI tooling space and suggests the authors have run real programs.
The second major methodology component is GATES, a hunt-to-detection promotion validation framework applied after the KEEP phase. GATES stands for Generalizable, Additive, Tunable, Exposure-tested, Sustainable — five gates each designed to catch a specific failure mode: IOC-based rules that expire, duplicate detections, baseline noise mismatch (called out as the top false-positive cause), single-dimensional detections, and unsustainable high-volume rules. It uses a two-tier structure with five BASE criteria scored from hunt data and five ADVANCED criteria validated in production.
The GATES verdict system is more nuanced than a simple pass/fail. Score bands of 4.0–5.0 yield PROMOTE (deploy as a standing detection), 3.0–3.9 yield CONDITIONAL, and below that HOLD — but there are also TIME_BOX for campaign-specific rules on a 90-day refresh, RECURRING_HUNT for quarterly execution instead of 24/7 monitoring, and DROP for logic not worth detecting but recorded so it is never re-proposed. Gate failures override score bands, with a deterministic tie-break order. The key detail for practitioners: GATES runs as a skill invoked in your AI assistant (/gates --hunt H-0001 typed to the assistant, not a shell command), and it is currently available only via git clone, not the pip distribution — tracked as Issue #21.
GATES also defines a handoff to a sibling project, ADEF, the agentic-detection-engineering-framework. Validated hunts emit hunt-promotion-analysis/H-XXXX_GATES.yaml files that adef hunt-promote --gates ingests, minting each deployable candidate a D-XXXX catalog record and journal entry at the Find stage of ADEF's FORGE pipeline. Archival verdicts emit .md narratives instead. This hunt-to-rule pipeline — LOCK hunting, GATES validation, ADEF engineering — is the clearest picture of where the project intends to fit in a mature detection program.
On integration posture, ATHF is deliberately platform-agnostic: it works with any SIEM or EDR because it never touches the telemetry itself, and it supports any AI assistant that can read repository files — the README names Claude Code, GitHub Copilot, and Cursor explicitly. With 379 stars, an MIT license, and active PyPI distribution, the project has reasonable traction for its niche, though the GATES packaging gap and the pre-1.0 version number signal it is still moving quickly.
For defenders evaluating adoption, the low-risk entry point is the pure-markdown mode: clone the repository, copy the HUNT_LOCK.md template, and see whether the LOCK structure fits your team's workflow before installing anything. The main operational caution is the standard one for agentic tooling — Level 3+ capabilities involve AI executing queries through MCP tools against your SIEM, so scope and permissions for those integrations deserve the same scrutiny you would give any automated query agent. Used within authorized environments, ATHF is a well-documented bet that threat hunting improves when programs stop forgetting.
Nebulock-Inc/agentic-threat-hunting-framework.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.