Understanding Data

A threat hunter makes a living from understanding data. All kinds of data.

Understanding data is not the same as recognising a field name or knowing a query language. It means knowing where a record came from, what produced it, what each field represents, which transformations occurred, and what the source cannot tell you.

Only then can we use counts, patterns, rarity, relationships, and anomalies without turning convenient shapes into false conclusions.

Questions to ask before analysing

I find it useful to establish a small source profile for the data source:

Null, missing, and absent are not the same

Terminology and representation vary by platform. In this note, I use the following analytical distinctions:

None of them proves that an action did not occur. Before interpreting absence, verify that the source was capable of observing the action, was healthy at the time, retained the event, and was queried correctly.

Filtering and sampling can reshape a distribution. If a connector begins dropping common events while retaining high-severity records, rare values may appear proportionally more common even though the underlying behaviour has not changed. Cardinality also deserves care: timestamps, random identifiers, inconsistent casing, full command lines, and parser variations can create artificial rarity. Normalise only when the transformation is understood, and keep a path back to the original value.

Searching with intent

Searching is bread and butter for a threat hunter. We search in order to find, but jumping into a large dataset without a question can consume hours while producing very little understanding.

You do not simply query into Mordor.

Roger Johnsen

Before searching, write down:

1. The observation or hypothesis that brought you to the data.
2. The entity you are following, such as an account, process, device, session, file, or network relationship.
3. The initial time window and why it is appropriate.
4. The fields needed to inspect individual records.
5. What result would support, weaken, or refute the hypothesis.
6. Which other source could corroborate the finding.

A query can return exactly what you asked for and still answer the wrong question.

An OODA-inspired hunting workflow

The workflow below is a deliberate hunting adaptation of John Boyd’s OODA concept, not a complete representation of Boyd’s model. It gives us a useful way to approach an unfamiliar source through Observe, Orient, Decide, and Act. The value is not the acronym itself. The value is accepting that understanding develops through repeated cycles.

Observe

Start close to the raw records.

Orient

Place the observations in their operational context.

Decide

Choose the next question, not the final verdict.

Act

Perform the next bounded action.

Restarting the loop is not failure. It is how the model is intended to work.

Keep a record of each loop

Grouping and clustering

The terms are often used interchangeably, but they answer different questions.

Grouping

Grouping applies explicit keys or criteria chosen by the analyst.

Examples include:

• events by account and destination
• connections by process and remote domain
• files by hash and device
• authentication attempts by source, target, and logon type
• observations in fixed time windows

The analyst decides what makes records belong together. This makes grouping reproducible, but the chosen key can hide important variation. Grouping only by account, for example, can conceal differences between source systems and session types.

Clustering

Clustering brings observations together based on similarity across selected features. It can be algorithmic, visual, or exploratory. The boundaries are inferred from the data and method rather than defined only by a fixed key.

Possible features include:

• event frequency and timing
• command-line tokens
• process ancestry
• destination or certificate characteristics
• byte counts and connection duration
• identity, device, and application behaviour

A cluster is not automatically a threat. It is a set of observations that look similar according to the selected features, distance measure, preprocessing, and parameters.

Stack counting

Stack counting means counting the occurrences of each distinct value in a field, sorting the result, and inspecting both the common and rare ends of the distribution.

Useful fields include:

• process names
• parent-child process relationships
• command-line fragments
• user agents
• destination domains
• service names
• file extensions
• authentication methods
• error and status codes

The count is a lead. It does not tell you whether the value is legitimate or malicious.

The following illustrative distribution shows user-agent families:

The same data in a table is easier to annotate:

A rare value can be interesting, but rarity is not maliciousness. A common value can also be abused or spoofed. Follow the value into identity, process, device, destination, and historical context.

Questions after counting

• Is the value rare globally, or only for this peer group?
• Is it new, or merely infrequent?
• Did collection or parsing change?
• Is the value user-controlled or easy to spoof?
• Does the count represent events, sessions, devices, or alerts?
• Can one noisy entity dominate the total?
• What raw records sit behind the count?
• What happened immediately before and after?

Baselining

Baselining is the practice of describing expected behaviour for a defined entity, peer group, and period. A baseline is not simply “what happened most often”.

A useful baseline states its scope:

Baselines drift. Roles change, software is deployed, staff travel, infrastructure moves, and logging changes. A baseline must therefore be versioned and reviewed.

Baselining is also something of a unicorn. It is rare, extremely rare, to find a system or network that has been fully baselined and documented. What I usually find are dashboards that explain part of what is going on. I still consider that useful baselining, as long as we are honest about the scope. A partial, documented view is better than an imaginary complete truth.

Baseline and profile

In this book, I use the terms as follows:

A profile describes characteristics and relationships associated with an entity or peer group: usual devices, applications, destinations, working hours, authentication methods, and process relationships. A baseline describes the expected level, range, frequency, or variation of selected behaviour over a defined period.

The two support each other. A profile provides context for choosing a relevant population. A baseline helps identify change within that context. Neither is a permanent definition of what is benign.

Useful summaries

Simple statistics can expose useful questions when their limitations are understood.

Combining summaries can tell a stronger story, but the narrative must remain tied to raw evidence.

A practical workflow

1. Inspect raw records.
2. Write down the source semantics and limitations.
3. Define the entity, population, and time window.
4. Group or count using a deliberate key.
5. Inspect the top, bottom, null, and unexpected values.
6. Pivot back to individual records.
7. Compare with a relevant peer group or historical period.
8. Test technical and legitimate explanations.
9. Corroborate with another data source.
10. Document the query, result, caveat, and assessment.

The objective is not to make data confess. It is to learn what the data can support.

A small hunt from count to assessment

This example shows how the techniques fit together. Assume the hunter wants to identify uncommon process names and investigate one result.

Start with a bounded count:

DeviceProcessEvents
| where Timestamp > ago(7d)
| where ActionType == "ProcessCreated"
| summarize
    EventCount = count(),
    DeviceCount = dcount(DeviceId)
    by FileName
| order by DeviceCount asc, EventCount asc

Suppose mshta.exe appears on one device. That is a lead, not a verdict. Return to the underlying events:

let HuntStart = ago(7d);
DeviceProcessEvents
| where Timestamp > HuntStart
| where ActionType == "ProcessCreated"
| where FileName =~ "mshta.exe"
| project Timestamp, DeviceId, DeviceName, AccountUpn,
    FileName, ProcessCommandLine,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine, SHA1
| order by Timestamp asc

The raw records might show that a browser launched mshta.exe with an external URL. The hunter should now test that interpretation:

1. Confirm that the process event and command line are complete.
2. Check whether the device role or approved software explains the execution.
3. Inspect the parent process and nearby process activity.
4. Pivot to network telemetry for the device, process context, destination, and time window.
5. Look for downloaded or created files and later execution.
6. Compare with similar devices and a longer historical period.
7. Check sensor health and whether the apparent rarity was created by retention or filtering.

If the network and file pivots support the same sequence, confidence may increase. If the activity maps to an approved application used across comparable devices, the hypothesis weakens. If telemetry is missing, the correct result may remain inconclusive.

The important part is not mshta.exe itself. The important part is the movement from aggregate, to raw record, to context, to corroboration, to a bounded assessment.

Resources

• MITRE ATT&CK Detection Strategies
• MITRE ATT&CK Data Components
• PEAK Threat Hunting Framework
• Baseline Hunting with the PEAK Framework
• Check the Stats, Your Threat Hunting is Probably Broken
• John Boyd, A Discourse on Winning and Losing
• NIST IR 8354, Digital Investigation Techniques
• Microsoft Defender XDR DeviceProcessEvents

Revision