CySA+ Runbook 05 — Network Security Alert Investigation

Runbook Information

Item	Details
Runbook	05
Runbook Name	Network Security Alert Investigation
Track	CompTIA CySA+
Difficulty	Intermediate–Advanced
Primary Role	SOC Analyst / Cybersecurity Analyst
Purpose	Investigate suspicious network activity and determine whether it represents scanning, exploitation, command-and-control, lateral movement, or benign traffic
Primary Systems	SIEM, IDS/IPS, Firewall, Zeek, Suricata, DNS, Proxy, EDR
Primary Data Sources	Network Flows, Zeek Logs, Suricata Alerts, Firewall Logs, DNS Logs, HTTP/TLS Metadata, PCAP
Output	Benign / Suspicious Network Activity / Confirmed Malicious Communication / Escalation
Related Labs	Lab 05, Lab 06, Lab 07, Lab 08, Lab 09, Lab 16, Lab 17, Lab 20

Operational Principle: A network alert is evidence of observed traffic, not automatic proof of compromise. Validate the connection, understand its direction and purpose, correlate it with endpoint and identity activity, and determine whether the traffic is authorized, suspicious, or malicious.

1. Purpose

This runbook provides a repeatable workflow for investigating network security alerts.

The analyst must determine:

What triggered the alert?
      ↓
Who initiated the connection?
      ↓
What system received it?
      ↓
Which port and protocol were used?
      ↓
Was the traffic expected?
      ↓
What did Zeek / IDS / firewall observe?
      ↓
Was DNS involved?
      ↓
Was HTTP or TLS involved?
      ↓
Was scanning or exploitation attempted?
      ↓
Was command-and-control possible?
      ↓
Was lateral movement involved?
      ↓
What hosts are affected?
      ↓
What should be contained?

2. When to Use This Runbook

Use this runbook for:

• IDS/IPS alerts

• suspicious firewall events

• unusual outbound connections

• unusual inbound connections

• network scanning

• port scanning

• service enumeration

• brute-force traffic

• suspicious DNS activity

• beaconing

• command-and-control indicators

• connections to malicious IPs

• connections to suspicious domains

• unusual HTTP requests

• abnormal TLS connections

• lateral movement

• unexpected SMB, RDP, SSH, or WinRM traffic

• unusual data transfer

• potential exfiltration

• malware-related network communication

3. Expected Outcomes

Every investigation should reach one of these outcomes:

Network Alert
      ↓
Investigation
      ↓
├── False Positive
│
├── Benign True Positive
│
├── Authorized Security Activity
│
├── Suspicious Network Activity
│
├── Confirmed Malicious Communication
│
└── Inconclusive — Continue Investigation / Escalate

4. Network Investigation Workflow

Use:

Alert Received
      ↓
Preserve Alert
      ↓
Identify Source
      ↓
Identify Destination
      ↓
Analyze Port / Protocol
      ↓
Validate Connection
      ↓
Review Zeek
      ↓
Review Suricata
      ↓
Review Firewall
      ↓
Analyze DNS
      ↓
Analyze HTTP / TLS
      ↓
Review PCAP if Available
      ↓
Correlate Endpoint
      ↓
Enrich IOCs
      ↓
Determine Scope
      ↓
Assess Threat
      ↓
Contain
      ↓
Escalate
      ↓
Document

5. Step 1 — Record the Original Alert

Capture:

Case ID:

Alert ID:

Alert Name:

Detection Source:

Detection Time:

Source IP:

Source Port:

Destination IP:

Destination Port:

Protocol:

Signature:

Category:

Severity:

Action:

Hostname:

User:

Preserve the original alert and raw event where possible.

6. Step 2 — Understand Why the Alert Fired

Ask:

Which network behavior triggered the rule?

Was it signature-based?

Was it anomaly-based?

Was it reputation-based?

Was a threshold crossed?

Was the traffic blocked?

Was it allowed?

Do not investigate only from the alert title.

7. Step 3 — Determine Traffic Direction

Classify:

Inbound

Outbound

Internal-to-Internal

Unknown

Direction provides immediate context.

Examples:

Internet
   ↓
Internal Server

may represent inbound attack activity.

Internal Endpoint
      ↓
Rare External IP

may represent outbound malware communication.

Internal Host
      ↓
Internal Server

may represent legitimate service access or lateral movement.

8. Step 4 — Identify the Source System

Record:

Source IP:

Hostname:

Asset Type:

Operating System:

User:

Business Owner:

Asset Criticality:

Network Segment:

Determine whether the source is:

Corporate Endpoint

Server

Security Scanner

Network Device

Cloud Workload

Guest Device

Unknown External Host

9. Step 5 — Identify the Destination

Record:

Destination IP:

Hostname:

Asset / Provider:

Port:

Service:

Network Segment:

Business Function:

Criticality:

For external destinations, determine:

Hosting Provider

Cloud Provider

Residential ISP

CDN

Known Business Partner

Unknown Infrastructure

10. Step 6 — Analyze Port and Protocol

Record:

Protocol:

Source Port:

Destination Port:

Expected Service:

Examples:

Port	Typical Service
22	SSH
25	SMTP
53	DNS
80	HTTP
443	HTTPS
445	SMB
3389	RDP
5985 / 5986	WinRM

Ports alone do not prove the application protocol.

11. Step 7 — Determine Whether the Service Is Expected

Ask:

Should this source use this service?

Should this destination expose this port?

Is the connection permitted by policy?

Is this traffic common for the host?

Is the destination part of an approved application?

Unexpected service relationships deserve investigation.

12. Step 8 — Establish the Investigation Window

Example:

Alert Time:
13:45

Initial Window:
13:15–14:15

Then expand as needed.

Look before and after the alert.

13. Step 9 — Review Connection Frequency

Determine:

Connection Count:

First Seen:

Last Seen:

Interval:

Duration:

Bytes Sent:

Bytes Received:

Patterns matter.

For example:

One Connection

differs from:

Connection Every 60 Seconds
for 6 Hours

14. Step 10 — Review Zeek conn.log

Where available, inspect:

Source IP

Destination IP

Source Port

Destination Port

Protocol

Service

Duration

Orig Bytes

Resp Bytes

Connection State

Look for repeated or unusual connections.

15. Step 11 — Interpret Zeek Connection States

Relevant states may help identify:

Successful Connection

Rejected Connection

No Response

Reset Connection

Partial Session

Use the state together with other telemetry.

Do not assume every failed connection is an attack.

16. Step 12 — Review Zeek dns.log

For suspicious sources, identify:

Queried Domain

Query Type

Response

Resolved IP

Timestamp

Determine whether the network alert was preceded by:

DNS Query
   ↓
Connection to Resolved IP

17. Step 13 — Identify Suspicious DNS Patterns

Look for:

Rare Domains

Recently Observed Domains

Long Random-Looking Subdomains

High Query Frequency

Repeated NXDOMAIN

Unusual Record Types

Dynamic DNS

Known Malicious Domains

Rarity alone does not prove malicious activity.

18. Step 14 — Review Zeek HTTP Telemetry

Where unencrypted HTTP metadata is available, review:

Host

URI

Method

User-Agent

Status Code

Referrer

Source

Destination

Look for unexpected downloads, uploads, or application behavior.

19. Step 15 — Review TLS Metadata

For encrypted connections, investigate available:

Server Name / SNI

Certificate Subject

Certificate Issuer

JA3/JA4 or Similar Fingerprints where available

TLS Version

Destination

Metadata can provide useful context even when payload content is encrypted.

20. Step 16 — Investigate Unexpected TLS Destinations

Ask:

Is the SNI expected?

Does the certificate match the destination?

Is this a rare destination?

Is the endpoint expected to communicate with it?

Does threat intelligence identify the infrastructure?

21. Step 17 — Review Suricata Alert

Record:

Signature:

Signature ID:

Category:

Severity:

Source:

Destination:

Protocol:

Timestamp:

Determine whether the alert refers to:

Exploit Attempt

Malware Communication

Scanning

Policy Violation

Suspicious Protocol

Threat-Intel Match

22. Step 18 — Determine Suricata Action

Identify:

Alert Only

Blocked

Dropped

Rejected

Allowed

A blocked exploit attempt has different immediate impact than one that reached the destination.

23. Step 19 — Review Related Suricata Alerts

Search:

Same Source

Same Destination

Same Signature

Same Time Window

A sequence can reveal attack progression.

Example:

Scan Alert
   ↓
Exploit Alert
   ↓
Malware Callback Alert

24. Step 20 — Review Firewall Logs

Determine:

Allowed / Denied

Rule

Source

Destination

Port

Bytes

Session Duration

Firewall evidence can help validate whether traffic actually passed.

25. Step 21 — Review NAT Context

If NAT is involved, identify:

Original Source

Translated Source

Original Destination

Translated Destination

Incorrect NAT interpretation can lead to investigating the wrong asset.

26. Step 22 — Review Proxy / Web Gateway Telemetry

For web traffic, capture:

User

Source Host

URL

Domain

Category

HTTP Method

Response

Bytes

Action

This may identify which user initiated suspicious traffic.

27. Step 23 — Review Packet Capture

If a PCAP is available, analyze it with Wireshark or another approved packet-analysis tool.

Filter using:

ip.addr == <IP>

or:

tcp.port == <port>

Do not replay suspicious traffic.

28. Step 24 — Build a Conversation View

For the suspicious session, determine:

Who initiated?

Was TCP established?

How long did it last?

How much data moved?

Which side sent more?

Was the session repeated?

29. Step 25 — Investigate Network Scanning

Scanning may appear as:

One Source
   ↓
Many Destination Ports

or:

One Source
   ↓
Many Destination Hosts

Determine:

Ports Scanned

Hosts Scanned

Duration

Success Rate

30. Step 26 — Distinguish Authorized Scanning

Before escalating, determine whether the source belongs to:

Vulnerability Scanner

Asset Discovery Tool

Penetration Test

Monitoring System

Approved Security Assessment

Validate against:

Approved Change

Scanner Inventory

Assessment Window

Known Security Team Activity

31. Step 27 — Investigate Brute-Force Traffic

Look for repeated connections to:

SSH

RDP

VPN

Web Login

SMTP Authentication

Other Authentication Services

Correlate network activity with authentication logs.

32. Step 28 — Correlate with Authentication

Example:

Repeated TCP/22 Connections
      ↓
SSH Failures
      ↓
Successful SSH Login

or:

Repeated RDP Connections
      ↓
4625 Failures
      ↓
4624 Success

Network evidence alone cannot confirm credential compromise.

33. Step 29 — Investigate Inbound Exploit Attempts

For inbound alerts, determine:

Was target service exposed?

Was request received?

Was IDS blocking?

Did the server respond?

Did endpoint/server behavior change afterward?

Successful exploitation requires corroborating server-side evidence.

34. Step 30 — Correlate with Endpoint Processes

After suspicious network activity, investigate:

New Processes

Unexpected Child Processes

PowerShell

Shell Activity

File Creation

Service Changes

Example:

Exploit Alert
      ↓
Server Process
      ↓
Unexpected Shell

strongly increases concern.

35. Step 31 — Investigate Outbound Connections

For suspicious outbound traffic, ask:

Which host initiated it?

Which process owned the connection?

Which user was active?

Was DNS queried first?

Is the destination rare?

Is it known malicious?

How much data was sent?

36. Step 32 — Correlate Process-to-Network Activity

Build:

Process
   ↓
DNS Query
   ↓
Domain
   ↓
IP
   ↓
Network Connection

This can turn a generic network alert into endpoint compromise evidence.

37. Step 33 — Investigate Beaconing

Potential beaconing may look like:

Connection
   ↓
Wait 60 Seconds
   ↓
Connection
   ↓
Wait 60 Seconds
   ↓
Connection

Evaluate:

Regularity

Destination

Duration

Packet Size

Process

DNS Context

Threat Intelligence

Periodic traffic is not automatically C2.

Many legitimate applications beacon.

38. Step 34 — Investigate Possible Command-and-Control

Indicators may include:

Repeated Rare External Connection

Known Malicious Infrastructure

Suspicious Domain

Malware Process

Regular Beaconing

Encrypted Connection to Unusual Host

Long-Lived Session

Classify:

C2:
Confirmed / Suspected / Not Observed / Unknown

39. Step 35 — Investigate Internal East-West Traffic

Review unexpected internal communication such as:

Workstation → Workstation

Workstation → Server

Server → Domain Controller

User Endpoint → Many Internal Hosts

This may indicate discovery or lateral movement.

40. Step 36 — Investigate SMB Activity

Look for:

TCP/445

Administrative Shares

File Shares

Multiple Internal Destinations

Correlate with:

Authentication

File Access

Remote Process Activity

41. Step 37 — Investigate RDP Activity

Look for:

TCP/3389

Successful Remote Interactive Login

Unusual Source Host

Privileged Identity

Correlate with Windows logon type:

10

where relevant.

42. Step 38 — Investigate SSH Activity

For SSH:

TCP/22

correlate with:

Failed password

Accepted password

Accepted publickey

sudo activity

43. Step 39 — Investigate WinRM and Remote Administration

Look for:

5985

5986

Remote Service Activity

PowerShell Remoting

Determine whether administration was authorized.

44. Step 40 — Determine Lateral Movement

Use:

Internal Connection
      +
Authentication
      +
Remote Session / Execution
      =
Stronger Evidence

Classify:

Attempted

Successful

Not Observed

Unknown

45. Step 41 — Investigate Potential Data Exfiltration

Look for:

Large Outbound Transfers

Unexpected Uploads

Cloud Storage

FTP/SFTP

Web Upload

Rare External Destination

Long-Lived Sessions

Correlate with endpoint evidence of:

Archive Creation

Sensitive File Access

Data Collection

46. Step 42 — Assess Traffic Volume

Record:

Bytes Sent:

Bytes Received:

Duration:

Session Count:

A large outbound transfer can be significant but should be interpreted relative to the application’s normal behavior.

47. Step 43 — Identify Suspicious IP Indicators

Create an IOC record:

IP:

Direction:

First Seen:

Last Seen:

Ports:

Affected Hosts:

Threat Intelligence:

Confidence:

48. Step 44 — Enrich IPs

Investigate:

ASN

Provider

Country / Region

Hosting Type

Reputation

Associated Malware

Associated Domains

Scanning Reports

First Seen

Last Seen

Do not treat cloud-hosted IPs as malicious solely because they belong to hosting providers.

49. Step 45 — Enrich Domains

Investigate:

Registration Context

DNS

Hosting

Reputation

Associated IPs

Malware Associations

Phishing Associations

Assign confidence.

50. Step 46 — Search Indicators Across the Environment

Hunt:

IP

Domain

Destination Port

URL

TLS SNI

across:

Zeek

Firewall

Proxy

DNS

EDR

Suricata

Determine whether other hosts communicated with the same infrastructure.

51. Step 47 — Build the Network IOC Inventory

Create:

IOC Type	Indicator	Source	Confidence
IP	<IP>	Zeek	High
Domain	<domain>	DNS	High
URL	<URL>	Proxy	High
Port	<port>	Network	Contextual
TLS SNI	<hostname>	TLS	Medium

52. Step 48 — Hunt Behavioral Patterns

Do not rely only on static IOCs.

Search for:

Same Beacon Interval

Same Rare Port

Same Connection Pattern

Same DNS Pattern

Same Internal Scan Pattern

Same Protocol Sequence

Behavioral detection can identify infrastructure changes.

53. Step 49 — Build the Network Timeline

Create:

Time	Source	Destination	Event	Evidence
13:10	WIN01	DNS	Domain query	Zeek
13:11	WIN01	External IP	TCP connection	Zeek
13:11	WIN01	External IP	IDS alert	Suricata
13:20	WIN01	SERVER01	SMB connection	Zeek
13:21	WIN01	SERVER01	Authentication	Windows

Use actual evidence.

54. Step 50 — Determine the Earliest Suspicious Network Activity

The alert may have triggered at:

14:10

but suspicious DNS or connections may have started earlier.

Continue backward until the earliest defensible event is identified.

55. Step 51 — Determine the Last Suspicious Activity

Identify:

Last DNS Query

Last Connection

Last IDS Alert

Last Internal Connection

Determine whether activity remains active.

56. Step 52 — Determine Network Threat Status

Classify:

Active

Contained

Historical

Unknown

Active communication may require urgent containment.

57. Step 53 — Determine Scope

Identify:

Affected Source Hosts

Affected Destination Hosts

Users

Applications

Network Segments

External Infrastructure

Use:

Confirmed Compromised

Suspected Compromised

Exposed / Contacted

Unaffected

Unknown

Do not classify a host compromised solely from one network connection.

58. Step 54 — Assess Confidentiality Impact

Ask:

Was sensitive data transferred?

Were credentials transmitted?

Was data uploaded?

Did the connection reach sensitive systems?

59. Step 55 — Assess Integrity Impact

Ask:

Was exploitation successful?

Were remote changes made?

Was malware delivered?

Were application/server files modified?

60. Step 56 — Assess Availability Impact

Ask:

Was service disrupted?

Was traffic blocked?

Was denial-of-service activity present?

Was a network segment impacted?

61. Step 57 — Determine Alert Classification

False Positive

Detection incorrectly interpreted benign traffic.

Benign True Positive

Traffic occurred as detected but was authorized.

Authorized Security Activity

Examples:

Vulnerability Scan

Penetration Test

Asset Discovery

Suspicious Network Activity

Traffic requires further investigation.

Confirmed Malicious Communication

Evidence supports malicious or unauthorized communication.

62. Step 58 — Assign Severity

Low

Blocked isolated attempt

No successful connection

No compromise evidence

Medium

Suspicious communication

Limited scope

No confirmed compromise

High

Confirmed malware communication

Successful exploitation

C2

Lateral movement

Sensitive-system access

Critical

Widespread C2

Active lateral movement across critical systems

Confirmed data exfiltration

Destructive network activity

Major service disruption

63. Step 59 — Determine Immediate Containment

Potential network containment includes:

Block IP

Block Domain

Block URL

Block Port

Add Firewall Rule

Add IDS/IPS Rule

Isolate Endpoint

Restrict Network Segment

Disable Exposed Service

Block User Session

Only perform actions within authorized procedures.

64. Step 60 — Avoid Overbroad Blocking

Before blocking:

Cloud IP

CDN

Shared Hosting

Public DNS

Major SaaS Provider

validate impact.

Overbroad blocking can cause significant business disruption.

65. Step 61 — Contain the Source Endpoint

If malicious outbound traffic originates from a compromised endpoint, blocking one destination may not be enough.

Consider:

Endpoint Isolation

Identity Containment

Process Termination

IOC Blocking

Enterprise Hunt

66. Step 62 — Contain Inbound Exploitation

For inbound attack activity, potential actions include:

Block Source

Restrict Service

Patch Vulnerability

Apply WAF/IPS Control

Disable Vulnerable Feature

Isolate Affected Server

67. Step 63 — Preserve Network Evidence

Preserve:

Raw IDS Alerts

Zeek Logs

Firewall Logs

DNS Logs

Proxy Logs

PCAP

Threat Intelligence

SIEM Events

Record relevant hashes for exported evidence.

68. Step 64 — Escalation Criteria

Escalate when:

Successful exploitation suspected or confirmed

C2 communication identified

Malware-associated traffic identified

Lateral movement detected

Privileged system involved

Sensitive data transfer suspected

Multiple internal systems affected

Active exfiltration suspected

Critical application targeted

Network activity remains active

69. Network Escalation Template

Use:

Case ID:

Classification:

Severity:

Alert:

Detection Source:

Source IP:

Source Host:

Source User:

Destination IP:

Destination Host:

Destination Port:

Protocol:

Direction:

First Seen:

Last Seen:

Connection Count:

Bytes Sent:

Bytes Received:

DNS:

HTTP / TLS:

IDS Signature:

Firewall Action:

Threat Intelligence:

Endpoint Correlation:

Authentication Correlation:

C2 Assessment:

Lateral Movement:

Potential Exfiltration:

Affected Hosts:

Threat Status:

Containment Performed:

Recommended Action:

Outstanding Questions:

Escalated To:

70. Example Command-and-Control Escalation

Case:
NET-2026-033

Classification:
Suspected Command-and-Control

Severity:
High

Source:
FIN-WIN23

Destination:
Rare external infrastructure

Activity:
The endpoint generated repeated DNS queries
and established periodic TLS connections to
the same destination.

Endpoint Correlation:
The traffic originated shortly after suspicious
PowerShell and malware execution.

Threat Intelligence:
Destination infrastructure has malicious associations.

Scope:
One endpoint confirmed communicating.
Enterprise-wide IOC hunt in progress.

Threat Status:
Active.

Recommended Action:
Isolate FIN-WIN23, block validated infrastructure,
preserve network and endpoint evidence, secure the
affected identity, and escalate to Incident Response.

71. Example Authorized Vulnerability Scan

Classification:
Authorized Security Activity

Alert:
Network Scan Detected

Source:
Approved vulnerability scanner

Destination:
Internal server subnet

Validation:
Source matches the enterprise scanner inventory.

Timing:
Activity occurred during the approved assessment window.

Behavior:
Large number of ports and systems contacted.

Impact:
No unauthorized activity identified.

Disposition:
Close as authorized activity.

Recommendation:
Tune detections using approved scanner context
without completely suppressing visibility.

72. Example Blocked Exploit Attempt

Classification:
Attempted Exploitation — Blocked

Source:
External IP

Destination:
WEB01

IDS:
Exploit signature triggered.

Action:
Traffic dropped.

Web Server:
No suspicious process or file activity identified.

Application:
No related errors or compromise indicators found.

Additional Activity:
No follow-on connections identified.

Severity:
Medium

Disposition:
Monitor and hunt for related activity.

73. Common Analyst Mistakes

Avoid:

Assuming every IDS alert is compromise

Ignoring traffic direction

Ignoring NAT

Treating port number as confirmed protocol

Ignoring DNS

Ignoring endpoint process context

Ignoring authentication evidence

Treating all periodic traffic as beaconing

Relying only on IP reputation

Blocking shared infrastructure without validation

Failing to distinguish scan from exploitation

Failing to distinguish contact from compromise

Ignoring internal east-west traffic

Ignoring data-transfer volume

Looking only at one alert

Ignoring activity before the alert

74. Rapid Network Triage Checklist

□ Original alert preserved

□ Source identified

□ Destination identified

□ Direction determined

□ Port reviewed

□ Protocol reviewed

□ Service expectation validated

□ Investigation window established

□ Connection frequency reviewed

□ Zeek conn.log reviewed

□ DNS reviewed

□ HTTP/TLS reviewed

□ Suricata reviewed

□ Firewall action reviewed

□ Proxy reviewed where relevant

□ PCAP reviewed where available

□ Scanning assessed

□ Brute force assessed

□ Endpoint telemetry correlated

□ Authentication correlated

□ Outbound activity reviewed

□ Beaconing assessed

□ C2 assessed

□ Internal movement reviewed

□ Exfiltration assessed

□ IOCs extracted

□ Threat intelligence checked

□ Environment-wide hunt performed

□ Scope determined

□ Severity assigned

□ Threat status determined

□ Containment considered

□ Escalation decision made

□ Case documented

75. Investigation Documentation Template

# Network Security Alert Investigation

## Case Information

Case ID:

Analyst:

Date:

## Alert

Alert Name:

Detection Source:

Detection Time:

Signature:

Severity:

Action:

## Source

IP:

Hostname:

User:

Asset Type:

Criticality:

Network Segment:

## Destination

IP:

Hostname:

Service:

Port:

Criticality:

Provider / Owner:

## Traffic

Direction:

Protocol:

Source Port:

Destination Port:

First Seen:

Last Seen:

Connection Count:

Duration:

Bytes Sent:

Bytes Received:

## Zeek Analysis

### Connections

Document findings.

### DNS

Document findings.

### HTTP

Document findings.

### TLS

Document findings.

## IDS / IPS

Signature:

Category:

Action:

Related Alerts:

## Firewall

Allowed / Denied:

Rule:

NAT Context:

## Proxy / Web

Document relevant findings.

## PCAP

Document packet-level observations.

## Network Behavior

Scanning:

Brute Force:

Beaconing:

C2:

Lateral Movement:

Potential Exfiltration:

## Endpoint Correlation

Document:
- processes
- files
- alerts
- user

## Authentication Correlation

Document login activity.

## IOC Inventory

Document:
- IPs
- domains
- URLs
- ports
- TLS indicators

## Threat Intelligence

Document enrichment and confidence.

## Enterprise Hunt

Document additional matches.

## Timeline

Create chronological network timeline.

## Scope

Confirmed Compromised:

Suspected:

Exposed / Contacted:

Unaffected:

Unknown:

## Impact

### Confidentiality

### Integrity

### Availability

## Classification

False Positive / Benign / Authorized Security Activity / Suspicious / Confirmed Malicious Communication

## Severity

Low / Medium / High / Critical

## Threat Status

Active / Contained / Historical / Unknown

## Containment

Document actions or recommendations.

## Escalation

Escalated:
Yes / No

Escalated To:

## Outstanding Questions

Document gaps.

## Final Analyst Assessment

Summarize findings.

## Disposition

Close / Monitor / Continue Investigation / Escalate

76. Runbook Validation Checklist

Alert & Context

• Original network alert preserved

• Detection logic understood

• Traffic direction determined

• Source identified

• Destination identified

• Asset criticality reviewed

• Port and protocol analyzed

• Expected service relationship assessed

Flow Analysis

• Investigation window established

• Connection count reviewed

• Duration reviewed

• Bytes sent/received reviewed

• Connection state reviewed

Zeek

• conn.log reviewed

• dns.log reviewed

• HTTP telemetry reviewed where relevant

• TLS metadata reviewed where relevant

IDS / Firewall

• Suricata/IDS signature reviewed

• Related alerts searched

• IDS action determined

• Firewall action reviewed

• NAT context considered

Attack Patterns

• Scanning assessed

• Authorized scanner context checked

• Brute force assessed

• Inbound exploitation assessed

• Beaconing assessed

• C2 assessed

• Internal movement assessed

• Data exfiltration assessed

Correlation

• Endpoint telemetry correlated

• Process-to-network relationship investigated

• Authentication telemetry correlated

• Related hosts searched

• Related users searched

Threat Intelligence

• IPs enriched

• Domains enriched

• Reputation checked

• Confidence assigned

• Shared infrastructure risk considered

Scope & Impact

• Environment-wide IOC hunt completed

• Compromised vs contacted hosts distinguished

• Confidentiality assessed

• Integrity assessed

• Availability assessed

• Threat status determined

Response

• Classification assigned

• Severity assigned

• Containment requirements evaluated

• Evidence preserved

• Escalation criteria evaluated

• Final disposition documented

77. Runbook Summary

A network investigation should not stop at:

IDS Alert
   ↓
Block IP

A professional investigation follows:

Network Alert
      ↓
Source / Destination
      ↓
Port / Protocol
      ↓
Flow Analysis
      ↓
DNS
      ↓
HTTP / TLS
      ↓
IDS / Firewall
      ↓
Endpoint Correlation
      ↓
Authentication
      ↓
Threat Intelligence
      ↓
C2 / Lateral Movement / Exfiltration
      ↓
Scope
      ↓
Containment
      ↓
Escalation

The key operational lesson is:

Network telemetry tells you who communicated with whom, but the strongest investigations combine that evidence with endpoint, identity, and threat-intelligence context to determine what the communication actually means.

What’s Next?

CySA+ Runbook 06 — Ransomware Incident Response

The next runbook focuses on one of the highest-priority incidents a SOC analyst may encounter.

You will build a repeatable operational procedure for:

• ransomware alerts

• mass file modification

• encryption indicators

• ransom-note artifacts

• suspicious execution

• PowerShell activity

• recovery-control interference

• credential abuse

• privilege activity

• lateral movement

• network-share activity

• command-and-control

• possible data exfiltration

• affected-host scoping

• emergency containment

• identity containment

• backup protection

• evidence preservation

• escalation to incident response and leadership

• recovery coordination

The workflow progresses from:

Ransomware Alert
      ↓
Validate Encryption
      ↓
Identify Initial Host
      ↓
Identify Execution
      ↓
Scope Identities / Systems
      ↓
Investigate Lateral Movement
      ↓
Assess Exfiltration
      ↓
Emergency Containment
      ↓
Protect Backups
      ↓
Escalate
      ↓
Eradicate
      ↓
Recover

➡️ Next: CySA+ Runbook 06 — Ransomware Incident Response