Lesson 74 — What Does Normal Look Like Here?
The hunt found something unusual.
At least, it looked unusual.
A finance workstation had launched PowerShell six times before 7:00 AM.
That sounded suspicious.
Until another analyst asked whether the same thing happened every morning.
Nobody knew.
Agent Foskett looked at the query results and smiled.
“Before we call something abnormal, perhaps we should find out what normal looks like.”
Unusual compared with what?
Measure frequency, timing, users, devices and peer behaviour before deciding that a difference is security-significant.
Case briefing
Investigation objective
Build a useful behavioural baseline from historical telemetry, compare a candidate against its own history and relevant peers, and decide whether the difference is genuinely meaningful.
Investigator's rule
Rare is not malicious. Common is not safe. Baselines provide context — not verdicts.
Stage 1 — define what you are trying to baseline
| Vague question | Better baseline question |
|---|---|
| Is PowerShell normal? | How often does this device normally execute PowerShell? |
| Is 06:42 unusual? | At what hours does this device normally execute PowerShell? |
| Does finance use PowerShell? | How often do comparable finance workstations show this behaviour? |
| Is this command strange? | Has this device or peer group executed this command pattern before? |
A baseline needs a specific behaviour
“Normal activity” is too broad to measure usefully. Define the event, entity, time period and comparison group you are trying to understand.
Choose a meaningful time window
A seven-day baseline may miss monthly processes. A ninety-day baseline may hide a recent operational change. Choose enough history to represent the behaviour you are testing.
Stage 2 — measure the device's own history
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceName =~ "FIN-WS-117"
| where FileName in~ ("powershell.exe", "pwsh.exe")
| summarize Executions=count()
by Day=bin(Timestamp, 1d)
| order by Day ascStart with frequency
Does the device execute PowerShell every day, once a month or almost never? Frequency provides a first layer of behavioural context.
Zero history is useful — carefully
If the behaviour has not appeared in the available period, the current event is novel within that telemetry window. That does not prove it is malicious.
Stage 3 — baseline the time of day
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceName =~ "FIN-WS-117"
| where FileName in~ ("powershell.exe", "pwsh.exe")
| extend HourOfDay = datetime_part("hour", Timestamp)
| summarize Executions=count() by HourOfDay
| order by HourOfDay ascTime can change the meaning
A process that is routine at 10:00 may be notable at 02:00. But scheduled tasks, batch jobs, backups and users in different working patterns can all create legitimate off-hours activity.
Watch your timezone assumptions
Telemetry timestamps and business working hours may not align automatically. Analysts should understand the time context before labelling activity “after hours.”
Stage 4 — the device history changes the story
Baseline can reduce suspicion
Finding that a behaviour is consistent with historical activity is legitimate evidence. It should change investigative priority when the context is reliable.
Baseline does not equal allowlist
An attacker can imitate or abuse normal tools and schedules. Historical familiarity should never make the analyst stop checking important differences.
Stage 5 — compare the command, not just the process
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceName =~ "FIN-WS-117"
| where FileName in~ ("powershell.exe", "pwsh.exe")
| summarize Executions=count(),
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp)
by ProcessCommandLine
| order by Executions descThe process may be normal while the command is not
PowerShell itself can be routine. A new command line, encoded content, unexpected download behaviour or different parent process may still make today's execution important.
Baseline multiple dimensions
Useful comparisons can include process, command line, initiating process, account, destination, timing, frequency and device role. No single dimension tells the whole story.
Stage 6 — compare against relevant peers
Self-baseline and peer-baseline answer different questions
The device's history tells you whether behaviour is normal for that endpoint. The peer group tells you whether the endpoint itself is behaving differently from comparable systems.
Choose peers carefully
Comparing a finance workstation with domain controllers or developer endpoints produces a weak baseline. Use role, function, user population or other meaningful characteristics where available.
Stage 7 — investigate why the outlier is normal for itself
Business context completes the baseline
Telemetry can show repetition, but it may not explain purpose. Asset ownership, application knowledge, change records and operational schedules can turn a technical pattern into understood behaviour.
Document the explanation
If the SOC repeatedly encounters this behaviour, record the validated context so future analysts can investigate faster without blindly ignoring similar events.
Stage 8 — now change one detail
Attackers can hide inside familiar patterns
The existence of routine PowerShell activity can make malicious PowerShell less noticeable. Compare the complete behavioural pattern, not just the tool name and time.
Baselines should sharpen questions
A good baseline tells you which dimensions are expected and therefore makes deviations in parent process, user, command or network behaviour easier to recognise.
Stage 9 — avoid common baseline traps
| Trap | Why it fails |
|---|---|
| “We saw it before, so it is safe.” | Previous occurrence does not establish legitimacy. |
| “Nobody else does it, so it is malicious.” | Unique business functions create legitimate outliers. |
| “It happened after hours.” | Scheduled processes and work patterns may explain timing. |
| “It is rare.” | Rare events can be benign; common events can be malicious. |
| “Thirty days is enough for everything.” | Seasonal, monthly and newly changed workflows may require different windows. |
Baseline quality depends on data quality
Missing telemetry, short retention, newly onboarded devices or inconsistent coverage can create a false impression of novelty.
Normal changes
Applications are deployed, teams move, scripts change and business processes evolve. A baseline is a model of observed behaviour during a period — not a permanent truth.
Stage 10 — write a defensible baseline finding
Say what the evidence supports
“This is normal” can sound absolute. A stronger finding states what was observed, what historical pattern exists, what context explains it and what limitations remain.
Keep baselines useful for future hunts
Record validated patterns, but revisit them when behaviour changes. Tomorrow's lesson deals with exactly that problem: what happens when the baseline itself moves?
Lesson 74 key takeaways
- An anomaly needs a meaningful comparison point.
- Define the behaviour, entity, period and comparison group before building a baseline.
- Compare an entity against its own historical behaviour.
- Compare the entity against relevant peers when that adds context.
- Frequency, timing, command line, parent process and account can all matter.
- Understand timezone and business-hour assumptions.
- Historical familiarity does not prove activity is safe.
- Peer rarity does not prove activity is malicious.
- Business context can explain legitimate technical outliers.
- Telemetry gaps and retention limits affect baseline confidence.
- Document validated normal patterns without creating blind trust.
- Baselines change as environments and business processes change.
Module 8 — Threat Hunting: Looking Beyond the Alerts
Lesson 74 built a behavioural baseline before declaring activity anomalous. Lesson 75 introduces a harder problem: the baseline has changed, and the analyst must decide whether that change represents legitimate operational drift or attack behaviour.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 8: Threat Hunting: Looking Beyond the Alerts
How do SOC analysts build a behavioural baseline for threat hunting?
Lesson 74 of the Agent Foskett SOC Analyst Academy teaches analysts how to use Microsoft Defender XDR Advanced Hunting and KQL to understand historical behaviour before deciding whether activity is anomalous.
What does normal behaviour look like in a security investigation?
Learn how to compare device history, time of day, command lines and peer groups, incorporate business context, recognise baseline limitations and avoid treating rare activity as automatically malicious.
