Context before Conclusion

Author: Roger C.B. Johnsen:

Introduction

Threat hunts rarely start with complete evidence. Often, it is just a fragment: an IOC from a report, a suspicious process, an unusual login, a file found on disk, a SOC escalation, a red team observation, or a weak anomaly in the data. But a starting point is not a finding. It is the first question. The value of threat hunting lies in building enough context around that fragment to understand what it represents, whether it matters, and which hypothesis it supports or weakens.

An indicator tells you where to start. Context tells you whether it matters.

The Starting Point Is Not the Finding

A threat hunt rarely starts with complete evidence. It may start with an IOC, a suspicious process, an unusual authentication pattern, a threat intelligence report, a SOC escalation, a red team observation, or a weak anomaly in the data.

That starting point is not the finding. It is the first question.

This distinction matters because hunters can become trapped by the wording or shape of the initial observation. If the starting point suggests a specific technique, tool, or behaviour, it is tempting to investigate only that possibility. If the hunter does not find that exact thing, the observation may be dismissed too quickly. That is a weak investigation. The better question is:

What does this observation actually represent?

Not:

Can I confirm the first explanation I was given?

A threat intelligence report may mention a named tool. A SOC escalation may mention a specific technique. A red team note may describe one suspected behaviour. An IOC may point to known infrastructure. None of these are conclusions by themselves. They are starting points.

The hunter must still examine the underlying activity, identify what actually happened, and decide whether the original explanation is supported, weakened, or replaced by a better one.

Context and Behaviour

Suspicion usually appears when behaviour and context do not fit together. A process name may look normal until it appears in the wrong parent-child relationship. A user action may look normal until it comes from a newly hired user with no reason to perform that activity. A file access pattern may look normal until the volume, timing, and role of the user make it strange. A network connection may look normal until it appears immediately after suspicious execution.

The mental model is simple:

Context + Behaviour = Suspicion

The behaviour tells you what happened. The context tells you whether it makes sense. This does not mean that every unusual event is malicious. It means that the hunter should look for the point where behaviour, baseline, role, timing, and environment stop fitting together.

Where Context Comes From

Context is not one thing. It is built from several layers and usually requires more than one data source.

The layers work together. A suspicious IP address may not mean much by itself. But if the IP is contacted by a rare process, from a user workstation, shortly after document execution, and followed by file creation in a user-writable directory, the context changes. The indicator has become part of a story.

The hunter may need endpoint telemetry, identity logs, authentication records, file access logs, DNS, proxy data, network flow, email metadata, asset inventory, vulnerability data, change records, HR role information, or business system knowledge.

The exact sources depend on the observation, but the question is always the same:

Which data can explain whether this activity makes sense?

Useful context often comes from several places.

The goal is not to collect every possible data point. The goal is to collect enough context to test the hypothesis properly.

From Indicator to Context

The basic workflow looks like this:

flowchart LR
    A[Indicator] --> B[Entity Context]
    B --> C[Temporal Context]
    C --> D[Relationship Context]
    D --> E[Environmental Context]
    E --> F[Behaviour]
    F --> G[Hypothesis]
    G --> H[Validation]

The exact order may vary. Sometimes the hunter starts with an entity. Sometimes the starting point is a time window. Sometimes the hunt begins with a known behaviour and the goal is to find where it appears. The value of the model is not that every hunt must follow it perfectly. The value is that it forces the hunter to move from isolated facts toward an explanation that can be tested.

Common Analytical Pitfalls

Context building is not only about adding more data. It is also about avoiding weak analysis. Several pitfalls appear again and again in investigations:

A hunt should not only ask whether something can be confirmed. It should also ask whether the available evidence is good enough to support the conclusion.

Entity Context

Entity context answers the first basic question:

What am I actually looking at?

The entity may be a user, device, account, process, IP address, file, hostname, domain, mailbox, cloud identity, or internal resource. A weak investigation treats the entity as obvious. A stronger investigation asks what the entity represents in the environment:

The same observation can mean different things depending on the entity. powershell.exe on a domain controller is not the same as powershell.exe on a developer workstation. A project manager traversing file shares is not the same as a file server administrator doing the same thing during planned maintenance. Context starts by understanding the entity.

Build the Timeline

Context is temporal. A suspicious observation rarely begins at the moment it becomes visible. The visible event may only be the point where the behaviour surfaced in the data. A hunter should therefore look both backwards and forwards in time.

Ask:

• What happened before the observation?
• What changed shortly before it appeared?
• Which process, user, host, account, or session started the chain?
• What happened immediately after?
• Did the activity continue, stop, spread, or change form?
• Are there related authentication, file, network, process, directory, or cloud events?

A narrow time window may be enough to confirm that something happened, but it is often not enough to understand why it happened. A timeline helps the hunter see whether the observation was isolated or one point in a larger sequence.

The important question is not only:

What did I observe?

It is also:

What story does the surrounding activity tell?

Relationship Context

Threat hunting is often relationship work. The interesting part is not always the entity itself, but how it relates to other entities. A process launched another process. A user accessed a device. A device connected to another device. An account touched many resources. A file was downloaded, written, opened, and executed.

These relationships help the hunter move from isolated events to behaviour.

Relationship context is where many weak signals become stronger. A single file access event may not matter. A newly hired project manager traversing many file shares within a short time window may matter. The difference is not only the event. The difference is the relationship between the user, the role, the resources, the timing, and the volume.

Ask Whether the Activity Makes Sense

Context is also environmental. The same activity can mean different things depending on who performed it, where it happened, and what role the user, device, account, or system has in the organisation.

A project manager traversing many file shares shortly after being hired is different from a file server administrator doing the same thing during planned maintenance. A developer running scripting tools on a build server is different from a finance user running the same tools from a workstation. A service account accessing many systems may be normal, suspicious, or badly designed. The answer depends on what the account is supposed to do.

The hunter should ask:

• Does this activity fit the user’s role?
• Does it fit the device’s purpose?
• Does it fit the department or business function?
• Is this normal for a newly hired user?
• Is the access pattern expected?
• Is the timing normal?
• Is the volume normal?
• Has this user, device, or account done this before?

Suspicion often appears when behaviour and context do not fit together.

Example: File Share Traversal

Consider this observation:

A user accessed many file shares within five minutes.

This may be suspicious. It may also be normal. The observation alone does not answer that. A weak investigation may stop at counting the file shares and deciding whether the number looks high. A stronger investigation builds context.

Now the observation becomes more useful.

A newly hired project manager accessed many unrelated file shares within five minutes from a workstation with no previous history of that access pattern.

That is stronger than:

User accessed many file shares.

The first version describes behaviour in context. The second version describes an event.

Example: PowerShell Execution

Consider this observation:

powershell.exe executed on a workstation.

That may not matter. PowerShell is common. The question is what the execution looks like when placed into entity, relationship, temporal, and follow-on context. A practical pivot flow could look like this:

flowchart LR
    A[powershell.exe] --> B[Process tree]
    B --> C[Parent process: winword.exe]
    C --> D[Recent document activity]
    D --> E[Command line]
    E --> F[File write]
    F --> G[Network connection]
    G --> H[Initial access hypothesis]

The observation can be strengthened step by step.

The original indicator was weak. The contextualised behaviour is much stronger. The goal is not to make every observation suspicious. The goal is to understand which observations become suspicious when placed in the right context.

This is also where the link to detection engineering begins. You do not build a useful detection by simply alerting on powershell.exe. You build better detection logic by understanding the relationship, sequence, and context that make the execution meaningful. See also Hunter to Detection .

When Context Weakens

Context does not always make something more suspicious. Sometimes it explains the activity. A suspicious process may turn out to be part of a software deployment. A strange login may come from a known VPN range. Unusual file access may be part of a migration project. A rare command line may come from an approved admin tool.

This is not failure. It is the hunt doing its job. The purpose of context is not to confirm the first suspicion. The purpose is to test it.

A hypothesis that is weakened by evidence should be refined or rejected. That is good analysis.

When Context Strengthens

Sometimes context makes the observation more suspicious. A single event becomes part of a sequence. A normal tool appears in an abnormal parent-child relationship. A user touches resources outside their role. A device communicates with systems it does not normally contact. A process writes files, spawns children, and connects externally.

The strength of a hunt often comes from combining weak signals. One weak signal may not matter. Several weak signals in the right context may tell a story.

What This Means for Threat Hunters

Threat hunters should not treat indicators as answers. An indicator is a direction of travel. It tells the hunter where to start looking, not what conclusion to reach. The hunter’s job is to build context around the observation:

flowchart LR
    A[Indicator] --> B[Context]
    B --> C[Behaviour]
    C --> D[Hypothesis]
    D --> E[Validation]
    E --> F[Conclusion or Next Pivot]

This means asking better questions:

• What does this observation actually represent?
• Which entities are involved?
• What happened before and after?
• Which relationships does the activity create?
• Does the behaviour make sense in this environment?
• Does context strengthen or weaken the hypothesis?
• What should I pivot to next?

The work is not finished when the indicator is found. The work begins when the indicator is placed in context.

Summary

A single indicator is rarely enough. It may tell you where to start, but it does not tell you what happened, why it happened, whether it matters, or what to do next. Threat hunting turns indicators into context. Context turns isolated observations into behaviour. Behaviour gives the hunter something to test.

The core idea is simple:

An indicator tells you where to start. Context tells you whether it matters.

Resources

• Hunter to Detection
• MITRE ATT&CK
• MITRE ATT&CK - T1059 Command and Scripting Interpreter
• Microsoft Defender Advanced Hunting

Revision