Threat hunting without a plan is just clicking around in the UI until you get bored.
Start with your own data. Don't try to replicate a blog post using someone else's dataset. Look at what Elastic Security is already detecting for you, then work backwards.
Your first steps:
* **Turn on the pre-built detection rules.** Let the system do the initial heavy lifting. Go to `Security -> Alerts` and see what fires.
* **Filter to a single host.** Pick a known server or workstation. Examine its process tree, network connections, and file modifications over the last 48 hours. Learn what normal looks like for *that* machine.
* **Run one pre-built query from the "Timeline" explorer.** Don't modify it yet. Just run it, look at the raw results, and try to understand why each field is there.
Example to list unique parent-child process relationships on a host:
```json
{
"query": {
"match": {
"event.category": "process"
}
},
"aggregations": {
"process_combo": {
"terms": {
"script": "doc['process.name'].value + ' -> ' + doc['process.parent.name'].value",
"size": 10
}
}
}
}
```
Your goal this week isn't to find an APT. It's to understand how your data flows into indices and how to ask a simple question. Come back with what you find and we'll get to the next step.
-miked
Numbers don't lie
Totally agree, especially on starting with your own data. I've seen so many teams get stuck trying to recreate a fancy hunt from a conference talk using a completely different dataset. It just leads to frustration.
The "filter to a single host" advice is golden. I'd add that picking a quiet, predictable server first is better than a user's laptop. You'll get a cleaner baseline of what "normal" actually is for that system, like scheduled tasks and benign background processes. Once you know that, the weird stuff stands out way more.
Your point about the goal not being to find an APT this week is so important. Early wins are about comfort with the data and the tool, not catching a criminal. That mindset shift keeps it from feeling pointless.
ian
Couldn't agree more. That "filter to a single host" step is what stopped me from rage-quitting when I started. I picked my own laptop, which was a mistake - turns out my "normal" is a horrifying procession of browser tabs, failed compile jobs, and a truly disturbing number of PowerShell sessions. Learning what's normal really means confronting your own operational chaos first 😅
Building on your "work backwards" point, I found it helpful to pick *one* alert that actually fired and just obsessively trace its timeline. Why did this rule trigger on Tuesday at 3pm? What user was logged in, what was the parent process, was there a network call right after? That reverse-engineering felt way more concrete than staring at a blank query builder.
Also, your sample query is great, but maybe warn people that the first time they run it, they'll realize half their services are spawned by "svchost.exe" and have a minor existential crisis. It's a rite of passage.
Your point about choosing the wrong host is key. Picking your own dev machine is like learning to drive in a demolition derby. A static, purpose-built server is a much clearer baseline.
That "obsessively trace one alert" method is how you move from theory to practical skill. It forces you to ask the right questions. But a caveat: don't get stuck rabbit-holing a false positive caused by some janky internal tool. If you can't find a real alert, start with a common, noisy one you *know* is benign, like a browser update. The process of ruling it out is the same valuable exercise.
And yes, the universal svchost realization is a necessary trauma. Welcome to the jungle.