Agent Foskett Academy • SOC Analyst Academy • Module 1 • Lesson 3 • Inside the SOC

Lesson 3 — Three Alerts Were Actually One Incident

Three alerts are sitting in the queue. One is about a sign-in. One is about PowerShell. One is about an outbound network connection. At first glance, they look like three separate jobs.

Then you notice the same user, the same device and a timeline only minutes apart. The SOC does not need three disconnected investigations. It needs one attack story.

Alerts are individual signals. Incidents are the story those signals tell together.

Build the Incident Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy correlating multiple alerts into one incident

Three alerts, one story

Identity, endpoint and network detections have appeared within minutes. Your job is to decide whether they are independent events or stages of the same developing incident.

✓ Compare users, devices and timestamps

✓ Find shared entities

✓ Build one investigation timeline

✓ Test whether the alerts really belong together

Case briefing

09:14 — ALERT 1 Unusual sign-in User: jordan.m@contoso.com Source IP: 203.0.113.84 09:19 — ALERT 2 Suspicious PowerShell activity Device: FIN-LT-027 User: jordan.m@contoso.com 09:23 — ALERT 3 Suspicious outbound connection Device: FIN-LT-027 Destination: 198.51.100.42 QUEUE VIEW 3 alerts 3 detection types INVESTIGATION VIEW 1 user 1 device 9 minutes THE QUESTION Three alerts — or one incident?

Investigation objective

Recognise when separate alerts describe one attack story and should be investigated together. Learn to correlate shared entities, timestamps and behaviour before treating every detection as an independent case.

Investigator's rule

Do not let product boundaries become investigation boundaries. Attackers move across identity, endpoint, email and cloud systems. The investigation should follow the evidence wherever it goes.

Stage 1 — compare the alerts before assigning them separately

The alert titles do not need to match. Compare the entities, timestamps and behaviours underneath them.

Alert	User	Device	Time	Key evidence
Unusual sign-in	jordan.m	Not yet known	09:14	New source IP
Suspicious PowerShell	jordan.m	FIN-LT-027	09:19	Encoded command
Outbound connection	Process context	FIN-LT-027	09:23	Unexplained external IP

Shared entities create pivots

The same user appears in the sign-in and endpoint activity. The same device appears in the PowerShell and network alerts. Those overlaps give the analyst a reason to test whether the detections belong together.

Time proximity adds context

Events involving the same entities within minutes deserve correlation. Time does not prove causation, but a tight sequence can turn three isolated detections into a much stronger investigation hypothesis.

Stage 2 — build the timeline

09:14 UNUSUAL SIGN-IN jordan.m 203.0.113.84 ↓ 5 minutes 09:19 POWERSHELL EXECUTION FIN-LT-027 jordan.m ↓ 4 minutes 09:23 OUTBOUND CONNECTION FIN-LT-027 198.51.100.42 POSSIBLE STORY Identity access ↓ Endpoint execution ↓ External communication

The timeline does not prove compromise. It does, however, give the analyst a coherent sequence to investigate rather than three unrelated alert titles.

Sequence changes meaning

An unexplained outbound connection may be a weak signal. PowerShell immediately before that connection is more interesting. An unusual sign-in immediately before both changes the context again.

Do not force the story

Correlation is not permission to invent missing steps. The sign-in may be legitimate, PowerShell may be administrative and the connection may be unrelated. The timeline tells you what needs to be tested next.

Stage 3 — find the connecting evidence

Now move beyond time and ask what evidence would directly connect the alerts.

ALERT 1 — SIGN-IN │ ├── Was MFA satisfied? ├── Was the source IP expected? └── What happened after authentication? │ ↓ ALERT 2 — POWERSHELL │ ├── What launched PowerShell? ├── What did the command do? └── Which user/session executed it? │ ↓ ALERT 3 — NETWORK │ ├── Which process opened the connection? ├── Was it PowerShell or a child process? └── What is known about the destination?

Strong correlation

If PowerShell or a child process initiated the outbound connection, the endpoint and network alerts are directly connected. If the same authenticated user context can also be tied to the execution, the incident story becomes stronger again.

Weak correlation

Shared infrastructure can mislead you. Two alerts using the same corporate NAT address, proxy or common service account may have little relationship. Look for meaningful entity links, not merely values that happen to repeat.

Stage 4 — think in incidents, not alert totals

Once evidence supports a relationship, grouping the alerts changes the investigation. Instead of repeating context gathering three times, the SOC can preserve one timeline and one evidence trail.

Alert-by-alert thinking	Incident thinking
Investigate the unusual sign-in separately.	Ask whether identity access preceded endpoint activity.
Investigate PowerShell separately.	Place execution into the same user and device timeline.
Investigate the network alert separately.	Determine whether execution caused the external communication.
Write three separate dispositions.	Build one evidence-backed incident assessment.

Correlation can change priority

Three individually uncertain signals may collectively describe a much stronger attack chain. Correlation can therefore change not only analyst efficiency, but the operational priority of the case.

Correlation improves handover

A coherent incident gives the next analyst a usable story: what happened first, what followed, which entities connect the activity and which links are still unproven.

Stage 5 — separate confirmed links from suspected links

CONFIRMED ✓ jordan.m appears in sign-in and PowerShell activity ✓ FIN-LT-027 appears in PowerShell and network activity ✓ all three detections occurred within nine minutes STILL TO PROVE ? Was the sign-in malicious? ? Did that session lead to endpoint execution? ? What did the PowerShell command do? ? Did PowerShell initiate the external connection? ? What is the external destination? ? Was persistence or credential access attempted? SOC DECISION GROUP FOR JOINT INVESTIGATION

Correlation strengthens the investigation. It does not remove the requirement to prove the important links.

Agent Foskett's alert-correlation workflow

MULTIPLE ALERTS ↓ COMPARE ENTITIES User • Device • IP • Process • Resource ↓ COMPARE TIME Seconds • Minutes • Hours ↓ LOOK FOR SEQUENCE Access → Execution → Network ↓ IDENTIFY DIRECT LINKS Session • Process • Device • Parent/Child ↓ BUILD ONE TIMELINE ↓ TEST ALTERNATIVE EXPLANATIONS ↓ GROUP WHEN EVIDENCE SUPPORTS IT ↓ INVESTIGATE THE INCIDENT

Your incident-correlation evidence board

Question	Why it matters	Status
Do the alerts share a user?	May connect identity and endpoint activity.	Yes — jordan.m
Do the alerts share a device?	May connect execution and network behaviour.	Yes — FIN-LT-027
Are the timestamps close?	Supports a possible sequence.	Yes — nine-minute window
Is there a direct process link?	Could connect PowerShell to the outbound connection.	Not yet proven
Is there a legitimate explanation?	Could weaken the incident hypothesis.	Still to investigate

Write the correlation finding like an analyst

Example: Three alerts initially appeared as separate identity, endpoint and network detections. Correlation identified jordan.m across the unusual sign-in and PowerShell activity, while FIN-LT-027 linked the PowerShell and outbound network detections. All events occurred within a nine-minute window. The alerts have therefore been grouped for joint investigation. Current evidence establishes temporal and entity correlation but does not yet prove that the sign-in caused the endpoint activity or that the external connection was malicious.

Lesson 3 key takeaways

Multiple alerts can describe different stages of one incident.
Compare users, devices, IP addresses, processes, resources and timestamps.
Shared entities provide investigation pivots between detections.
Time proximity strengthens a hypothesis but does not prove causation.
Sequence can turn individually weak signals into a meaningful attack story.
Do not allow security-product boundaries to fragment the investigation.
Group alerts when the evidence supports a shared incident.
Keep confirmed relationships separate from relationships still being tested.
Correlation can increase operational priority and reduce duplicated analyst work.
Investigate the story the evidence tells, not simply the number of alerts in the queue.

Module 1 — inside the SOC

You can now turn several related alerts into one investigation story. The next lesson continues the Module 1 roadmap and develops the analyst's triage and decision-making process further.

Continue to Lesson 4 from the SOC Analyst Academy roadmap.

Continue your SOC Analyst training

Module 1 builds the analyst mindset: triage, alert interpretation, correlation and defensible investigation 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 1: Inside the SOC: Thinking Like an Analyst

Learn how a SOC analyst reads the queue, interprets detections, correlates related activity and builds an evidence-led incident story.

← Previous lesson

Lesson 2 — The Alert Says Suspicious Read the detection claim carefully and separate observed evidence from interpretation.

✅ Current lesson

Lesson 3 — Three Alerts Were Actually One Incident Recognise when separate alerts describe one attack story and should be investigated together.

Next lesson →

Lesson 4 — The User Said “I Didn't Do That” Use user statements as evidence without allowing them to replace technical validation.

How SOC analysts correlate multiple security alerts

Lesson 3 of the Agent Foskett SOC Analyst Academy teaches analysts how to identify shared users, devices, processes, IP addresses and timestamps across separate security alerts and determine when they belong to one incident.

Security alert correlation and incident investigation

Learn how identity, endpoint and network detections can form one attack timeline, how to distinguish correlation from causation and how to document an evidence-based decision to investigate related alerts together.