"Lab 17 — Incident Triage and Evidence Collection"

Mission Information

Item	Details
Lab	17
Lab Name	Incident Triage and Evidence Collection
Track	CompTIA CySA+
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Role	Cybersecurity Analyst / SOC Analyst
Environment	CySA+ SOC Investigation Lab
Primary Systems	SIEM + Windows Endpoint + Linux Server + Analyst Workstation
Skills	Incident Triage, Evidence Collection, Scope Analysis, Severity Classification, Timeline Analysis, Evidence Integrity, Escalation

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

Your SOC receives an alert indicating suspicious activity involving:

CYSA-WIN01
10.10.10.20

The initial detection indicates:

Suspicious Authentication
        ↓
PowerShell Execution
        ↓
Network Communication
        ↓
Potential Malware Activity

At this stage, you do not yet know whether this is:

• a false positive

• expected administrative behavior

• suspicious activity

• a confirmed security incident

Your responsibility is to perform incident triage.

You must quickly determine:

• whether the alert is credible

• which users and systems are affected

• what happened

• when it happened

• how severe the situation is

• which evidence must be preserved

• whether containment should begin

• whether the incident must be escalated

Mission Objective: Perform structured security incident triage, preserve relevant evidence, determine scope and severity, and produce an evidence-backed escalation decision.

Mission Objectives

By completing this lab, you will be able to:

• validate security alerts

• distinguish alerts from incidents

• establish an investigation scope

• identify affected users and systems

• determine incident severity

• collect endpoint evidence

• preserve log evidence

• capture network evidence

• understand volatile evidence

• calculate evidence hashes

• document evidence integrity

• understand chain-of-custody fundamentals

• build incident timelines

• collect indicators of compromise

• recommend containment actions

• make escalation decisions

• produce incident-triage findings

1. What Is Incident Triage?

Incident triage is the initial process used to determine:

Is this real?

How serious is it?

What is affected?

What should happen next?

A simplified workflow is:

Security Alert
      ↓
Validate
      ↓
Scope
      ↓
Collect Evidence
      ↓
Assess Severity
      ↓
Contain?
      ↓
Escalate?

Triage is not always the complete investigation.

Its purpose is to make an informed early decision.

2. Alert vs Event vs Incident

Event

An observable occurrence.

Example:

User logged into a system.

Alert

A detection mechanism identifies activity requiring review.

Example:

Five failed logins followed by success.

Incident

A security event or series of events that requires coordinated response.

Example:

Compromised Account
        ↓
Malware Execution
        ↓
Unauthorized Network Activity

Therefore:

Alert
   ≠
Incident

until sufficient evidence supports escalation.

3. Incident Triage Questions

Begin every triage with:

What happened?

When did it happen?

Where did it happen?

Who was involved?

How was it detected?

What systems are affected?

Is activity ongoing?

What is the potential impact?

What evidence is available?

What action is required now?

These questions keep the investigation focused.

4. Start the Lab Environment

Start:

CYSA-SIEM
10.10.10.40

CYSA-ANALYST
10.10.10.10

CYSA-WIN01
10.10.10.20

CYSA-LINUX01
10.10.10.30

Verify telemetry is available from:

Windows
Linux
Zeek
Suricata
Authentication
Process Activity

5. Create the Investigation Workspace

On CYSA-ANALYST:

mkdir -p ~/CySA-Lab/Investigations/LAB17/{Evidence,Logs,PCAP,Hashes,Screenshots,Findings,Reports}

Create notes:

touch ~/CySA-Lab/Investigations/LAB17/investigation-notes.md

Use:

Incident ID:
LAB17-IR-001

6. Record the Initial Alert

Document:

Alert Name:
Suspicious Endpoint Activity

Affected Host:
CYSA-WIN01

IP:
10.10.10.20

User:
<username>

Alert Time:
<timestamp>

Detection Source:
SIEM

Also capture:

Severity
Rule Name
Detection ID
Source IP
Destination IP
Related Process

where available.

7. Preserve the Original Alert

Capture:

Alert Screenshot

Raw Alert JSON / Event

Detection Rule

Event Timestamp

Do not rely only on screenshots.

Raw evidence is more useful for later analysis.

8. Establish the Investigation Window

Suppose the alert occurred at:

20:30

Use an initial window such as:

20:15–20:45

Then expand if needed.

The principle is:

Alert Time
    ↓
Look Before
    ↓
Look After

You need context around the triggering event.

9. Validate the Alert

Ask:

Did the source telemetry actually exist?

Did the rule interpret it correctly?

Was the behavior expected?

Did multiple data sources observe it?

For example:

SIEM Alert
   +
Windows Event
   +
Zeek Connection

provides stronger evidence than a single rule match.

10. Review Authentication Activity

Search for:

4624
4625
4672

on:

CYSA-WIN01

Identify:

Failed Logins
Successful Logins
Privileged Sessions
Source IP
Username
Logon Type

11. Review Process Activity

Search for:

4688

Look for:

powershell.exe
cmd.exe
rundll32.exe
regsvr32.exe
schtasks.exe

Record:

Process
Parent Process
Command Line
User
Timestamp

12. Review PowerShell Activity

Search for:

4104

where available.

Record:

Script Content
User
Host
Parent Process
Timestamp

Be careful not to conclude malicious intent simply because PowerShell was used.

13. Review Network Activity

Pivot on:

10.10.10.20

Search Zeek telemetry.

Review:

Destination IP
Destination Port
Protocol
Service
Duration
Bytes
DNS
TLS
HTTP

14. Review Suricata Alerts

Search for:

10.10.10.20

in Suricata telemetry.

Document:

Signature
Signature ID
Severity
Source
Destination
Protocol
Timestamp

15. Review Threat Intelligence Context

If suspicious:

IP
Domain
URL
Hash

was identified, enrich it using approved intelligence sources.

Record:

Reputation
Known Associations
Confidence
Internal Matches

16. Determine Whether the Alert Is Credible

Classify:

False Positive

Benign True Positive

Suspicious Activity

Confirmed Incident

Insufficient Evidence

Example:

Alert:
PowerShell Execution

Context:
Approved administrator troubleshooting

Classification:
Benign True Positive

versus:

PowerShell
   +
Unexpected User
   +
Suspicious Domain
   +
Unknown Binary

which warrants deeper investigation.

17. Identify the Primary Asset

Document:

Hostname
IP Address
Operating System
Business Function
Asset Owner
Criticality

Example:

Asset:
CYSA-WIN01

Role:
User Workstation

Criticality:
Moderate

Asset importance affects incident severity.

18. Identify the Primary User

Document:

Username
Privilege Level
Department / Role
Normal Systems
Recent Authentication Activity

Ask:

Is this user expected on this system?

Was privileged access involved?

Did the account authenticate from unusual sources?

19. Determine Initial Scope

Start with:

Primary Host
Primary User
Primary Source IP

Then search for each indicator across the SIEM.

The goal is to determine whether the incident is:

Single Host
Multiple Hosts
Single User
Multiple Users
Environment-Wide

20. Pivot on the Source IP

Search:

<source IP>

Determine:

Which hosts did it contact?

Which accounts did it target?

Which ports were used?

Which alerts reference it?

21. Pivot on the User

Search:

<username>

Determine:

Which hosts did the user access?

What processes were associated?

Was privileged activity observed?

Did authentication occur elsewhere?

22. Pivot on File Hashes

If a suspicious file is involved, search:

SHA-256

across endpoint telemetry.

Determine:

How many hosts contain it?

Was it executed?

When was it first seen?

23. Pivot on Domains

Search:

<suspicious domain>

across:

DNS
Zeek
Proxy
Suricata
Endpoint Telemetry

Identify affected systems.

24. Build an Initial Scope Table

Indicator	Matches	Scope
User	1 host	Limited
Hash	1 host	Limited
Domain	3 hosts	Expanded
Source IP	4 authentication events	Investigate

This table helps determine whether the incident is larger than originally detected.

25. Understand Evidence Types

Incident evidence may include:

Logs
Files
Disk Data
Memory
Network Captures
Processes
Registry Data
Screenshots
Cloud Audit Logs
Authentication Records

Different evidence types have different volatility.

26. Understand Volatile Evidence

Volatile evidence changes quickly or disappears when a system is powered off.

Examples:

Running Processes
Active Network Connections
Logged-In Users
Memory
Open Files
ARP Cache
Temporary Data

This evidence may need to be collected early.

27. Understand Less-Volatile Evidence

Examples include:

Disk Files
Windows Event Logs
Linux Logs
SIEM Events
PCAP Files
Registry Hives
Stored Configuration

These generally persist longer but can still be modified or deleted.

28. Order of Volatility

A simplified concept is:

Most Volatile
     ↓
Memory
Running Processes
Network Connections
Temporary State
Disk Data
Logs
Archived Evidence
     ↓
Less Volatile

Organizations should follow their formal forensic procedures.

29. Collect Process Evidence

On an authorized Windows lab endpoint:

Get-Process |
Select-Object Name, Id, Path

Save:

Get-Process |
Select-Object Name, Id, Path |
Out-File C:\Temp\LAB17-processes.txt

Do not terminate suspicious processes yet unless containment requires it.

30. Collect Network Connection Evidence

Run:

Get-NetTCPConnection

Save:

Get-NetTCPConnection |
Out-File C:\Temp\LAB17-network-connections.txt

This captures live network state.

31. Collect Logged-In User Evidence

Run:

query user

and:

whoami

Record active user sessions.

32. Collect Basic System Information

Run:

hostname

Then:

Get-Date

Then:

Get-ComputerInfo |
Select-Object WindowsProductName, WindowsVersion

This establishes system context.

33. Collect Windows Event Logs

Export relevant logs through Event Viewer or approved commands.

For example:

wevtutil epl Security C:\Temp\LAB17-Security.evtx

Export PowerShell Operational telemetry where available:

wevtutil epl Microsoft-Windows-PowerShell/Operational C:\Temp\LAB17-PowerShell.evtx

Do not clear the original logs.

34. Collect Linux Logs Where Relevant

On CYSA-LINUX01:

sudo cp /var/log/auth.log ~/CySA-Lab/Investigations/LAB17/Logs/

If appropriate:

sudo journalctl --since "1 hour ago" > ~/CySA-Lab/Investigations/LAB17/Logs/linux-journal.txt

Use evidence relevant to your incident scope.

35. Preserve SIEM Evidence

Export or record relevant SIEM events.

Include:

Raw Event
Timestamp
Host
User
Source IP
Destination IP
Event ID
Alert ID

Where possible, preserve the raw event format rather than only copying visible text.

36. Preserve Network Evidence

If a relevant PCAP exists, copy it into:

~/CySA-Lab/Investigations/LAB17/PCAP/

Example:

LAB17-IR-001.pcapng

Do not modify the original capture.

37. Capture a New PCAP If Required

On an authorized monitoring interface:

sudo tcpdump -i <interface> -w ~/CySA-Lab/Investigations/LAB17/PCAP/LAB17-live-capture.pcap

Only collect traffic within your authorized lab scope.

Stop:

Ctrl + C

when sufficient evidence has been collected.

38. Preserve Suspicious Files

If a suspicious file exists, copy it into an evidence directory without executing it.

Example:

Evidence/
└── suspicious-file.bin

Record:

Original Path
Original Filename
Collection Time
Source Host

39. Calculate Evidence Hashes

Calculate SHA-256 for evidence files.

Example:

sha256sum suspicious-file.bin

For a PCAP:

sha256sum LAB17-IR-001.pcapng

For exported logs:

sha256sum LAB17-Security.evtx

Store hashes under:

Hashes/

40. Why Evidence Hashing Matters

Hashing helps demonstrate:

Evidence Collected
      ↓
Hash Recorded
      ↓
Evidence Rechecked Later
      ↓
Hash Matches
      ↓
Integrity Supported

If the hash changes unexpectedly, the evidence may have been modified.

41. Create an Evidence Inventory

Build:

Evidence ID	Item	Source	SHA-256
EVID-001	Security.evtx	CYSA-WIN01	<hash>
EVID-002	PowerShell.evtx	CYSA-WIN01	<hash>
EVID-003	PCAP	Network	<hash>
EVID-004	Suspicious File	CYSA-WIN01	<hash>

42. Understand Chain of Custody

Chain of custody documents how evidence was handled.

It answers:

Who collected it?

When?

Where?

How?

Who accessed it?

Was it transferred?

Was it modified?

A basic chain-of-custody record improves accountability.

43. Create a Chain-of-Custody Record

For each evidence item record:

Evidence ID
Description
Source
Collected By
Collection Time
SHA-256
Storage Location
Transfers
Notes

Example:

Evidence ID:
EVID-001

Description:
Windows Security Event Log

Source:
CYSA-WIN01

Collected:
2026-08-26 20:30

Collector:
SOC Analyst

SHA-256:
<hash>

Location:
LAB17/Evidence/

44. Preserve Original vs Working Copies

Use:

Original Evidence
      ↓
Read-Only / Preserved

and:

Working Copy
      ↓
Investigation

Do not perform analysis directly on the only copy of important evidence.

45. Build the Incident Timeline

Correlate all sources.

Example:

Time	Source	Activity
20:01	Authentication	Multiple failures
20:04	Authentication	Successful login
20:05	Windows	PowerShell launched
20:06	DNS	Suspicious domain queried
20:06	Zeek	External connection
20:07	Suricata	Alert generated
20:08	Endpoint	Suspicious file observed

Your actual events will differ.

46. Identify the Earliest Suspicious Event

Ask:

What is the first event that may be related to the incident?

Do not assume the SIEM alert is the beginning.

For example:

Alert:
20:07

but:

Initial Authentication Failure:
19:58

The incident may have begun earlier.

47. Identify the Latest Suspicious Event

Determine:

Is suspicious activity still occurring?

If the latest event occurred seconds ago:

Potential Active Incident

If activity stopped hours ago:

Historical Incident

This affects response urgency.

48. Determine Incident Scope

Document:

Affected Hosts
Affected Users
Affected Accounts
Indicators
External Destinations
Files
Applications

Classify:

Contained to One Asset

Multiple Assets

Enterprise-Wide Potential

49. Assess Confidentiality Impact

Ask:

Was sensitive data accessed?

Were credentials exposed?

Was unauthorized access obtained?

Was data transmitted externally?

Classify:

None
Low
Moderate
High
Unknown

50. Assess Integrity Impact

Ask:

Were files changed?

Were accounts modified?

Were registry keys changed?

Were security settings changed?

Were logs cleared?

51. Assess Availability Impact

Ask:

Was service disrupted?

Was a system unavailable?

Was ransomware behavior observed?

Was critical functionality affected?

52. Determine Incident Severity

A simple lab model:

Low

Limited suspicious activity
No confirmed compromise
No sensitive impact

Medium

Credible suspicious behavior
Limited scope
No major business impact

High

Confirmed compromise
Privilege activity
Malware
Sensitive system impact

Critical

Multiple critical systems
Major data exposure
Ransomware
Enterprise-wide compromise

Use organizational policy in real environments.

53. Consider Asset Criticality

A compromise involving:

User Training Workstation

may receive different urgency from:

Identity Server
Payment System
Production Database

Incident severity should reflect both:

Technical Activity
+
Business Impact

54. Determine Whether Containment Is Required

Containment may be appropriate when:

Malware execution confirmed
Account compromise confirmed
Suspicious network activity ongoing
Persistence identified
Multiple systems affected
Data exposure suspected

Possible containment actions include:

Isolate Endpoint
Disable Account
Revoke Sessions
Block Malicious IP
Block Domain
Quarantine File
Disable Service
Restrict Network Access

55. Do Not Destroy Evidence During Containment

Before:

Delete File
Reimage Endpoint
Kill Process
Disable Service

consider whether evidence must first be preserved.

A good response balances:

Stop the Threat
      +
Preserve Evidence

56. Determine Escalation Requirements

Escalate when:

Confirmed compromise
High-value asset involved
Privileged account involved
Malware confirmed
Sensitive data may be affected
Multiple systems involved
Containment required
Legal or regulatory implications exist

57. Create an Escalation Summary

Use:

Incident:
LAB17-IR-001

Status:
Confirmed / Suspected

Severity:
High

Affected Asset:
CYSA-WIN01

Affected User:
user01

Key Evidence:
Authentication anomaly
PowerShell execution
Suspicious network communication

Scope:
One endpoint currently identified

Containment:
Recommended

Escalation:
Incident Response Team

58. Create an IOC Inventory

Document:

Type	Indicator	Source	Confidence
IP	<IP>	Zeek	High
Domain	<domain>	DNS	High
Hash	<SHA-256>	Endpoint	High
User	<username>	Authentication	High
Process	powershell.exe	4688	Contextual

Avoid treating common process names as standalone malicious IOCs.

59. Build an Incident Evidence Map

Conceptually:

User
 ↓
Authentication
 ↓
Endpoint
 ↓
Process
 ↓
Suspicious File
 ↓
DNS
 ↓
Domain
 ↓
IP
 ↓
Network Alert

This helps explain how evidence relates.

60. Mission Challenge — Incident Triage

The SOC provides:

A high-severity alert indicates suspicious authentication, PowerShell execution, and external communication from CYSA-WIN01. Determine whether this is a security incident and what actions should be taken.

Investigate and answer:

1. What triggered the original alert?

2. Is the triggering telemetry valid?

3. Which host is affected?

4. Which user is involved?

5. What source IP initiated authentication?

6. Were authentication failures observed?

7. Was authentication successful?

8. Was the session privileged?

9. Which processes executed?

10. What was the process lineage?

11. What PowerShell activity occurred?

12. Were suspicious files observed?

13. Which hashes were identified?

14. Was suspicious DNS activity observed?

15. Were external network connections present?

16. Did Zeek confirm the activity?

17. Did Suricata generate alerts?

18. What threat intelligence exists?

19. Are additional hosts affected?

20. Are additional users affected?

21. Is suspicious activity ongoing?

22. What evidence must be preserved?

23. What hashes were calculated?

24. What is the incident severity?

25. Should containment begin?

26. Should the incident be escalated?

61. Document Your Findings

Update:

~/CySA-Lab/Investigations/LAB17/investigation-notes.md

Use:

# LAB17 Incident Triage

## Incident ID

LAB17-IR-001

## Initial Alert

Document:
- alert
- time
- severity
- detection source

## Affected Assets

Document:
- host
- IP
- role
- criticality

## Affected Users

Document:
- account
- privilege
- normal activity

## Authentication Evidence

Document:
- failures
- success
- source
- logon type
- privilege

## Process Evidence

Document:
- process
- parent
- child
- command line
- timestamp

## Network Evidence

Document:
- DNS
- destination IP
- port
- protocol
- Zeek
- Suricata

## File Evidence

Document:
- filename
- path
- SHA-256
- source host

## Threat Intelligence

Document relevant IOC enrichment.

## Scope

Document:
- hosts
- users
- indicators
- systems

## Evidence Inventory

List all preserved evidence and hashes.

## Timeline

Build the complete incident sequence.

## Impact

### Confidentiality
None / Low / Moderate / High / Unknown

### Integrity
None / Low / Moderate / High / Unknown

### Availability
None / Low / Moderate / High / Unknown

## Severity

Low / Medium / High / Critical

## Containment Decision

Contain / Monitor / Continue Investigation

## Escalation

Escalate / Close / Continue SOC Investigation

## Recommended Actions

Document immediate and follow-up actions.

62. Example Analyst Findings

A simulated assessment might resemble:

Incident:
LAB17-IR-001

Affected Asset:
CYSA-WIN01

Affected User:
user01

Authentication:
Multiple failed authentication events were followed by successful access.

Process Activity:
PowerShell execution was observed shortly after authentication.

Network Activity:
The endpoint queried a suspicious domain and established an external connection.

Network Correlation:
Zeek confirmed the connection.
Suricata generated related telemetry.

File Evidence:
A suspicious file identified during prior malware analysis was observed on the endpoint.

Scope:
One endpoint currently confirmed.
Additional IOC hunting required.

Assessment:
Evidence supports a confirmed simulated endpoint compromise.

Severity:
High

Containment:
Recommended.

Escalation:
Escalate to the Incident Response Team.

Recommended Actions:
Isolate the endpoint, disable or secure the affected identity, preserve evidence, block validated malicious indicators, hunt across the environment, and continue forensic analysis.

63. Evidence to Capture

Capture:

01-initial-alert.png
02-raw-alert.png
03-authentication-events.png
04-successful-login.png
05-privilege-event.png
06-process-execution.png
07-process-tree.png
08-powershell-activity.png
09-network-connections.png
10-zeek-evidence.png
11-suricata-alert.png
12-threat-intelligence.png
13-file-evidence.png
14-file-hash.png
15-event-log-export.png
16-pcap-evidence.png
17-evidence-inventory.png
18-chain-of-custody.png
19-incident-timeline.png
20-scope-analysis.png
21-severity-classification.png
22-escalation-summary.png

64. Validation Checklist

• Initial alert was preserved

• Alert validity was assessed

• Investigation window was defined

• Primary asset was identified

• Primary user was identified

• Authentication telemetry was reviewed

• Process telemetry was reviewed

• PowerShell telemetry was investigated

• Network activity was investigated

• Zeek evidence was correlated

• Suricata evidence was correlated

• Threat intelligence was reviewed

• Investigation scope was established

• Source-IP pivoting was performed

• User pivoting was performed

• Hash pivoting was performed

• Domain pivoting was performed

• Volatile evidence concepts were understood

• Process evidence was collected

• Network connection evidence was collected

• Logged-in users were recorded

• Windows Event Logs were preserved

• Relevant Linux logs were preserved where applicable

• SIEM evidence was preserved

• PCAP evidence was preserved where available

• Suspicious files were preserved safely

• SHA-256 hashes were calculated

• Evidence inventory was created

• Chain-of-custody information was documented

• Original and working evidence concepts were understood

• Incident timeline was constructed

• Earliest suspicious activity was identified

• Latest suspicious activity was identified

• Confidentiality impact was considered

• Integrity impact was considered

• Availability impact was considered

• Severity was assigned

• Containment requirements were assessed

• Escalation decision was documented

• Evidence was captured

65. Mission Review

In this mission, you brought together the investigation skills developed throughout the CySA+ lab series.

You moved from:

Security Alert

to:

Alert
  ↓
Validation
  ↓
Authentication
  ↓
Processes
  ↓
Network
  ↓
Threat Intelligence
  ↓
Scope
  ↓
Evidence Collection
  ↓
Evidence Integrity
  ↓
Timeline
  ↓
Severity
  ↓
Containment
  ↓
Escalation

The key lesson is:

Incident triage is about making the best defensible decision possible with the evidence available at that moment.

A strong triage decision combines:

Validated Telemetry
       +
Scope
       +
Asset Criticality
       +
Evidence
       +
Threat Context
       +
Business Impact
       =
Incident Priority

Skills Developed

After completing this mission, you should be able to:

• perform structured incident triage

• validate SOC alerts

• establish investigation scope

• identify affected assets and users

• pivot across indicators

• collect volatile evidence

• preserve endpoint logs

• preserve network evidence

• preserve suspicious files safely

• calculate evidence hashes

• maintain an evidence inventory

• understand chain-of-custody fundamentals

• correlate multiple security data sources

• construct incident timelines

• assess confidentiality, integrity, and availability impact

• classify incident severity

• recommend containment

• make escalation decisions

• document incident-triage findings

What’s Next?

Lab 18 — Ransomware Incident Investigation

You now know how to validate an alert, determine scope, preserve evidence, assign severity, and decide whether an incident requires escalation.

In the next mission, you will apply these skills to one of the highest-impact incident types faced by SOC and incident-response teams:

Ransomware

You will investigate:

• initial access indicators

• suspicious process execution

• script activity

• file-encryption indicators

• mass file modification

• ransom-note artifacts

• persistence

• credential abuse

• lateral movement indicators

• network activity

• impacted hosts

• affected users

• ransomware IOCs

• incident scoping

• containment priorities

• recovery considerations

• executive incident reporting

The workflow progresses from:

General Incident Triage

to:

Initial Access
      ↓
Execution
      ↓
Privilege / Credential Activity
      ↓
Propagation
      ↓
File Encryption
      ↓
Business Impact
      ↓
Emergency Containment

➡️ Next: Lab 18 — Ransomware Incident Investigation