Keeping a threat hunt log: what to record for every hunt

Ship crews keep a logbook so that the next watch knows what happened on the last one. A hunt log does the same job for a security team. The hunt itself may take an afternoon; the record of it is what makes the afternoon count next month.

What goes in each entry?

Keep the fields the same for every hunt, so entries can be searched and counted.

1. ID and date. A simple running number and the date the hunt closed.
2. Hunter. Who ran it, and who reviewed it if anyone did.
3. Origin. Intelligence (name the advisory or report), hypothesis, or departure from normal.
4. Hypothesis. The one-sentence statement, in the four-part form from writing a hunt hypothesis.
5. ATT&CK tags and version. The tactic and technique IDs, and the ATT&CK version you used, such as v19.2.
6. Data and window. Each source searched, and the exact time range for each. If one source had shorter retention, say so.
7. Queries. The text of every query, stored with the entry rather than in someone's notes.
8. Results. Counts of matches, and the disposition of each group: malicious, benign with reason, or unexplained.
9. Outcome. Finding, documented negative, new detection or data gap.
10. Follow-ups. Tickets opened, rules proposed, owners named.

Why record the ATT&CK version?

Because the framework changes. ATT&CK v19 split the old Defense Evasion tactic into Stealth (TA0005) and Defense Impairment (TA0112). A hunt logged under TA0005 before the split may belong under either tactic now. With the version recorded, a later reviewer knows which vocabulary the entry used. Our post on what ATT&CK v19 changes covers the split.

What does a good log make possible?

• Repeating a hunt. A saved hypothesis plus stored queries is a hunt playbook. Next quarter, the same hunt runs in minutes.
• Handover between shifts. An open hunt with its queries and partial results can be picked up by someone else.
• Coverage reporting. Counting closed hunts by technique shows which behaviors have been checked recently and which have not. That is not proof of protection, but it is an honest map of effort.
• Arguing for data. A list of hunts that ended in a data gap is the clearest case for fixing a source.

Where should the log live?

Anywhere the team already works and can search: a ticket system, a wiki, or a folder in the same repository as the detection rules. Keeping it next to the rules has one advantage: when a hunt becomes a detection, the rule can reference the log entry that produced it. See detection-as-code.

What tools add

Some tools write part of the record for you. Vega's threat hunting page says "every step of the hunt shows its work". Nebulock's LOCK framework ends with a Keep stage that closes a hunt with a finding. When you look at a tool, check whether its record of a hunt includes the queries, the data windows and the reasons for dismissing results, or only the conclusion. The conclusion alone is not enough for the next shift.

Start small

If the team has no log today, start with five fields: date, hypothesis, data and window, outcome, follow-ups. Add the rest once the habit sticks.

Next: turn a logged hunt into a standing rule in from hunt to detection rule.