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

Lesson 5 — What Evidence Do You Collect First?

The alert is no longer just something sitting in the queue. You have enough concern to investigate it properly. Now another problem appears: there may be hundreds or thousands of related events across identity, endpoint, network and cloud telemetry.

You cannot collect everything first. You need to know what matters now, what might disappear, what establishes the timeline and what gives you the best pivots for the next stage of the investigation.

Good investigations do not begin by collecting everything. They begin by collecting the right evidence in the right order.

Build the Evidence Plan Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy planning evidence collection for an incident investigation

The first evidence decision

A suspicious sign-in, PowerShell execution and external connection are now part of the same investigation. Decide which evidence to preserve and examine first before the environment or timeline changes.

✓ Preserve the alert and incident context

✓ Capture volatile identity and endpoint evidence

✓ Establish a narrow investigation timeline

✓ Collect evidence that creates useful pivots

Case briefing

11:02 — INCIDENT ESCALATED User: alex.w@contoso.com Device: FIN-LT-044 Alert: Suspicious PowerShell activity Related sign-in: 10:54 External connection: 11:05 AVAILABLE EVIDENCE Identity sign-ins Endpoint processes Network connections File activity Alert details User context Device timeline Cloud activity THE PROBLEM Where do you start?

Investigation objective

Build an evidence-first workflow that preserves important context, establishes the initial timeline and gives the analyst strong pivots without drowning the investigation in unrelated telemetry.

Investigator's rule

Collect evidence according to investigative value and volatility, not according to which portal you opened first. Your first collection should help answer the next question.

Stage 1 — preserve what triggered the investigation

Before expanding the investigation, capture the original alert and incident context. Later actions, enrichment and automated processing can change what you see.

Capture	Why it matters	Examples
Alert identity	Preserves the detection that started the case.	Alert ID, title, severity, detection source
Entities	Creates the first investigation pivots.	User, device, IP, process, file, URL
Time	Defines the first investigation window.	Alert time, first activity, last activity
Detection evidence	Shows why the security product raised the alert.	Command line, sign-in properties, network destination

Start narrow

A focused window around the alert is easier to reason about than an immediate seven-day data dump. Start close to the event, then widen the timeline when the evidence gives you a reason.

Preserve identifiers

Usernames are useful, but IDs are often stronger pivots. Record device IDs, account identifiers, alert IDs, process IDs and other stable values when they are available.

Stage 2 — collect the identity timeline

If the investigation involves a user account, establish authentication activity around the incident. KQL lets the analyst quickly preserve a focused sign-in view before moving deeper into the case.

12345 678910 11121314151617

let TargetUser = "alex.w@contoso.com";
let StartTime = datetime(2026-08-22 10:30:00);
let EndTime = datetime(2026-08-22 11:30:00);
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          DeviceDetail,
          AuthenticationRequirement,
          ConditionalAccessStatus,
          ResultType
| order by TimeGenerated asc

Why identity comes early

Identity evidence can tell you whether suspicious endpoint activity followed an unusual authentication event, whether the account was active elsewhere and which IP addresses or applications deserve further investigation.

Do not collect only failures

Successful authentication can be more important than failed authentication. The attacker only needs one successful session for the investigation to change completely.

Stage 3 — collect the endpoint timeline

Next, establish what happened on the affected device around the alert. Begin with process activity because process ancestry, command lines and account context often create the pivots that lead to files and network evidence.

12345 678910 1112131415161718

let TargetDevice = "FIN-LT-044";
let StartTime = datetime(2026-08-22 10:30:00);
let EndTime = datetime(2026-08-22 11:30:00);
DeviceProcessEvents
| where Timestamp between (StartTime .. EndTime)
| where DeviceName =~ TargetDevice
| project Timestamp,
          DeviceName,
          AccountName,
          FileName,
          ProcessCommandLine,
          ProcessId,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          InitiatingProcessId,
          SHA1
| order by Timestamp asc

Process evidence creates pivots

A suspicious process may reveal a parent process, command line, file hash or child process. Each can lead to the next evidence source without requiring the analyst to search everything at once.

Context before containment

Urgent containment may be necessary, but understand what evidence could be changed or lost when accounts are disabled, sessions revoked, devices isolated or processes terminated. Response and evidence collection need to work together.

Stage 4 — follow the pivots into network and file evidence

Once the process timeline identifies suspicious activity, use the device, process and time window to collect related network and file events.

12345 678910 111213

let TargetDevice = "FIN-LT-044";
let StartTime = datetime(2026-08-22 10:30:00);
let EndTime = datetime(2026-08-22 11:30:00);
DeviceNetworkEvents
| where Timestamp between (StartTime .. EndTime)
| where DeviceName =~ TargetDevice
| project Timestamp,
          DeviceName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RemoteIP,
          RemotePort,
          RemoteUrl,
          Protocol
| order by Timestamp asc

Follow evidence, not curiosity

If the process contacted an external destination, investigate that destination. If it created a file, investigate the file. Every pivot should have a reason connected to the incident hypothesis.

Widen only when justified

If the first hour reveals earlier execution, persistence or another account, widen the time window. The investigation grows because the evidence requires it, not because a larger query feels more thorough.

Stage 5 — build an evidence collection order

1. PRESERVE THE ALERT Alert ID • entities • timestamps • detection evidence ↓ 2. ESTABLISH IDENTITY CONTEXT Sign-ins • IPs • applications • authentication ↓ 3. ESTABLISH ENDPOINT CONTEXT Processes • command lines • parent/child relationships ↓ 4. FOLLOW DIRECT PIVOTS Network • files • URLs • hashes • additional accounts ↓ 5. ADD HUMAN AND BUSINESS CONTEXT User statement • device owner • expected activity ↓ 6. WIDEN THE TIMELINE WHEN NEEDED ↓ 7. DOCUMENT WHAT EACH ITEM PROVES

Evidence collection should reduce uncertainty with every step.

What should you collect first?

Evidence	Priority	Reason
Original alert and entities	Immediate	Defines why the investigation exists and gives the first pivots.
Relevant sign-in activity	High	Establishes identity context around the incident.
Process timeline	High	Explains execution and exposes parent/child relationships.
Network and file events tied to suspicious processes	High	Shows follow-on behaviour and creates new pivots.
User and business context	Important	Helps distinguish expected behaviour from abnormal activity.
Broad unrelated telemetry	Later	Useful only when the investigation gives you a reason to expand.

Your evidence board

Evidence collected	Question answered	Next pivot
Successful sign-in at 10:54	Was the account active before endpoint execution?	Source IP and device context
PowerShell at 11:02	What executed on FIN-LT-044?	Parent process and command line
External connection at 11:05	Did suspicious execution communicate externally?	Remote IP/URL and initiating process
User statement	Was the activity expected by the user?	Compare with technical evidence

Write the collection note like an analyst

Example: Initial evidence collection preserved the alert details, affected entities and a one-hour investigation window around the suspicious PowerShell activity on FIN-LT-044. Identity telemetry identified a successful sign-in for alex.w eight minutes before execution. Endpoint telemetry was then used to establish process ancestry and command-line context, followed by network telemetry associated with the affected device and time window. Collection was expanded only where evidence created a direct investigative pivot. Further review is required to determine whether the authentication, execution and external connection form one malicious sequence.

Lesson 5 key takeaways

Preserve the original alert, entities and timestamps before expanding the investigation.
Start with a focused time window and widen it when evidence requires you to.
Collect stable identifiers as well as readable names.
Identity evidence can establish what happened immediately before endpoint activity.
Process telemetry is one of the strongest sources of endpoint pivots.
Follow suspicious processes into related network and file evidence.
Do not collect huge volumes of unrelated telemetry simply because it is available.
Consider how containment actions may change the evidence available to you.
Use KQL to answer specific investigative questions, not to generate data for its own sake.
Every collection step should reduce uncertainty or create the next justified pivot.

Module 1 — inside the SOC

You now have a focused evidence set and an initial timeline. The next lesson continues the Module 1 roadmap and develops the analyst's investigation process further.

Continue to Lesson 6 from the SOC Analyst Academy roadmap.

Continue your SOC Analyst training

Module 1 builds the analyst mindset: triage, correlation, user context, evidence collection and defensible decision-making.

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 preserves the right evidence, establishes a timeline and follows justified pivots through an investigation.

← Previous lesson

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

✅ Current lesson

Lesson 5 — What Evidence Do You Collect First? Build an evidence-first workflow before deciding what the incident means.

Next lesson →

Lesson 6 — The Alert Had Five Entities — Which One Do You Pivot On? Choose the most useful user, device, IP, process, file or URL pivot for the next step.

What evidence should a SOC analyst collect first?

Lesson 5 of the Agent Foskett SOC Analyst Academy teaches analysts how to preserve alert context, establish identity and endpoint timelines and follow evidence-led pivots during a Microsoft security investigation.

Evidence collection with Microsoft Sentinel, Defender XDR and KQL

Learn how SOC analysts use focused KQL queries across sign-in, process and network telemetry to collect relevant evidence without overwhelming an investigation with unrelated data.