Hypothesis-Driven Hunting

"I feel like something is off with our service accounts" is not a hunt. It is anxiety. A hunt is a sentence you can prove false: "A service account has authenticated interactively in the last 30 days, which it should never do." Now you have something a query can settle. Either that event exists in the logs or it does not.

The falsifiable part matters more than it sounds. If your hypothesis cannot come back clean, you have not written a test, you have written a mood. And a hunt that can never end is one you will abandon halfway through, learning nothing.

Build the hypothesis from a real technique

The strongest hypotheses come from a specific attacker behavior, not a general fear. Pick a MITRE ATT&CK technique that fits your threat model and phrase it as something that either happened or did not.

Take T1053.005, scheduled task persistence. The vague version is "attackers use scheduled tasks." The hypothesis version is testable:

$A non-admin process created a scheduled task that runs a script from a user-writable directory in the last 14 days.

Notice the shape. A subject (non-admin process), an action (created a scheduled task), a suspicious qualifier (script from a user-writable path), and a time bound (14 days). Strip any of those and the hunt gets harder to end.

Map it to data before you query

Before you write a single query, answer three questions on paper. Which log source records this behavior. Do you actually collect it and for how long. What field distinguishes benign from suspicious. If you skip this, you will burn an hour building a query against a log that does not contain the answer.

For the scheduled-task hunt on Windows, the mapping is concrete: Security event ID 4698 records task creation, Sysmon event ID 1 gives you the parent-child process lineage, and the task's Command field tells you what it runs. On Linux the analog is auditd rules on cron writes plus execve logs. Write that mapping down. It is half the hunt.

Reach a verdict, every time

A hunt has exactly three honest outcomes and you should name which one you hit. You found malicious activity, so it becomes an incident. You found benign activity that looks malicious, so it becomes tuning or an allow-list entry. Or you found nothing, which either falsifies the hypothesis or exposes a visibility gap because you could not see well enough to answer.

The failure mode is stopping at "hmm, weird" and walking away. Weird is not a verdict. Chase every anomaly to one of the three endpoints. Even a clean result is worth writing down, because next quarter someone will ask "did we ever check for this," and "yes, on this date, over this window, nothing" is a real answer.