You log in, the dashboard is glowing green, and not a single alarm is going off. Everything looks perfect, right? Honestly, that’s exactly what worries me. After years of jumping between attacking and defending, I’ve realized one thing: the real threats usually hide in those "quiet" moments.
A smart attacker doesn't just kick the door down and start making noise. They slip in, escalate privileges, and wipe their tracks as they go. This is where you need that "gut feeling" that your SIEM won't give you.
I remember a project recently where everything seemed totally fine. But when we dug deeper, we noticed some weird DNS traffic spikes from a specific user outside of work hours. If we had just sat there thinking, "the firewall will catch it if something's wrong," we probably wouldn't have spotted that data leak for months. That’s exactly where threat hunting begins. Instead of waiting for someone to break a window and trigger an alarm, you go out there and ask, "Is someone already inside? Let's go find them."
Start with a Hypothesis
One of the questions I get most is: "Where do we even start?" The answer is simple, though it takes some patience: build a hypothesis. You need to visualize this in your head: "If I were the attacker trying to stay hidden in this specific company, how would I do it?"
Let’s throw an idea out there: "The attacker might be using scheduled tasks to stay persistent in the system." Look, that’s a great starting point. Suddenly, you aren't looking at a mountain of useless logs anymore; you have a specific target to investigate.
Sysmon: Your Eyes and Ears
If you’re working in a Windows environment and you aren't using Sysmon (System Monitor), you’re basically walking through a dark room with your eyes closed. Standard Windows logs can be way too surface-level. Sysmon, on the other hand, hands you the "who, what, when, and how" of every process on a silver platter.
Event ID 1 (Process Creation) is my absolute favorite. It’s where attackers leave the most tracks. For example, if you see cmd.exe or powershell.exe being triggered by w3wp.exe (IIS), you need to stop and think. Why would a web server be running PowerShell under normal conditions? You’re likely looking at a web shell.
Here’s a simple KQL (Kusto Query Language) snippet for you. If you’re using Azure Sentinel or something similar, this can be a lifesaver:
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("w3wp.exe", "httpd.exe", "nginx.exe")
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "bitsadmin.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine
// This query helps you find suspicious command-line activities running under web servers.
The truth is, a query as simple as this can uncover a breach that's been sitting there for weeks in just a matter of seconds.
The Dark Side of PowerShell
As you probably know, PowerShell is an attacker’s favorite toy. It’s part of what we call "Living off the Land"—using the system's own tools against itself so they don't have to bring in "loud" malware.
Don't just wait for the red lights to blink. Go out there, ask the right questions, and start hunting. I'm still learning new tricks every day, and honestly, that curiosity is what keeps us one step ahead.