The Threat Hunting Mindset: Think in Attack Paths

Give ten analysts the instruction “hunt for lateral movement” and you may receive ten queries. The useful ones will not begin with a memorized list of event IDs. They will begin with the environment: where an attacker could land, what they could reach, and which route would attract the least attention.

Thinking like an attacker does not mean guessing dramatically or treating every anomaly as hostile. It means viewing the environment as a set of possible paths, then testing those paths with a defender’s discipline.

The mindset in practice

• how attackers reason about paths rather than individual controls;
• why legitimate tools require behavioral context;
• how to turn an imagined attack path into a hunt; and
• how to avoid confirmation bias.

Controls are obstacles; attackers need a route

Defenders often organize knowledge by control: firewall, EDR, identity policy, email gateway. An attacker has a different problem. They need to move from their current position to an objective.

Suppose an attacker compromises a standard user workstation. Their next questions might be:

1. Which credentials or tokens are available here?
2. Which internal systems accept those identities?
3. Which remote administration method blends into normal operations?
4. Where is valuable data stored?
5. How can access survive a password reset or reboot?

Each decision suggests evidence. Credential access may leave process-access or authentication traces. Remote execution may connect a source host, account, destination, logon type, and newly created process. Persistence may create a service, task, registry value, or cloud credential.

The hunter’s job is to translate the route into observable facts.

Legitimate tools are not automatically legitimate behavior

PowerShell, WMI, remote services, scheduled tasks, rundll32, and certificate utilities all have valid administrative uses. Blocking or alerting on the binary name alone produces noise and misses the real question: does this use fit the surrounding context?

Evaluate at least these dimensions:

Dimension	Useful question
Identity	Does this account normally perform the action?
Time	Is the timing consistent with its history and business schedule?
Source	Is the action coming from a normal management host?
Target	Does this identity usually reach this system?
Process	Is the parent-child chain expected?
Command	Are the arguments common for this team and tool?

One unusual dimension is a lead. Several unusual dimensions in the same sequence are more persuasive.

Know your own environment first

You cannot model a realistic attack path through a network you do not understand. Architecture diagrams help, but hunters also need operational truth:

• which service accounts have broad access;
• which systems are administered remotely and from where;
• where endpoint or script logging is weak;
• which scheduled jobs run after hours;
• which exceptions have quietly become permanent; and
• who owns the systems needed to validate unusual activity.

This knowledge is why a locally grounded hypothesis often outperforms a generic checklist.

Turn an attack path into a hunt

Use this five-part pattern:

1. Position: Assume the attacker controls a specific kind of asset.
2. Objective: Name what they are trying to reach or achieve.
3. Likely route: Choose a plausible technique given local controls.
4. Observable evidence: List the telemetry and fields the route would create.
5. Benign alternatives: Write down ordinary explanations before querying.

Example:

If an attacker compromises a help-desk account, they may use an approved remote-management tool to reach executive workstations. We should see that account connecting from an unusual source, outside its normal ticket-driven targets, followed by process activity not associated with the support workflow.

This is stronger than “hunt for remote tools” because it provides an identity, source, target population, expected sequence, and basis for comparison.

Try to disprove yourself

Adversarial imagination without analytical discipline creates false positives. Before escalation, actively search for the strongest benign explanation:

• Was there an approved change or maintenance window?
• Did the account owner change teams?
• Is a software deployment responsible for the process pattern?
• Does the same behavior occur across many known-good systems?
• Is the timestamp or identity field reliable?

Document the evidence that weakens your theory as carefully as the evidence that supports it. A hypothesis is a tool to test, not a conclusion to defend.

A short practice exercise

Choose one important server and imagine that you control a nearby workstation with a standard user account. Without writing a query, map one plausible route to that server. For every step, note:

• the action an attacker would take;
• the control they would encounter;
• the telemetry the action should produce; and
• one benign activity that could look similar.

Only then write the first query. This habit keeps the investigation tied to a coherent story instead of a collection of unrelated suspicious events.

The threat-hunting mindset combines an attacker’s focus on paths with a defender’s insistence on evidence. Imagine the quietest plausible route through your environment, identify what that route must leave behind, and work hard to prove your own interpretation wrong.