building-a-threat-hunt-hypothesis

Name: building-a-threat-hunt-hypothesis
Author: meltedinhex

18stars5forks

How to install building-a-threat-hunt-hypothesis?

meltedinhex/analyst-ai-pack/building-a-threat-hunt-hypothesis

$npx -y skills add meltedinhex/analyst-ai-pack --skill building-a-threat-hunt-hypothesis

Installs into the current project.

Summary

Frames a structured, testable threat-hunting hypothesis: grounding it in adversary

Files · 1

View on GitHub

SKILL.md

1	# Building a Threat-Hunt Hypothesis
2
3	## When to Use
4
5	- You are starting a proactive, hypothesis-driven hunt rather than responding to an alert.
6	- You need to turn a vague concern ("are we seeing living-off-the-land abuse?") into a testable,
7	scoped statement with clear data requirements.
8	- You want a repeatable plan that produces either a detection, a gap, or a confident negative.
9
10	Do not use this as an incident-response trigger — if you already have a confirmed alert,
11	pivot to investigation/IR, not hypothesis generation.
12
13	## Prerequisites
14
15	- Knowledge of your environment's telemetry (EDR, Sysmon, proxy, DNS, auth logs) and retention.
16	- Familiarity with ATT&CK to anchor the behavior you intend to hunt.
17
18	## Workflow
19
20	### Step 1: Pick a behavior, not a tool
21
22	Anchor on an adversary behavior (an ATT&CK technique/sub-technique) you have reason to expect
23	given your threat model, not a specific product alert.
24
25	### Step 2: Write a testable hypothesis
26
27	Use the form: "If [actor behavior], then I expect to observe [evidence] in [data source]."
28
29	```text
30	If an adversary uses WMI for lateral movement (T1047), then I expect to observe
31	wmiprvse.exe spawning command interpreters on hosts that do not normally do so,
32	in Sysmon process-creation (Event ID 1).
33	```
34
35	### Step 3: Map to data and logic
36
37	Confirm the data source exists and is retained, then define the concrete query/detection logic
38	and what "normal" looks like (baseline) so anomalies stand out.
39
40	```bash
41	python scripts/analyst.py plan --technique T1047 --datasource "Sysmon EID1" --window 14d
42	```
43
44	### Step 4: Set scope and success criteria
45
46	Define the host/time scope, the threshold for "interesting," and the three possible outcomes:
47	finding (→ IR), detection gap (→ engineering), or confident negative (documented).
48
49	### Step 5: Record and hand off
50
51	Capture the hypothesis, queries, and outcome so it becomes a repeatable, version-controlled
52	hunt — successful logic becomes a detection rule.
53
54	## Validation
55
56	- The hypothesis is falsifiable and names a specific data source that actually exists.
57	- A baseline of "normal" is defined so results are interpretable.
58	- Each outcome has a defined next action (IR, detection engineering, or documented negative).
59
60	## Pitfalls
61
62	- Hunting for a tool name instead of a behavior, missing variants.
63	- Writing a hypothesis you cannot test with available telemetry.
64	- No baseline, so every result looks suspicious (or nothing does).
65
66	## References
67
68	- See [`references/api-reference.md`](references/api-reference.md) for the hunt-plan generator.
69	- MITRE ATT&CK and the PEAK framework (linked in frontmatter).

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

building-a-threat-hunt-hypothesis

18stars5forks

View on GitHub

How to install building-a-threat-hunt-hypothesis?

meltedinhex/analyst-ai-pack/building-a-threat-hunt-hypothesis

$npx -y skills add meltedinhex/analyst-ai-pack --skill building-a-threat-hunt-hypothesis

Installs into the current project.

Summary

Frames a structured, testable threat-hunting hypothesis: grounding it in adversary

Files · 1

View on GitHub

SKILL.md

1	# Building a Threat-Hunt Hypothesis
2
3	## When to Use
4
5	- You are starting a proactive, hypothesis-driven hunt rather than responding to an alert.
6	- You need to turn a vague concern ("are we seeing living-off-the-land abuse?") into a testable,
7	scoped statement with clear data requirements.
8	- You want a repeatable plan that produces either a detection, a gap, or a confident negative.
9
10	Do not use this as an incident-response trigger — if you already have a confirmed alert,
11	pivot to investigation/IR, not hypothesis generation.
12
13	## Prerequisites
14
15	- Knowledge of your environment's telemetry (EDR, Sysmon, proxy, DNS, auth logs) and retention.
16	- Familiarity with ATT&CK to anchor the behavior you intend to hunt.
17
18	## Workflow
19
20	### Step 1: Pick a behavior, not a tool
21
22	Anchor on an adversary behavior (an ATT&CK technique/sub-technique) you have reason to expect
23	given your threat model, not a specific product alert.
24
25	### Step 2: Write a testable hypothesis
26
27	Use the form: "If [actor behavior], then I expect to observe [evidence] in [data source]."
28
29	```text
30	If an adversary uses WMI for lateral movement (T1047), then I expect to observe
31	wmiprvse.exe spawning command interpreters on hosts that do not normally do so,
32	in Sysmon process-creation (Event ID 1).
33	```
34
35	### Step 3: Map to data and logic
36
37	Confirm the data source exists and is retained, then define the concrete query/detection logic
38	and what "normal" looks like (baseline) so anomalies stand out.
39
40	```bash
41	python scripts/analyst.py plan --technique T1047 --datasource "Sysmon EID1" --window 14d
42	```
43
44	### Step 4: Set scope and success criteria
45
46	Define the host/time scope, the threshold for "interesting," and the three possible outcomes:
47	finding (→ IR), detection gap (→ engineering), or confident negative (documented).
48
49	### Step 5: Record and hand off
50
51	Capture the hypothesis, queries, and outcome so it becomes a repeatable, version-controlled
52	hunt — successful logic becomes a detection rule.
53
54	## Validation
55
56	- The hypothesis is falsifiable and names a specific data source that actually exists.
57	- A baseline of "normal" is defined so results are interpretable.
58	- Each outcome has a defined next action (IR, detection engineering, or documented negative).
59
60	## Pitfalls
61
62	- Hunting for a tool name instead of a behavior, missing variants.
63	- Writing a hypothesis you cannot test with available telemetry.
64	- No baseline, so every result looks suspicious (or nothing does).
65
66	## References
67
68	- See [`references/api-reference.md`](references/api-reference.md) for the hunt-plan generator.
69	- MITRE ATT&CK and the PEAK framework (linked in frontmatter).

People who liked this also viewed

6 picks

Type