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

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

None of the alerts looked urgent on its own.

A failed sign-in. A suspicious PowerShell command. A new inbox rule. An unusual cloud download. A connection to an unfamiliar external host.

Each alert sat quietly in the queue with a Low severity label. Then Agent Foskett put them on one timeline.

Weak signals can become strong evidence when they describe the same sequence.

Build the Timeline Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy correlating five low severity alerts

Five alerts — one story

The severity of each clue mattered less once the analyst discovered they shared the same user, device and timeline.

✓ Correlate shared entities

✓ Build a chronological timeline

✓ Connect identity and endpoint evidence

✓ Reassess the combined risk

Case briefing

09:02 — LOW Repeated failed sign-ins User: m.harris 09:07 — LOW Successful sign-in from unfamiliar IP User: m.harris 09:14 — LOW Suspicious PowerShell execution Device: FIN-LT-044 09:19 — LOW New inbox forwarding rule User: m.harris 09:27 — LOW Unusual cloud file download User: m.harris VIEWED SEPARATELY: Five low-priority alerts VIEWED TOGETHER: Identity access ↓ Endpoint execution ↓ Mailbox persistence ↓ Data access THE STORY IS NO LONGER LOW RISK.

Investigation objective

Recognise when multiple individually weak signals share enough entities, timing and behaviour to form one higher-risk incident.

Investigator's rule

Do not add severity scores. Correlate evidence. Five Low alerts become important because of the story they form, not because Low + Low + Low somehow equals High.

Stage 1 — find the shared entities

Alert	Shared entity	Possible relationship
Failed sign-ins	m.harris	Possible credential targeting
Unfamiliar successful sign-in	m.harris	Possible account access
PowerShell execution	FIN-LT-044 / m.harris	Possible endpoint activity after access
Inbox forwarding rule	m.harris	Possible persistence or mail collection
Cloud file download	m.harris	Possible data access

Correlation starts with pivots

Usernames, devices, IP addresses, processes, URLs and timestamps are not just alert details. They are the pivots that let you discover whether separate detections belong together.

Shared user does not prove one incident

A busy employee can legitimately generate many unrelated events. Correlation becomes stronger when identity overlap is supported by timing, device and behavioural sequence.

Stage 2 — inspect the identity timeline with KQL

Start with the affected identity and reconstruct the sign-in activity surrounding the first alerts.

12345 678910 1112131415

let TargetUser = "m.harris@contoso.com";
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ResultType,
          ResultDescription,
          ConditionalAccessStatus
| order by TimeGenerated asc

Sequence matters

Repeated failures followed minutes later by a successful sign-in from the same unfamiliar source can be more meaningful than either observation viewed alone.

Successful activity changes the question

Once authentication succeeds, triage should move from “Was someone trying?” toward “What happened after access was obtained?”

Stage 3 — pivot from identity to endpoint

09:02 Failed authentication attempts ↓ 09:07 Successful unfamiliar sign-in ↓ 09:11 User session active ↓ 09:14 PowerShell on FIN-LT-044 ↓ 09:15 External network connection THE ENDPOINT ALERT IS NO LONGER AN ISOLATED POWERSHELL EVENT. IT NOW SITS DIRECTLY AFTER SUSPICIOUS IDENTITY ACTIVITY.

Stage 4 — inspect endpoint behaviour

12345 678910 1112131415

let TargetDevice = "FIN-LT-044";
DeviceProcessEvents
| where Timestamp > ago(24h)
| where DeviceName =~ TargetDevice
| where AccountName =~ "m.harris"
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine
| order by Timestamp asc

Cross-domain evidence is powerful

Identity telemetry and endpoint telemetry are produced by different parts of the environment, but an attacker crosses those boundaries naturally. The analyst must do the same.

Do not force correlation

Events occurring close together are not automatically related. Require meaningful shared entities or a plausible behavioural connection before combining them.

Stage 5 — the complete timeline

09:02 Multiple failed sign-ins LOW ↓ 5 MINUTES 09:07 Successful unfamiliar sign-in LOW ↓ 7 MINUTES 09:14 Suspicious PowerShell LOW ↓ 5 MINUTES 09:19 Inbox forwarding rule created LOW ↓ 8 MINUTES 09:27 Unusual cloud file download LOW ------------------------------------------------ INDIVIDUAL VIEW Five weak signals CORRELATED VIEW Possible credential compromise ↓ Successful account access ↓ Endpoint execution ↓ Mailbox persistence ↓ Potential data collection ONE HIGH-RISK STORY

The timeline creates meaning

No individual alert has to prove the entire attack. Each event contributes evidence to a sequence that becomes more concerning as independent signals align.

Confidence should rise for a reason

Confidence rises because multiple telemetry sources support a coherent hypothesis — not simply because there are more alerts.

Stage 6 — decide whether to group the alerts

Correlation evidence	What it tells you
Same identity across four alerts	Strong shared entity
Endpoint activity tied to the same user	Connects identity and device evidence
All events occur within 25 minutes	Supports a common sequence
Behaviour progresses logically	Authentication → execution → persistence → data access
No known business activity explains the sequence	Reduces benign alternatives

Correlation is strongest when entities, time and behaviour all agree.

Stage 7 — build the weak-signal triage workflow

LOW-SEVERITY ALERT ↓ IDENTIFY ENTITIES ↓ SEARCH NEARBY ALERTS / EVENTS ↓ SHARED USER? SHARED DEVICE? SHARED IP? ↓ BUILD TIMELINE ↓ DO EVENTS FORM A PLAUSIBLE SEQUENCE? ↓ CHECK ACROSS IDENTITY / ENDPOINT / CLOUD ↓ REASSESS COMBINED RISK ↓ GROUP + ESCALATE WHEN EVIDENCE SUPPORTS IT

Write the triage finding

TRIAGE FINDING Five Low-severity alerts were initially present as separate items in the SOC queue. Correlation identified the same user across authentication, mailbox and cloud activity, with endpoint activity on FIN-LT-044 associated with the same identity. The events occurred within a 25-minute window and formed a coherent sequence: Failed authentication → successful unfamiliar access → PowerShell execution → inbox forwarding rule → unusual file download DECISION Group the alerts into one incident and escalate for immediate investigation. The escalation is based on correlated evidence and attack progression — not the individual severity labels.

Lesson 17 key takeaways

Low-severity alerts can become important when they form one coherent security story.
Do not mathematically add severity scores — correlate evidence.
Users, devices, IP addresses and timestamps are powerful pivots between alerts.
Build a timeline before deciding whether separate detections belong together.
Identity, endpoint, mailbox and cloud evidence can all contribute to one incident.
Shared entities alone are not enough; timing and behavioural progression also matter.
Successful authentication should trigger investigation of what happened next.
Cross-domain evidence can materially increase confidence.
Do not force unrelated alerts into a single incident merely because they occurred close together.
Reassess operational priority when correlated evidence reveals a higher-risk sequence.

Module 2 — alert triage

You have now turned five weak signals into one defensible incident story. Next, Agent Foskett faces a different problem: the incident queue is growing faster than the SOC can clear it.

Next: Lesson 18 — The Incident Queue Was Growing Faster Than We Could Clear It

Continue your SOC Analyst training

Module 2 focuses on alert triage, weak-signal correlation, context 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

Correlate weak signals across identities, devices and services before deciding how serious the incident really is.

← Previous lesson

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

✅ Current lesson

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

Next lesson →

Lesson 18 — The Incident Queue Was Growing Faster Than We Could Clear It Prioritise under pressure without simply sorting by severity.

How SOC analysts correlate low-severity security alerts

Lesson 17 of the Agent Foskett SOC Analyst Academy teaches analysts how to connect multiple low-severity alerts across identity, endpoint, mailbox and cloud activity into a higher-risk incident when the evidence supports correlation.

KQL weak-signal correlation and SOC investigation

Learn how to use Microsoft security telemetry and KQL to investigate authentication and endpoint activity, build a timeline, identify shared entities and reassess incident priority when weak signals form one coherent attack story.