Writing a hunt hypothesis

A hunt without a hypothesis tends to become browsing. You open a console, scroll, and stop when time runs out. A hypothesis gives the hunt an end: it is either supported by the data or it is not.

The four parts

A workable hypothesis has four parts.

1. A behavior. Something an attacker does, stated as an action: "an account signs in interactively", "a scheduled task is created", "a log source stops reporting". Avoid naming a threat group; groups change their tools, behaviors are what you can see.
2. A place. The systems, users or accounts where it would happen: domain controllers, service accounts, the finance team's laptops.
3. A time frame. The window you will look at, such as the last 30 days.
4. The evidence. The data source that would show the behavior, and what a positive result would look like in it.

Put together: "In the last 30 days, a service account signed in interactively to a workstation, visible in identity provider sign-in logs as an interactive logon type for an account in the service account group."

Check it before you hunt

Ask three questions. Can I reach the data? If the evidence lives in a source you cannot query, rewrite the hypothesis or fix the access first. Would a negative result tell me something? If nothing found is as likely to mean missing data as no attacker, the hypothesis needs a sharper evidence line. Does it map to an ATT&CK tactic? Tagging it now means the result can be counted against coverage later. See reading an ATT&CK tactic page.

Keep it small

A hypothesis that needs weeks is usually two or three hypotheses joined together. Split it. Small hunts close, and closed hunts produce either a finding or a documented negative, both of which are useful records.

Write down what you ruled out

The most common loss in hunting is the result nobody recorded. Note the query, the window, the number of matches and why each was dismissed. The next hunter starts from there instead of from zero.

For a longer treatment, see hypothesis-driven threat hunting.