Agent Foskett Academy • SOC Analyst Academy • Module 8 • Lesson 75 • Threat Hunting: Looking Beyond the Alerts

Lesson 75 — The Baseline Changed

For thirty days, FIN-WS-117 behaved exactly as expected.

The reporting workflow launched PowerShell every weekday morning.
Same time.
Same parent process.
Same command.
Same account.

Then, on Monday, the pattern changed.

The executions started later.
The command line was different.
A second account appeared.
And one of the processes connected externally.

The baseline had moved.

Agent Foskett looked at the timeline.

“The question isn't whether the baseline changed. It did. The question is why.”

A changing baseline can represent legitimate operational drift, malicious activity, or both. Evidence decides which.

Investigate the Change Back to SOC Analyst Academy

Agent Foskett investigating a changing behavioural baseline

Normal is not permanent.

Environments evolve. The analyst must determine whether the change is expected business drift or security-significant behaviour.

✓ Detect change

✓ Correlate

✓ Validate

✓ Decide

Case briefing

KNOWN BASELINE FIN-WS-117 06:40–07:05 Approved reporting application ↓ powershell.exe ↓ Known command ↓ No external network activity MONDAY 07:18 chrome.exe ↓ powershell.exe ↓ New command ↓ External network connection 07:24 Approved reporting application ↓ powershell.exe ↓ Known command THE OLD BASELINE NO LONGER EXPLAINS ALL THE ACTIVITY.

Investigation objective

Recognise when a previously understood behavioural pattern has changed, identify which dimensions changed, validate legitimate business drift and isolate evidence that cannot be explained by the new operating context.

Investigator's rule

Do not force new evidence to fit an old baseline.

Stage 1 — establish exactly what changed

Baseline dimension	Historical pattern	New observation
Time	06:40–07:05 weekdays	07:18 and 07:24
Parent process	Approved reporting application	Chrome and approved application
Command line	Known reporting command	One new command + known command
Account	Reporting service account	User account + service account
Network	No expected external connection	External connection from PowerShell

Change is multidimensional

A baseline can shift in frequency, timing, account, parent process, command, destination, device population or sequence. Capture the differences before deciding what they mean.

One changed dimension may be benign

A schedule moving from 06:40 to 07:20 could reflect a business change. Several simultaneous changes deserve stronger scrutiny.

Stage 2 — compare old and recent activity

1234567891011121314

DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceName =~ "FIN-WS-117"
| where FileName in~ ("powershell.exe", "pwsh.exe")
| extend Period = iff(
    Timestamp > ago(7d),
    "Recent 7 days",
    "Previous period"
)
| summarize Executions=count(),
            Commands=dcount(ProcessCommandLine)
          by Period, InitiatingProcessFileName, AccountName
| order by Period asc

Compare periods deliberately

Instead of looking only at today's events, compare a recent window against the established historical period. That makes emerging behavioural changes easier to see.

New does not mean malicious

A newly observed parent process or command should be treated as a lead. The next task is to explain it using independent evidence.

Stage 3 — form competing explanations

HYPOTHESIS A LEGITIMATE DRIFT • Reporting application updated • Schedule changed • New script introduced • User interaction now required • Workflow changed by finance HYPOTHESIS B ATTACK ACTIVITY • Browser launched PowerShell • New command not previously observed • User account involved • External connection followed execution HYPOTHESIS C BOTH Legitimate reporting change AND separate malicious activity on the same device. DO NOT PICK ONE YET.

Competing hypotheses prevent tunnel vision

If the analyst decides too early that “the baseline simply changed,” malicious evidence may be rationalised away. If they decide everything new is hostile, normal business evolution becomes noise.

Mixed explanations are common

A legitimate change and an unrelated security event can occur on the same device at the same time. Do not assume one explanation must account for every observation.

Stage 4 — validate legitimate change outside the telemetry

Validation source	What the analyst learns
Change record	Finance reporting application was upgraded Friday evening.
Application owner	New version now runs at 07:20 instead of 06:40.
Deployment records	Updated package was deployed to FIN-WS-117.
Script owner	Approved reporting command remained unchanged.
User interview	User did not intentionally launch PowerShell from Chrome.

Part of the drift is explained

The new schedule is legitimate. The approved application is legitimate. The known reporting PowerShell execution is legitimate.

But not every difference is explained

The Chrome-launched PowerShell process, new command, user account and external network activity remain outside the validated business change.

Stage 5 — split explained drift from unexplained behaviour

07:24 Approved reporting app ↓ PowerShell ↓ Known command ↓ Service account EXPLAINED BY: Approved application upgrade and schedule change ──────────────────── 07:18 Chrome ↓ PowerShell ↓ New command ↓ User account ↓ External connection NOT EXPLAINED BY: Application upgrade THE BASELINE CHANGED. BUT THE CHANGE DID NOT EXPLAIN EVERYTHING.

This is the critical analyst move

Once legitimate drift is validated, remove it conceptually from the suspicious population and continue investigating the residue that remains unexplained.

Do not close the whole case because one change was approved

A valid change ticket can explain specific activity. It does not automatically legitimise every event observed near the change window.

Stage 6 — investigate the unexplained command

12345678

DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName =~ "chrome.exe"
| project Timestamp, DeviceId, DeviceName,
          AccountName, ProcessCommandLine,
          InitiatingProcessFileName
| order by Timestamp asc

Ask whether the new behaviour exists elsewhere

If Chrome-to-PowerShell is truly new on FIN-WS-117, search the broader environment. A matching sequence on other devices may transform a local anomaly into an attack pattern.

History helps classify novelty

Novel within one device, novel within a peer group and novel across the entire environment are different findings. Record which one the evidence supports.

Stage 7 — pivot into follow-on network activity

12345678910111213

DeviceNetworkEvents
| where Timestamp between (
    datetime(2026-09-04 07:15:00) ..
    datetime(2026-09-04 07:25:00)
)
| where DeviceName =~ "FIN-WS-117"
| where InitiatingProcessFileName in~ (
    "powershell.exe", "pwsh.exe"
)
| project Timestamp, DeviceName,
          InitiatingProcessFileName,
          RemoteIP, RemotePort, RemoteUrl
| order by Timestamp asc

Correlate the changed behaviour with consequences

A new command becomes more significant when it is followed by suspicious network activity, file creation, credential access, persistence or lateral movement.

Sequence matters

The strongest conclusion often comes from a chain of related events rather than one changed baseline attribute.

Stage 8 — the environment provides another clue

ENVIRONMENTAL HUNT FIN-WS-117 07:18 Chrome → PowerShell 07:19 External connection FIN-WS-122 07:36 Chrome → PowerShell 07:37 External connection FIN-WS-130 07:51 Chrome → PowerShell 07:52 External connection THREE FINANCE DEVICES SAME NEW BEHAVIOUR WITHIN 34 MINUTES NO APPROVED CHANGE EXPLAINS THIS PATTERN.

The baseline shift is now security-significant

The analyst has moved beyond “this device looks different.” A correlated new behaviour across several comparable endpoints strongly increases the need for incident investigation.

Do not confuse correlation with final attribution

The evidence may support malicious activity without yet proving the attacker, entry vector or exact technique chain. Keep conclusions proportional to the evidence.

Stage 9 — decide what becomes the new baseline

Observed change	Disposition
Reporting task moved to 07:20	Validated legitimate drift — update baseline context.
Approved reporting command remains present	Expected behaviour.
Chrome → PowerShell	Unexplained and correlated across devices.
New user-context command	Suspicious — continue investigation.
External connection from PowerShell	Suspicious follow-on behaviour.

Baselines should evolve only with validated context

Do not absorb new behaviour into “normal” merely because it has occurred repeatedly. Repetition without validation can normalise an attack.

Update the baseline, not the suspicion away

Record the legitimate schedule change while preserving the separate suspicious pattern as investigative evidence.

Stage 10 — write a defensible finding

FINDING: The historical baseline for FIN-WS-117 changed after an approved reporting application upgrade. The new 07:20 schedule and known reporting command are supported by deployment records and application owner confirmation. A separate Chrome-launched PowerShell sequence using a user account and a previously unseen command is not explained by the approved change. Related behaviour was identified on two additional finance devices within 34 minutes, followed by external PowerShell network activity. The validated business drift should be incorporated into the baseline. The separate correlated behaviour requires incident investigation.

Separate facts from interpretation

The strongest report distinguishes validated operational changes from unexplained security-relevant evidence instead of labelling the entire behavioural shift as either benign or malicious.

A baseline is a living reference

Good threat hunting continually updates its understanding of the environment while resisting the temptation to treat every repeated behaviour as normal.

Lesson 75 key takeaways

Normal behaviour changes as environments and business processes evolve.
Identify exactly which baseline dimensions changed.
Several simultaneous changes deserve stronger scrutiny than one isolated difference.
Form competing explanations before choosing a conclusion.
Legitimate drift and malicious activity can coexist.
Validate business changes using independent evidence.
An approved change only explains the activity it actually covers.
Separate validated drift from unexplained residual behaviour.
Search historical and environmental telemetry for new patterns.
Correlate changed behaviour with follow-on activity.
Do not automatically absorb repeated unexplained behaviour into the baseline.
Update baselines when legitimate drift is validated.

Module 8 — Threat Hunting: Looking Beyond the Alerts

Lesson 75 separated validated operational drift from suspicious behavioural change. Lesson 76 moves into another core hunting skill: combining several individually weak signals until they form one much stronger investigative lead.

Next: Lesson 76 — Three Weak Signals Became One Strong Lead

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 8: Threat Hunting: Looking Beyond the Alerts

Build behavioural hypotheses, establish baselines, scope activity and turn successful hunts into repeatable team capability.

← Previous lesson

Lesson 74 — What Does Normal Look Like Here? Build a baseline before declaring an anomaly.

✅ Current lesson

Lesson 75 — The Baseline Changed Separate legitimate drift from attack behaviour.

Next lesson →

Lesson 76 — Three Weak Signals Became One Strong Lead Combine weak behaviours into a stronger hunting candidate.

How do threat hunters investigate a changing behavioural baseline?

Lesson 75 of the Agent Foskett SOC Analyst Academy teaches analysts how to distinguish validated business drift from unexplained security-relevant behaviour when a previously understood baseline changes.

Separating legitimate drift from attack behaviour

Learn how to compare historical and recent Microsoft Defender XDR telemetry, validate approved changes, preserve unexplained evidence, correlate new behaviours across devices and update a baseline without normalising malicious activity.