Threat Hunting 101: Finding Active Compromise Using Logs, Timelines, and Simple Hypotheses

Here’s a thing I’ve seen over and over: most “mystery breaches” aren’t solved because analysts stared at alerts. They’re solved because someone asked one good question and then lined up the logs in time order. That’s what threat hunting 101 really is—turning messy events into a clear story of what’s happening right now.

If you want a direct answer: start with logs, build a timeline, and test simple hypotheses like “is this account still being used in a weird way?” or “did a new tool start running after a login from a new place?” When you do it this way, active compromise usually stops being a vague fear and becomes a pattern you can prove (or disprove).

Threat hunting 101 in plain terms: what you’re actually doing

Threat hunting refers to proactive searching for signs of compromise that alerts may miss. In practice, you look for suspicious behavior, connect events in time, and confirm whether you’re seeing real attacker activity or just normal weirdness.

In 2026, most orgs have more logs than they know what to do with. The hard part isn’t “data exists.” The hard part is deciding what matters. Threat hunting 101 gives you a repeatable way to focus: one question, one timeline, and a small set of tests.

Here’s my rule of thumb from real work: don’t hunt the whole ocean. Hunt the part where fish are biting. That means you pick a slice—an endpoint group, a set of servers, a time window after a known incident, or a single high-risk identity—and you follow it.

Logs you need first: the minimum set that finds active compromise

The best starting logs are the ones that show identity, process activity, network connections, and changes. If you’re missing one of these, your hypotheses will keep breaking.

When I train teams, I tell them to collect at least four log sources (even if you don’t have perfect coverage yet):

• Authentication logs: successful and failed logons, MFA events, token grants, SSO events. (Windows Security Event Logs, AD/Azure AD sign-in logs, Okta sign-in logs, etc.)
• Endpoint process logs: what ran, when it ran, and who launched it. (Microsoft Defender for Endpoint events, Sysmon, EDR telemetry)
• File and registry changes: drops, persistence changes, scheduled tasks, services, startup entries. (Windows event logs, Sysmon, EDR “file created/modified”)
• Network telemetry: outbound connections, DNS queries, proxy logs, firewall hits. (Zeek, firewall, DNS logs, proxy logs)

For active compromise, you also need speed. In a typical hunt, the important question is “is the attacker still active today?” That means your logs need to answer queries across the last few hours and also across the last few days.

What people get wrong about logs (and how to fix it)

Most teams search for “bad strings” instead of searching for behavior that matches an attacker workflow. For example, looking for a single malware name can miss variants. But looking for the chain—unusual login → new process → encoded command → outbound call—is much harder to dodge.

Another common mistake: teams only look at one host. Attackers pivot. They log in to one server, run something, and then move laterally. Even if your hunt starts with one machine, the timeline should widen to accounts and related systems.

If you want a practical setup for collecting the right signals, check your own environment against guidance in our logging and detection fundamentals article on Tutorials & How-To. (If you don’t have it yet, write it—this exact checklist is worth publishing.)

Build a timeline like a detective: the fastest path to “active”

A timeline is just a clean list of “who did what, when” across identity, endpoint, and network. It’s the bridge between raw logs and a confident hunt result.

When I say timeline, I don’t mean a fancy report. I mean you pull events into one ordered view, then you look for gaps and sudden changes. Attackers leave footprints when they do things in sequence.

The timeline workflow I use (step-by-step)

1. Pick an anchor event: a suspicious login, a new admin session, a new scheduled task creation, or an endpoint alert that looked “weird but not fatal.”
2. Define your time window: start 24–72 hours back, and always include at least a few hours forward from the anchor. Active compromise can continue after the first odd event.
3. Collect identity events: sign-ins, token grants, MFA changes, password resets, new device registrations, group changes.
4. Collect endpoint events: process start/stop, parent/child process chains, script execution, service creation, scheduled tasks, driver installs.
5. Collect network events: DNS, outbound connections, proxy logs, unusual geolocation, repeated failed connections that later succeed.
6. Mark likely attacker steps: “initial access,” “execution,” “persistence,” “command and control,” “lateral movement.” You can label them even if you can’t fully prove each one yet.
7. Test the timeline against alternative explanations: is there a normal admin tool? is it a backup job? did a software update run? If your hypothesis can’t beat the normal explanation, you haven’t proven anything.

Timing matters. If you see a login at 10:12, then a script run at 10:13, then outbound DNS spikes at 10:14, that’s a strong “this looks like the attacker doing a sequence” signal. If those events are unrelated or hours apart, the story weakens.

Simple hypotheses that work: how to test without getting lost

A hypothesis is a testable guess about attacker behavior based on your timeline. The trick is to keep them small. Don’t write one giant hypothesis that tries to explain everything.

Here are five simple hypothesis templates I use in hunts because they’re easy to test with common logs.

Hypothesis 1: “This account is still doing risky logins after the first alert.”

Test it by checking whether the same user (or service account) keeps authenticating in a pattern that doesn’t match business reality.

• Look for logins from new countries or new network ranges.
• Look for odd times (for example, 2–4 a.m. weekdays when users typically log in during business hours).
• Check for repeated MFA failures followed by success.
• Verify whether the device name and device ID changed.

In one case I worked in 2025 (we were still aligning our SIEM rules), a helpdesk account had one “failed sign-in” alert. The real story showed up only when we checked that same account for the next three days. It kept signing in from the same small set of IPs and then used those sessions to spawn new PowerShell processes. The alerts were there, but the hunt timeline made the pattern obvious.

Hypothesis 2: “A new parent/child process chain shows execution by mistake or by attackers.”

This is a practical one when you have endpoint process trees (common in EDR and Sysmon). Test whether a normal app suddenly becomes the parent of a suspicious child.

• Office apps launching script interpreters (PowerShell, cmd, wscript, cscript).
• Browsers spawning executables or running scripts.
• Teams/Slack launching command tools.
• One-off admin tools spawning network download commands.

What most people get wrong: they focus on the child process alone. Attackers can swap payloads. But parent/child chains often stay consistent because the attacker needs a way to start their code.

Hypothesis 3: “Persistence changed right after initial access.”

Test for scheduled tasks, services, Run keys, startup folder changes, WMI subscriptions, or new autorun entries.

• Find persistence events within 15 minutes to 2 hours after the first suspicious login or first suspicious process.
• Check who created the change. Is it the same user as the login? Or is it a different identity (like SYSTEM spawned by a weird service)?
• Look for “unusual frequency.” A task created once is different from tasks recreated every few minutes.

If you want a deeper look at persistence types and what to look for in Windows logs, see our related post in the same cluster: Windows persistence red flags in Vulnerabilities & Exploits. (Swap the placeholder with your real URL.)

Hypothesis 4: “Outbound network activity grew right when the attacker was active.”

Test whether the suspicious host or account shows network “bursts” right after execution.

• DNS queries for rare domains right after process start.
• Repeated HTTP/S calls to a small set of domains or IPs.
• New proxy patterns or unusual User-Agent strings.
• Connections to uncommon ports or to internal services from unexpected hosts.

Small detail that helps a lot: look at destinations (domains and IPs) and repetition. Attackers often “call home” in a loop. Normal apps might talk once and stop.

Hypothesis 5: “The attacker moved laterally using the same credentials chain.”

If you see a suspicious user logging in to one server, test whether that account later appears on other hosts soon after.

• Check for new admin sessions on file servers or remote management tools.
• Look for Remote Desktop, WinRM, SSH, PsExec-like activity, or admin share access.
• Correlate the timestamps with the endpoint process tree events on the first host.

Timeline tip: if Host A shows execution at 10:13 and Host B shows remote login at 10:18, that’s a near-certain “they moved” pattern unless you can prove a scheduled admin job ran exactly then.

People also ask: Threat hunting 101 quick answers

What’s the difference between threat hunting and incident response?

Threat hunting is proactive or semi-proactive searching for signs of compromise. Incident response is what you do when you already suspect or confirm an incident and you’re focused on containment, eradication, and recovery.

In real life, they blend. You might start with an incident ticket, then hunt backward for the first suspicious access, and then hunt forward for active compromise.

Do I need a SIEM to do threat hunting 101?

You don’t strictly need a SIEM, but you need queryable logs and time-based correlation. A SIEM helps because it normalizes events and gives you faster searches. Without it, you can still hunt using EDR dashboards, Windows event queries, and scripts—but it takes longer and you’ll miss correlations.

If you’re a smaller team, focus on one EDR platform or one log pipeline first. A half-built SIEM with weak sources often wastes time.

How do I find active compromise when alerts are noisy?

Use hypotheses tied to time and behavior, not just alert names. Alerts are noisy because the same event can be normal or malicious. Your job is to decide which story fits the timeline.

For example, a “PowerShell command started” alert is common. But “PowerShell started as a child of Word, ran a script that created a scheduled task, and then made DNS calls to a new domain” is a different story.

What tools should I use in 2026 for log-based hunting?

Use what you already have, then add a lightweight helper where needed. Common tool categories include:

• EDR console for process trees and file/network relationships (Microsoft Defender for Endpoint, CrowdStrike, etc.).
• Sysmon + endpoint event collection when you need extra visibility into process/file/registry events.
• Zeek or DNS logging when your network view is weak.
• Query tools (KQL for Microsoft/Sentinel, Lucene in Elastic, Splunk SPL) to build timelines quickly.
• Case tracking (even a simple ticket with timestamps) so you don’t lose your hunt trail.

My opinion: a timeline you can explain to another analyst beats a fancy hunting UI. When you’re under pressure, clarity wins.

Two mini case studies: log timelines that reveal active compromise

Seeing the timeline makes the pattern stick, so here are two examples based on real hunting shapes I’ve seen. These aren’t full incident reports, but they show how the thinking works.

Case study A: “One odd login” became a two-day takeover

We started with a single alert: a user signed in from a new IP. The first look felt harmless because the login succeeded and MFA passed.

But the timeline showed the next events: five minutes later, the endpoint process logs showed PowerShell started with an encoded command. Within 20 minutes, the host created a scheduled task running a renamed script from a user temp folder. Then the network logs showed periodic outbound DNS queries every 60–90 minutes.

Hypothesis that won: “The attacker is still active.” We proved it by showing continued outbound patterns after business hours for the next day and more suspicious sign-ins from the same account.

Case study B: “Suspicious file upload” was actually lateral movement

Another time, an alert pointed to a file uploaded to a shared drive. Most people stop there. We didn’t.

The timeline linked that upload to a process chain on a workstation: a script downloaded a small binary, executed it, then created a new service on a file server. The file server network logs then showed new outbound connections to the same destination domains we saw earlier.

Hypothesis that won: “The attacker moved laterally using the same credentials chain.” That made containment urgent because the file server became the new control point.

Execution checklist: run Threat hunting 101 in a real shift

If you want this to work when you’re busy, follow a simple hunt checklist and timebox it. You’re not trying to write a novel. You’re trying to answer one key question: is this active compromise?

30-minute first pass (before you go deep)

1. Pick the anchor (the first suspicious event or the alert you don’t trust).
2. Confirm scope: which user, which host(s), which time range.
3. Pull identity events around the anchor (+/− 6–12 hours).
4. Pull endpoint process events for the same host(s) around the anchor (+/− 2–4 hours).
5. Pull network events for those hosts (+/− 2–4 hours).
6. Write down 2–3 hypotheses that the evidence supports.

Next 60 minutes: test hypotheses and decide

1. Prove or disprove account persistence: new sessions, token grants, risky device changes.
2. Prove or disprove execution: parent/child process chains and script execution.
3. Prove or disprove C2-like behavior: repeated outbound calls, odd DNS, periodic connections.
4. Decide action: escalate, contain, or close with a documented “not compromise” outcome.

Timeboxing matters. If you spend 4 hours collecting everything first, you’ll lose the urgent context. Active compromise hunts need early answers and clear next steps.

Threat hunting isn’t magic: limitations you must accept

Logs are not perfect, and threat hunting is only as good as the evidence you can trust. If your endpoint telemetry is missing or your time sync is off, timelines can lie to you.

Two real limitations I’ve hit in 2026:

• Clock drift: if systems aren’t time-synced, event ordering breaks. Fix NTP first, then hunt.
• Coverage gaps: some hosts (shared workstations, unmanaged servers) don’t log process activity well. In those cases, identity and network timelines carry more weight.

Another limitation: encrypted traffic reduces what you see. You’ll rely more on metadata—who talked to what, when, and how often—rather than “what was inside.”

Turn hunt results into better detections (without overfitting)

The best outcome of threat hunting is not just a ticket—it’s better detection logic. You want to take what you learned and reduce the work next time.

But don’t overfit. If you write a detection rule that only works on one domain or one machine name, attackers will dodge it. Instead, build around behavior patterns.

Example improvements you can make after a hunt:

• Alert on “script execution via office child process” plus “creates scheduled task within 60 minutes.”
• Alert on “new token grants for a dormant account” plus “outbound DNS burst.”
• Alert on “remote login to admin tools” plus “service creation on a new host.”

This also helps your future self. If you know the hunt logic, you’ll spot repeats faster.

Conclusion: your next step is one timeline and three hypotheses

Threat hunting 101 works because it’s disciplined: logs → timeline → simple hypotheses → test → decision. Don’t chase every alert. Choose an anchor event, expand in time order, and test behavior that fits an attacker workflow.

Your actionable takeaway for today: take one suspicious identity or host from the last 72 hours, build a timeline across login + process + network, and write down three small hypotheses. If you can confirm active compromise (or confidently rule it out), you’ve done threat hunting—not just alert reviewing.

If you keep going, pair this with the rest of our site’s guidance: check our Threat Intelligence posts for context on attacker tradecraft, and our Vulnerabilities & Exploits articles for how initial access often starts. That combo turns hunting into a system, not a one-off hero moment.

Featured image alt text suggestion: “Threat hunting 101 timeline showing logs for logins, processes, and network activity during active compromise investigation.”