Agent Foskett Academy • SOC Analyst Academy • Module 2 • Lesson 16 • Alert Triage

Lesson 16 — The Alert Arrived During a Known Change Window

It was 10:18 PM when a security alert appeared on a production server.

The change calendar showed an approved maintenance window from 10:00 PM until midnight. That seemed to explain everything — administrators were working on the server, so unusual activity was expected.

But an approved change window explains when activity may occur. It does not automatically explain what occurred.

Change context can lower uncertainty. It should never switch off investigation.

Validate the Change Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy investigating an alert during a change window

The timing matched

Now the analyst must establish whether the user, device, command and resulting behaviour match the approved work too.

✓ Confirm the change record

✓ Match users and assets

✓ Compare expected actions

✓ Investigate unexplained differences

Case briefing

22:18 — MEDIUM ALERT DEVICE APP-PROD-07 ALERT Suspicious PowerShell execution ACCOUNT admin.deploy COMMAND PowerShell launched with an encoded argument CHANGE CALENDAR CHG-4821 22:00 — 00:00 Production application upgrade APP-PROD-07 Approved engineer: admin.deploy INITIAL REACTION "KNOWN CHANGE — CLOSE ALERT" BUT THE CHANGE RECORD SAYS: Expected activity: Deploy application package Restart application services Validate service health IT DOES NOT MENTION ENCODED POWERSHELL.

Investigation objective

Use change-management information to accelerate triage while validating that the observed security activity actually matches the approved work.

Investigator's rule

A change window is context, not a security exception. Approved maintenance does not make every action during that period legitimate.

Stage 1 — validate the change record

Change detail	Question for the analyst
Time window	Did the alert occur within the approved start and finish times?
Assets	Is the affected device actually listed in the change?
Implementers	Does the account involved belong to an approved engineer or service?
Planned actions	Does the command or process behaviour match the documented work?
Expected network activity	Were downloads, repositories or remote connections part of the implementation?
Change status	Was the work actually underway, cancelled, completed or rolled back?

The timestamp is only one match

An alert occurring during maintenance is useful context, but time alone is weak evidence. Attackers do not avoid approved change windows.

Specific change records are valuable

The more clearly a change documents assets, implementers and expected actions, the easier it becomes for the SOC to distinguish expected administration from unexplained behaviour.

Stage 2 — compare the observed execution with the approved work

APPROVED CHANGE User: admin.deploy Device: APP-PROD-07 Window: 22:00 — 00:00 Expected: Deploy package Restart service Run health check VS SECURITY TELEMETRY User: admin.deploy ✓ Device: APP-PROD-07 ✓ Time: 22:18 ✓ Observed: Encoded PowerShell ? THREE THINGS MATCH. ONE IMPORTANT THING STILL NEEDS EXPLAINING.

Partial matches are not complete explanations

The correct user on the correct server at the correct time can still perform an unexpected action — accidentally, legitimately, or maliciously.

Ask the change owner

Operational validation can be evidence. If the engineer confirms the exact command and its purpose, record that. If they say, “I didn't run that,” the priority changes immediately.

Stage 3 — inspect the execution with KQL

Use endpoint telemetry to establish the command, parent process and account around the alert.

12345 678910 1112131415

let TargetDevice = "APP-PROD-07";
let WindowStart = datetime(2026-08-23 22:00:00);
let WindowEnd = datetime(2026-08-24 00:00:00);
DeviceProcessEvents
| where Timestamp between (WindowStart .. WindowEnd)
| where DeviceName =~ TargetDevice
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

The whole window matters

Looking only at the alert timestamp can hide the sequence. Review activity before and after it so you can see whether the command fits naturally into the maintenance workflow.

Expected tools can still be abused

PowerShell, remote administration and deployment tools may all be normal during maintenance. Validate how they were used rather than treating the tool name as benign or malicious.

Stage 4 — the sequence reveals the difference

22:05 Approved deployment tool starts 22:07 Application package copied 22:11 Application service stopped 22:14 New version installed 22:16 Application service restarted 22:18 PowerShell launches encoded command ↓ Creates file in Temp directory ↓ Connects to unfamiliar external host 22:21 Normal health-check script runs THE MAINTENANCE EXPLAINS MOST OF THE TIMELINE. IT DOES NOT EXPLAIN THE 22:18 SEQUENCE.

Look for the unexplained event

Most of the activity may be legitimate. The analyst's job is to identify the part that does not fit the approved change and investigate that difference.

Do not dismiss mixed activity

A legitimate maintenance session and malicious activity can coexist. Attackers may exploit administrative access, stolen credentials or tools already present during the change.

Stage 5 — investigate follow-on network activity

12345 678910 111213141516

let TargetDevice = "APP-PROD-07";
DeviceNetworkEvents
| where Timestamp between (
    datetime(2026-08-23 22:00:00) ..
    datetime(2026-08-24 00:00:00)
)
| where DeviceName =~ TargetDevice
| where InitiatingProcessFileName =~ "powershell.exe"
| project Timestamp,
          RemoteIP,
          RemoteUrl,
          RemotePort,
          InitiatingProcessAccountName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Compare destinations with the change

If the change required downloads from an approved repository, those destinations should be explainable. An unrelated external destination deserves separate validation.

Use operational context carefully

A change ticket, engineer statement and deployment record can all strengthen the investigation. None should override contradictory security telemetry.

Stage 6 — change-window triage workflow

ALERT DURING CHANGE WINDOW ↓ CONFIRM CHANGE EXISTS ↓ MATCH TIME ↓ MATCH DEVICE ↓ MATCH USER / IMPLEMENTER ↓ MATCH EXPECTED ACTIONS ↓ COMPARE PROCESS / COMMAND / NETWORK ACTIVITY ↓ EVERYTHING EXPLAINED? ↓ YES → DOCUMENT + CLOSE / TUNE AS APPROPRIATE NO ↓ ISOLATE THE UNEXPLAINED BEHAVIOUR ↓ INVESTIGATE / ESCALATE

The change ticket explains expected work. The logs still decide whether the observed behaviour fits.

Stage 7 — write the triage finding

TRIAGE FINDING The alert occurred during approved change CHG-4821 on APP-PROD-07. The account, device and timing matched the approved maintenance activity. However, an encoded PowerShell command at 22:18 created a temporary file and initiated an external connection not documented in the change plan. DECISION Do not dismiss the alert based solely on the maintenance window. Escalate the unexplained 22:18 activity for further investigation while preserving the approved change activity as legitimate context.

Lesson 16 key takeaways

An approved change window is useful context, not an automatic security exception.
Validate the change time, assets, implementers and expected actions.
The correct user, device and timestamp do not explain an unexpected command by themselves.
Compare security telemetry with the actual scope of the approved work.
Use KQL to reconstruct activity across the full maintenance window.
Legitimate administrative tools can still be used in suspicious ways.
Look specifically for events that do not fit the expected change sequence.
Legitimate maintenance and malicious activity can coexist.
Operational statements are evidence, but they should not override contradictory telemetry.
Document exactly which activity was explained and which activity remains unresolved.

Module 2 — alert triage

You have now learned to use change-management context without allowing it to prematurely close an investigation. Next, Agent Foskett looks at five individually weak alerts that become far more serious when placed on the same timeline.

Next: Lesson 17 — Five Low-Severity Alerts Formed One High-Risk Story

Continue your SOC Analyst training

Module 2 focuses on alert triage, change context, asset criticality, recurrence and defensible priority decisions.

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 2: Alert Triage — Deciding What Matters First

Use approved change context without automatically dismissing suspicious security behaviour.

← Previous lesson

Lesson 15 — The Device Was a Server, Not a Workstation Adjust triage when asset function changes potential impact.

✅ Current lesson

Lesson 16 — The Alert Arrived During a Known Change Window Use change context without automatically dismissing suspicious behaviour.

Next lesson →

Lesson 17 — Five Low-Severity Alerts Formed One High-Risk Story Correlate weak signals during triage.

SOC alert triage during approved change windows

Lesson 16 of the Agent Foskett SOC Analyst Academy teaches analysts how to use maintenance and change-management context when investigating security alerts without automatically treating activity as benign.

KQL investigation during maintenance windows

Learn how to use Microsoft Defender XDR DeviceProcessEvents and DeviceNetworkEvents to reconstruct activity during an approved change window and identify commands, processes and network connections that do not match the expected work.