Threat hunting goes wrong for beginners in a predictable way. Someone has a hunch, you open your log tool, you scroll, you find nothing conclusive, and three hours disappear. The missing ingredient usually isn't tooling. It's a specific, written target for what you're looking for. MITRE ATT&CK supplies that target. It's a free, public knowledge base that describes how real intrusions actually unfold, organised into tactics and techniques, and it gives you a vocabulary that works whether you're a one-person security team or part of a large SOC.

Tactics Are Goals, Techniques Are Methods

The Enterprise matrix has fourteen tactics, starting at Reconnaissance and running through Initial Access, Execution, Persistence, Discovery, Lateral Movement, and on to Impact. A tactic is the adversary's objective at a stage of the intrusion. A technique is how they achieve it, and techniques have numbered IDs you can search and cite.

Take persistence. The tactic is Persistence (TA0003). A technique under it is Scheduled Task/Job (T1053), and a sub-technique is Scheduled Task on Windows (T1053.005). When you say "T1053.005" in a hunt ticket or a detection rule name, everyone knows exactly what you mean. That precision is the whole value.

Resist the urge to work through the grid top to bottom. A realistic first goal is one tactic, done properly, with your findings written down.

Write a Hunt Hypothesis Before You Write a Query

Hunting is hypothesis-driven. The template that keeps beginners honest looks like this: If an adversary is doing [technique] on our estate, we would see [artifact] in [data source].

Here's a filled-in example:

If an adversary established persistence using a scheduled task, we would see schtasks.exe invoked with /create from an unusual parent process, or a Windows Security event 4698 where the task author isn't our configuration management account.

Notice what that does. It names the technique, the telemetry to check, and the normal pattern it deviates from. A query writes itself once the hypothesis is that concrete.

Confirm You Have the Telemetry First

This step is boring and non-negotiable. If you don't collect command lines, you cannot hunt techniques that live in command lines. Before committing to a hunt, check roughly three telemetry tiers:

• Endpoint process data: Sysmon Event ID 1, Windows Security 4688 with process creation auditing enabled, or your EDR's process events. This is the workhorse for Execution, Persistence, and Discovery hunts.
• Account and authentication data: 4624 for successful logons, 4625 for failures, 4720 for account creation. Necessary for Credential Access and much of Lateral Movement.
• Network and naming data: DNS queries, proxy logs, firewall flows. Useful for Command and Control, and often the only visibility you get into hosts you don't manage.

Sketch which techniques each source actually supports. That rough table becomes your coverage map, and it's far more useful to leadership than a count of alerts.

Turn the Technique into a Query

Start deliberately broad. The first pass exists to collect evidence and teach you what normal looks like, not to page anyone. Here's a scheduled-task hunt in KQL, the syntax used in Microsoft Defender and Sentinel:

DeviceProcessEvents
| where FileName in~ ("schtasks.exe", "at.exe")
| where ProcessCommandLine has_any ("/create", "/change")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, ProcessCommandLine

Each line does one job: restrict to process events, restrict to task-scheduling binaries, keep only creation or modification, then pull the fields you'll triage. Field names differ across SIEMs, so adapt to Splunk, Elastic, or your own schema. The logic travels.

Run it over a wide window. Fourteen to thirty days, not twenty-four hours. You are building a baseline, and volume spikes that look alarming inside a single shift often turn out to be patch cycles.

What to Keep From Every Result

• Timestamp, hostname, and account
• Parent process name and full path
• Full command line, unredacted
• Process hash, if your telemetry carries it

Triaging Results Like a Hunter

Most of what comes back will be legitimate. That's expected. What you're scanning for is friction between the artifact and how your organisation normally behaves. Signals worth pulling the thread on:

• A document reader or spreadsheet spawning a task-scheduling binary. Office has no reason to do that.
• Command lines containing encoded blobs, long base64 strings, or -enc flags.
• Task names that imitate system names with a letter doubled or reversed.
• An account creating scheduled tasks on a host it has never touched before.
• One host registering several tasks in a short burst, especially outside change windows.

Then pivot. Take the parent process from a suspicious result and search for it across thirty days. If the same binary also appears in your command-line hunt or a service-creation hunt, you're no longer looking at one odd event; you're looking at a pattern.

When something turns out to be benign, that's a result too. Note the script, the admin group, or the updater responsible. It sharpens every future hunt and stops the next person from repeating your investigation.

Close the Loop So the Work Compounds

A hunt that ends without documentation evaporates. Write a short entry every time:

1. The hypothesis and the technique ID
2. The query text and the date range searched
3. Data sources used, and anything you couldn't see
4. Findings, including confirmed false positives
5. The next question this raised

Anything that proved reliably suspicious becomes a detection rule. Anything merely noisy becomes a dashboard you glance at weekly. Plot your covered techniques in ATT&CK Navigator, note the gaps, and pick your next tactic from there rather than from whatever alert happened to be loudest.

Your First Hunt This Week

Keep the scope small enough to finish. Confirm command-line logging is on, choose a single technique such as T1053.005, write the hypothesis in one sentence, and run the broad query over the last two weeks. Take the five strangest results and draw a process tree for each one. Then write the five-line hunt log and pick one thing to detect next.

Do that twice a month and something shifts. You stop waiting for alerts to tell you where to look, you start knowing what belongs on your network, and the matrix in front of you becomes a map instead of a wall of acronyms.

Photo: B_A / Pixabay