Lab 08 Network Security Alert Investigation

Mission Overview

Welcome to Lab 08 — Network Security Alert Investigation.

In Lab 07, you investigated malware and endpoint telemetry to determine whether suspicious code executed and what impact occurred on the endpoint.

Now you will move outward from the host and investigate what the SOC can observe across the network.

Enterprise SOC teams continuously receive alerts from:

• firewalls

• IDS/IPS platforms

• network detection systems

• SIEM correlation rules

• endpoint network telemetry

• VPN infrastructure

• secure web gateways

• DNS security platforms

• cloud network controls

An IDS alert does not automatically mean an attack succeeded.

A firewall connection does not automatically mean compromise.

A blocked connection may actually demonstrate that a security control worked correctly.

Your job is to reconstruct the communication and determine:

Who communicated with whom, over which service, in which direction, whether the traffic was allowed, what triggered the detection, what other evidence supports it, and whether the activity represents normal traffic, suspicious behavior, or a security incident.

Mission Goal: Investigate a simulated network security alert by validating the source, destination, protocol, service, direction, security-control outcome, related host and identity activity, and network scope before assigning an evidence-based SOC disposition.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Network Security Alert Investigation
Secondary Skill	Network Event Correlation
Environment	GoHackersCloud SOC Analyst Lab
Evidence	IDS/IPS + firewall + SIEM + endpoint/network logs
Primary Outcome	Network Alert Investigation Report
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

• interpret network security alerts

• identify source and destination systems

• determine network direction

• analyze source and destination ports

• identify protocols and services

• distinguish IDS detection from attack success

• interpret firewall actions

• distinguish allowed from blocked communications

• determine asset ownership and criticality

• analyze connection frequency

• identify recurring communication patterns

• establish network context

• correlate network alerts with endpoint telemetry

• correlate network alerts with authentication events

• correlate DNS and proxy evidence

• investigate related network alerts

• identify possible lateral communication

• determine network scope

• document positive security controls

• assign severity and confidence separately

• make containment and escalation recommendations

• produce a professional network investigation report

Investigation Methodology

Use:

Network Alert → Source → Destination → Service → Direction → Control Outcome → Context → Correlation → Scope → Disposition

Conceptually:

Network Alert
      │
      ▼
Validate Detection
      │
      ▼
Identify Source
      │
      ▼
Identify Destination
      │
      ▼
Protocol / Port / Service
      │
      ▼
Determine Direction
      │
      ▼
Allowed / Blocked?
      │
      ▼
Asset + User Context
      │
      ▼
Endpoint / DNS / Auth / Proxy
      │
      ▼
Related Connections
      │
      ▼
Determine Scope
      │
      ▼
Disposition

The core principle is:

A network alert tells you that a security control observed something interesting. It does not, by itself, tell you what actually happened.

Part 1 — Create the Investigation Workspace

Create:

SOC-Labs/
└── Lab-08/
    ├── 01-Scope/
    ├── 02-Alert/
    ├── 03-Source/
    ├── 04-Destination/
    ├── 05-Network-Flow/
    ├── 06-Firewall/
    ├── 07-IDS-IPS/
    ├── 08-DNS/
    ├── 09-Endpoint/
    ├── 10-Authentication/
    ├── 11-Correlation/
    ├── 12-Scope/
    ├── 13-Timeline/
    ├── 14-Evidence/
    ├── 15-Findings/
    └── 16-Report/

Create:

Lab-08-Network-Security-Alert-Investigation.md

Part 2 — Open the SOC Case

Example:

CASE ID:
GHC-SOC-2026-008

CASE TITLE:
Network Security Alert Investigation

STATUS:
Investigating

INITIAL PRIORITY:
P2

ANALYST:

DATE:

Part 3 — Review the Initial Alert

Assume the lab provides:

ALERT ID:
ALT-NET-001

ALERT:
Suspicious Outbound Network Communication

SOURCE:
10.10.20.45

DESTINATION:
203.0.113.50

DESTINATION PORT:
443

PROTOCOL:
TCP

ACTION:
Allowed

TIME:
14:32 UTC

INITIAL SEVERITY:
High

Do not immediately conclude:

Outbound connection
      ↓
External IP
      ↓
Compromise

Instead ask:

What system generated this connection, which process or user was responsible, what destination was contacted, why was it detected, and what evidence exists before and after the event?

Part 4 — Preserve the Original Alert

Record:

NETWORK ALERT PROFILE

Alert ID:

Alert Name:

Sensor:

Timestamp:

Source IP:

Source Port:

Destination IP:

Destination Port:

Protocol:

Direction:

Action:

Signature / Rule:

Severity:

Confidence:

Bytes:
If supplied

Packets:
If supplied

Evidence Reference:

Do not modify the original event.

Part 5 — Establish the Investigation Window

Start with a focused window.

Example:

Alert:
14:32 UTC

Initial Investigation Window:
14:15–14:50 UTC

Expand only when evidence requires it.

Part 6 — Identify the Source Asset

The source IP alone is not enough.

Determine:

SOURCE ASSET PROFILE

IP:

Hostname:

Operating System:

Asset Owner:

Department:

Business Role:

Criticality:

Network Segment:

Expected User:

Endpoint Protection:

Normal Services:

Normal Destinations:

Part 7 — Validate IP-to-Asset Mapping

IP addresses may change because of:

• DHCP

• VPN

• NAT

• cloud addressing

• containerized environments

Always correlate the IP with the relevant timestamp.

Remember:

IP Address ≠ Permanent Device Identity

Part 8 — Identify the Destination

Create:

DESTINATION PROFILE

IP:

Hostname / Domain:
If known

Port:

Protocol:

Service:

Internal / External:

Expected Business Destination:
Yes / No / Unknown

Known Application Dependency:
Yes / No / Unknown

Reputation:
If supplied

Assessment:

Part 9 — Determine Network Direction

Classify the event as:

Inbound

Outbound

Internal → Internal

External → Internal

Internal → External

Cross-Segment

Unknown

Direction materially changes the investigation.

Part 10 — Build the Communication Model

Example:

WIN-FIN-02
10.10.20.45
     │
     │ TCP/443
     ▼
203.0.113.50
External Destination

Then add the control:

WIN-FIN-02
     │
     ▼
Firewall / IDS
     │
     │ Allowed
     ▼
External Destination

Part 11 — Analyze the Port

Suppose:

Destination Port:
443/TCP

This commonly supports HTTPS/TLS traffic.

But:

Port 443 ≠ Legitimate HTTPS automatically.

Likewise:

Unusual Port ≠ Malicious automatically.

Ports provide context—not intent.

Part 12 — Determine the Actual Service

Where telemetry allows, correlate:

• port

• application identification

• TLS metadata

• proxy evidence

• process

• destination hostname

Create:

Port	Protocol	Identified Service	Confidence
443	TCP	HTTPS/TLS

Part 13 — Review the Alert Signature

Record:

DETECTION PROFILE

Rule / Signature:

Category:

Description:

Sensor:

Source:

Destination:

Direction:

Trigger Condition:

Action:

Confidence:

Known Limitations:

Understand what the rule detected.

Do not rely only on the alert title.

Part 14 — Distinguish Signature from Reality

An IDS may detect:

Suspicious outbound communication

That means:

Observed traffic
      ↓
Matched detection logic

It does not necessarily mean:

Malware executed
      ↓
Command-and-control established
      ↓
Data stolen

Those require additional evidence.

Part 15 — Determine Whether the Traffic Was Allowed

Possible firewall actions:

Allow

Deny

Drop

Reject

Reset

Quarantine

Unknown

Record:

FIREWALL OUTCOME

Source:

Destination:

Port:

Protocol:

Action:

Rule:

Policy:

Bytes:

Session Duration:

Assessment:

Part 16 — Understand Blocked Traffic

Suppose:

Action:
Blocked

Then:

Connection Attempt
      ≠
Successful Connection

The blocked event may demonstrate a functioning security control.

Part 17 — Understand Allowed Traffic

Likewise:

Allowed
   ≠
Malicious

The firewall may simply permit a legitimate business service.

You must establish context.

Part 18 — Build the Firewall Event Register

Time	Source	Destination	Port	Action	Rule

Part 19 — Determine Connection Frequency

Search the supplied telemetry for the same:

Source
+
Destination
+
Port

over the investigation window.

Determine:

• one connection

• repeated connections

• periodic connections

• continuous session

• burst activity

Part 20 — Build the Connection Frequency Register

Time	Source	Destination	Port	Action
14:32	10.10.20.45	203.0.113.50	443	Allow
14:37	10.10.20.45	203.0.113.50	443	Allow
14:42	10.10.20.45	203.0.113.50	443	Allow

Part 21 — Analyze Periodicity Carefully

Regular intervals may indicate:

• monitoring

• software updates

• cloud synchronization

• health checks

• scheduled application traffic

• automated malicious communication

Therefore:

Periodic Traffic ≠ Command-and-Control Automatically

Part 22 — Determine the Responsible Process

If endpoint telemetry exists, correlate the network event with the process responsible.

Record:

PROCESS-TO-NETWORK CORRELATION

Host:

Process:

Parent Process:

User:

Destination:

Port:

Time:

Expected Process:
Yes / No / Unknown

Expected Destination:
Yes / No / Unknown

Part 23 — Build the Process Network Register

Time	Host	Process	Destination	Port	Assessment

This is one of the strongest correlations available during network investigations.

Part 24 — Analyze Process Context

Suppose traffic originated from:

chrome.exe

That may represent ordinary browser traffic.

Suppose it originated from:

InvoiceViewer.exe

from Lab 07.

That provides significantly different context.

But still:

Suspicious Process + Connection ≠ Data Exfiltration Proven

Part 25 — Correlate Parent Process

Build:

explorer.exe
     │
     ▼
InvoiceViewer.exe
     │
     ▼
203.0.113.50:443

Now the network event becomes part of an endpoint activity chain.

Part 26 — Correlate DNS Evidence

Determine whether the source system resolved a domain before the connection.

Example:

WIN-FIN-02
     │
     ▼
DNS Query
     │
     ▼
update-service.example.test
     │
     ▼
203.0.113.50

Record:

DNS CORRELATION

Time:

Client:

Domain:

Resolved IP:

Process:
If available

Destination Match:
Yes / No

Assessment:

Part 27 — Build the DNS Register

Time	Client	Domain	Resolved IP	Assessment

Part 28 — Interpret DNS Carefully

Always distinguish:

DNS Query
   ≠
Connection

and:

Domain Resolution
   ≠
Malicious Communication

DNS is supporting evidence.

Part 29 — Correlate Proxy Evidence

If proxy telemetry exists, record:

• user

• host

• URL

• domain

• action

• status

• category

• bytes

Create:

PROXY CORRELATION

User:

Host:

Time:

URL:

Destination:

Action:

HTTP Status:
If supplied

Bytes:

Category:

Assessment:

Part 30 — Correlate Endpoint Alert Evidence

Search endpoint telemetry around the network event.

Look for:

• EDR alert

• suspicious process

• file execution

• file creation

• process termination

• quarantine

• network prevention

Build:

Time	Endpoint Event	Process	Related Network Event

Part 31 — Correlate Authentication Activity

Ask whether the network event followed:

• unusual login

• privileged authentication

• remote access

• VPN session

• account anomaly

Create:

AUTHENTICATION CORRELATION

User:

Authentication Time:

Source:

Destination Host:

Success / Failure:

Expected:

Network Event Time:

Relationship:

Part 32 — Distinguish Temporal Correlation from Causation

Suppose:

14:25
User login

14:32
Network alert

This does not prove the login caused the network event.

Use:

Correlation provides investigative context. Causation requires stronger evidence.

Part 33 — Investigate Internal-to-Internal Traffic

Not every network alert involves the Internet.

Example:

USER-PC-17
    │
    │ SMB
    ▼
FILE-SRV-01

Ask:

• is the source authorized?

• is the destination expected?

• is the service expected?

• did authentication succeed?

• is segmentation working?

Part 34 — Investigate Cross-Segment Traffic

Example:

Guest Network
     │
     ▼
Finance Server

This deserves attention even if the traffic itself is not malicious.

The issue may be:

Unexpected network reachability.

Part 35 — Build the Segmentation Context Register

Source Zone	Destination Zone	Service	Expected	Observed
User	Server	HTTPS	Yes	Allowed
Guest	Finance	SMB	No	Blocked

Part 36 — Investigate Inbound Traffic

For external-to-internal alerts, determine:

Was the destination service intentionally exposed?

Was the connection allowed?

Was authentication attempted?

Was the application affected?

Did the security control block it?

Do not actively test the external source.

Part 37 — Investigate Outbound Traffic

For internal-to-external alerts, determine:

Which host initiated it?

Which process initiated it?

Which user was active?

Which domain was resolved?

Was the destination expected?

Was traffic allowed?

Was the communication repeated?

Part 38 — Investigate Internal Lateral Communication

Internal communication can be normal.

Examples include:

• SMB

• RDP

• SSH

• database traffic

• application APIs

• administrative protocols

Investigate deviations from expected relationships.

Part 39 — Build the Expected Communication Baseline

Source	Destination	Service	Expected
USER-PC	DNS Server	DNS	Yes
App Server	DB Server	Database	Yes
Guest Device	Finance Server	SMB	No

Part 40 — Compare Expected vs Observed

Create:

EXPECTED:
Finance workstation → Approved proxy → Internet

OBSERVED:
Finance workstation → External destination directly

That difference may be more important than the destination reputation alone.

Part 41 — Review Traffic Volume

Where supplied, assess:

• bytes sent

• bytes received

• packets

• duration

• connection count

Do not claim data theft based solely on high volume.

Part 42 — Build the Traffic Volume Register

Time	Source	Destination	Sent	Received	Duration

Part 43 — Distinguish Transfer from Exfiltration

Always distinguish:

Outbound Bytes
     ≠
Sensitive Data

and:

Large Transfer
     ≠
Data Exfiltration

To claim exfiltration, evidence must support unauthorized sensitive-data transfer.

Part 44 — Investigate Repeated Denied Connections

Repeated blocked traffic may indicate:

• misconfiguration

• stale application dependency

• automated process

• unauthorized access attempt

• compromised host behavior

Create:

REPEATED DENIAL PROFILE

Source:

Destination:

Port:

First Seen:

Last Seen:

Count:

Interval:

Process:
If known

Expected:

Assessment:

Part 45 — Investigate Multiple Destinations

Search whether the source communicates with:

one destination

or:

many destinations

Create:

Destination	Port	Count	Action	Expected

Part 46 — Investigate Multiple Source Hosts

Search whether the same destination appears from multiple endpoints.

Create:

Source Host	User	Destination	Process	Status
WIN-FIN-02	finance-user	203.0.113.50
WIN-HR-04

This helps establish scope.

Part 47 — Search Related Alerts

Search the SIEM for:

• same source

• same destination

• same signature

• same domain

• same port

• same user

Build:

RELATED ALERT REGISTER

Alert ID:

Time:

Source:

Destination:

Rule:

Severity:

Relationship:

Part 48 — Avoid Alert Counting as Evidence of Impact

Remember:

10 Alerts
    ≠
10 Successful Attacks

Multiple alerts may represent one underlying activity.

Part 49 — Consolidate Duplicate Alerts

Example:

IDS Alert
Firewall Alert
EDR Network Alert
DNS Alert

may all describe the same activity chain.

Correlate rather than treating each as a separate incident.

Part 50 — Build the Correlation Matrix

Time	IDS	Firewall	DNS	Endpoint	Authentication
14:31			Query
14:32	Alert	Allow		Connection
14:33

Part 51 — Build the Network Activity Chain

Example:

Suspicious File Execution
          │
          ▼
        Process
          │
          ▼
       DNS Query
          │
          ▼
   Domain Resolution
          │
          ▼
Outbound Connection
          │
          ▼
      IDS Alert
          │
          ▼
     Firewall Allow

This is far stronger than analyzing the IDS alert alone.

Part 52 — Build the Master Timeline

Example:

14:24
User authenticated to WIN-FIN-02

14:28
Suspicious process started

14:31
DNS query observed

14:32
Connection to external destination

14:32
IDS alert generated

14:32
Firewall permitted connection

14:33
EDR network telemetry recorded connection

14:35
Security process terminated

14:40
SOC investigation started

Only include supported evidence.

Part 53 — Normalize Time

Ensure:

• IDS

• firewall

• DNS

• endpoint

• proxy

• authentication

• SIEM

timestamps use a common reference.

Document any clock difference.

Part 54 — Determine Network Scope

Create:

NETWORK SCOPE

Primary Source:

Primary Destination:

Related Sources:

Related Destinations:

Ports:

Protocols:

Domains:

Affected Segments:

Affected Users:

Related Processes:

First Seen:

Last Seen:

Part 55 — Determine Asset Scope

Create:

Asset	Role	Related Activity	Criticality	Status
WIN-FIN-02	Workstation	Source	Medium	Investigating
FILE-SRV-01	Server		High

Part 56 — Determine User Scope

Create:

USER SCOPE

Primary User:

Other Users:

Privileged Users:

Service Accounts:

Authentication Relationship:

Known Exposure:

Part 57 — Determine Destination Scope

Ask:

Is this one destination?

One domain with multiple IPs?

Multiple related domains?

Multiple unrelated destinations?

Internal or external?

Do not assume shared infrastructure means shared malicious ownership.

Part 58 — Determine Whether the Security Control Worked

Examples:

IDS

Detected

but may not block.

IPS

Detected + Blocked

Firewall

Allowed / Denied

EDR

Process terminated

DNS Security

Domain blocked

Document the actual outcome.

Part 59 — Build the Security Control Outcome Matrix

Control	Detected	Blocked	Evidence
IDS	Yes	No
Firewall
DNS Security
EDR
Proxy

Part 60 — Identify Positive Security Controls

Examples:

IDS detected anomalous traffic.

Firewall denied unauthorized cross-segment communication.

DNS security blocked the suspicious domain.

EDR identified the responsible process.

Proxy prevented access to the destination.

Segmentation prevented access to a sensitive server.

Positive controls belong in the investigation report.

Part 61 — Identify Telemetry Gaps

Examples:

• no process-to-network mapping

• missing DNS logs

• NAT obscures source

• no proxy telemetry

• encrypted payload

• incomplete packet metadata

• firewall retention gap

• no asset ownership record

Create:

Gap	Investigation Impact	Confidence Effect
No endpoint process data	Cannot attribute connection to process	Medium

Part 62 — Build Investigation Hypotheses

Hypothesis 1 — Expected Business Traffic

Known application
+
approved destination
+
expected process
+
normal frequency

Hypothesis 2 — Security Tool False Positive

Rule matched
+
traffic legitimate
+
no additional suspicious evidence

Hypothesis 3 — Misconfiguration

Unexpected traffic
+
known application
+
incorrect destination/policy

Hypothesis 4 — Suspicious Endpoint Communication

Unexpected process
+
unexpected destination
+
network detection

Hypothesis 5 — Potential Security Incident

Suspicious process
+
DNS indicator
+
external connection
+
related endpoint evidence

Part 63 — Create the Hypothesis Matrix

Hypothesis	Supporting Evidence	Contradicting Evidence	Confidence
Expected traffic
False positive
Misconfiguration
Suspicious communication
Security incident

Part 64 — Determine the SOC Disposition

Use:

Expected Activity

Traffic matches approved business behavior.

Benign / False Positive

Detection fired but evidence supports legitimate activity.

Operational Misconfiguration

Unexpected traffic caused by configuration or application issues.

Suspicious Network Activity

Activity is anomalous and requires investigation.

Potential Security Incident

Multiple correlated indicators support possible malicious activity.

Confirmed Security Incident

Evidence demonstrates unauthorized or malicious network activity with relevant impact.

Inconclusive

Available telemetry cannot support a reliable conclusion.

Part 65 — Example — Expected Business Traffic

DISPOSITION:
Expected Activity

SOURCE:
APP-SRV-01

DESTINATION:
Approved cloud service

SERVICE:
TCP/443

EVIDENCE:
The application owner confirmed the destination is part of an
approved service dependency.

The process responsible for the traffic matches the expected
application.

Connection frequency is consistent with baseline behavior.

SEVERITY:
Informational

CONFIDENCE:
High

Part 66 — Example — Blocked Cross-Segment Traffic

DISPOSITION:
Suspicious Network Activity — Blocked

SOURCE:
Guest network endpoint

DESTINATION:
Finance server

SERVICE:
SMB

FIREWALL:
Denied

EVIDENCE:
The source attempted communication that violates the expected
segmentation model.

The firewall blocked the connection.

SUCCESSFUL ACCESS:
Not observed.

SEVERITY:
Medium

CONFIDENCE:
High

POSITIVE CONTROL:
Network segmentation operated as intended.

Part 67 — Example — Potential Security Incident

DISPOSITION:
Potential Security Incident

SOURCE:
WIN-FIN-02

DESTINATION:
Unexpected external destination

SERVICE:
TCP/443

ACTION:
Allowed

CORRELATION:
The connection occurred shortly after execution of a suspicious
process identified by endpoint telemetry.

DNS evidence associates the same endpoint with the destination
domain.

The responsible process is not part of the approved software
baseline.

KNOWN IMPACT:
Outbound communication confirmed.

DATA EXFILTRATION:
Not established.

SEVERITY:
High

CONFIDENCE:
High

ESCALATION:
Required.

Part 68 — Assign Severity

Consider:

• source criticality

• destination criticality

• traffic direction

• service

• allowed vs blocked

• responsible process

• authentication context

• endpoint evidence

• segmentation impact

• number of systems

• persistence of communication

• potential business impact

Part 69 — Assign Confidence Separately

Example:

Severity:
High

Confidence:
Medium

may indicate potentially serious activity with incomplete endpoint attribution.

Part 70 — Determine Containment Recommendations

Depending on evidence:

• block malicious destination

• block domain

• isolate affected endpoint

• terminate suspicious process

• restrict network path

• disable affected account

• revoke active session

• increase monitoring

• preserve network evidence

Do not perform disruptive actions unless explicitly authorized.

Part 71 — Build the Containment Decision Matrix

Action	Required	Reason	Impact	Approval
Block destination
Isolate endpoint
Restrict segment
Disable identity
Preserve PCAP/logs

Part 72 — Determine Escalation

Escalate when:

• suspicious communication was allowed

• suspicious process is correlated

• privileged or critical asset involved

• multiple hosts communicate with same indicator

• lateral communication suspected

• segmentation failure identified

• potential credential compromise exists

• containment is required

• data exposure requires investigation

Part 73 — Build the Escalation Summary

ESCALATION SUMMARY

Case ID:

Alert:

Source:

Source Asset:

Source User:

Destination:

Domain:

Port:

Protocol:

Direction:

Action:

Responsible Process:

DNS Correlation:

Endpoint Correlation:

Authentication Correlation:

Other Hosts:

Other Destinations:

Known Impact:

Unconfirmed Concerns:

Severity:

Confidence:

Containment Recommendation:

Evidence References:

Part 74 — Build the Network Evidence Register

Evidence ID	Source	Description
EV-NET-01	IDS	Original alert
EV-NET-02	Asset Inventory	Source context
EV-NET-03	Firewall	Connection outcome
EV-NET-04	DNS	Domain resolution
EV-NET-05	EDR	Process attribution
EV-NET-06	Authentication	User context
EV-NET-07	SIEM	Related alerts

Part 75 — Build the Final Network Investigation Register

CASE ID:

ALERT:

SOURCE IP:

SOURCE HOST:

SOURCE USER:

SOURCE ZONE:

DESTINATION IP:

DESTINATION DOMAIN:

DESTINATION ZONE:

SOURCE PORT:

DESTINATION PORT:

PROTOCOL:

SERVICE:

DIRECTION:

FIREWALL ACTION:

IDS/IPS ACTION:

RESPONSIBLE PROCESS:

PARENT PROCESS:

DNS CORRELATION:

PROXY CORRELATION:

ENDPOINT CORRELATION:

AUTHENTICATION CORRELATION:

CONNECTION COUNT:

FIRST SEEN:

LAST SEEN:

TRAFFIC VOLUME:

RELATED SOURCES:

RELATED DESTINATIONS:

RELATED ALERTS:

SEGMENTATION CONTEXT:

TELEMETRY GAPS:

POSITIVE CONTROLS:

DISPOSITION:

SEVERITY:

CONFIDENCE:

KNOWN IMPACT:

ESCALATION:

CONTAINMENT:

REMAINING QUESTIONS:

Part 76 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Network Security Alert Investigation

Case ID:

Analyst:

Date:


INITIAL ALERT

Alert ID:

Rule:

Sensor:

Time:

Severity:

Source:

Destination:

Port:

Protocol:

Action:


SOURCE CONTEXT

IP:

Hostname:

Operating System:

Owner:

User:

Role:

Criticality:

Network Zone:

Expected Activity:


DESTINATION CONTEXT

IP:

Domain:

Internal / External:

Port:

Service:

Expected Destination:

Business Purpose:


NETWORK FLOW

Direction:

Source Port:

Destination Port:

Protocol:

Service:

Connection Count:

First Seen:

Last Seen:

Bytes Sent:

Bytes Received:


SECURITY CONTROLS

IDS Detection:

IPS Action:

Firewall Action:

DNS Security:

Proxy Action:

EDR Action:


PROCESS CORRELATION

Process:

Parent:

User:

Execution Time:

Expected:

Related Endpoint Alert:


DNS CORRELATION

Domain:

Query Time:

Resolved IP:

Matches Destination:

Assessment:


AUTHENTICATION CORRELATION

User:

Authentication:

Source:

Time:

Expected:

Relationship:


SEGMENTATION

Source Zone:

Destination Zone:

Expected Reachability:

Observed Reachability:

Control Outcome:


SCOPE

Related Hosts:

Related Users:

Related Destinations:

Related Domains:

Related Alerts:

Affected Segments:


TELEMETRY GAPS

Gap 01:

Impact:

Gap 02:

Impact:


POSITIVE CONTROLS

Control 01:

Evidence:

Control 02:

Evidence:


FINAL ASSESSMENT

Disposition:

Severity:

Confidence:

Known Impact:

Successful Communication:
Confirmed / Not Observed / Unknown

Compromise:
Confirmed / Potential / Not Established

Data Exfiltration:
Confirmed / Not Established / Unknown

Escalation:
Yes / No

Containment:
Yes / No

Remaining Questions:

Ready for DNS & Web Traffic Investigation:
Yes / No

Part 77 — What Not to Do

Do not:

Assume IDS alert means successful attack

Assume IPS alert means compromise

Assume firewall allow means malicious traffic

Assume firewall deny means attack succeeded

Assume external IP means malicious destination

Assume port 443 means legitimate HTTPS

Assume unusual port means malware

Assume repeated traffic means command-and-control

Assume periodic traffic means beaconing

Assume DNS query means successful connection

Assume outbound connection means data exfiltration

Assume high traffic volume means data theft

Assume internal communication is trusted

Assume multiple alerts represent multiple incidents

Actively probe suspicious Internet systems

Attempt to connect to suspicious destinations

Capture unrelated production traffic

Disable network security controls

Change firewall rules without authorization

Block production dependencies without approval

Isolate critical systems without approval

Overstate the evidence

The professional rule is:

Observe, correlate, scope, and document. Do not turn a defensive investigation into an unauthorized network assessment.

Troubleshooting

IDS Alert Exists but Firewall Shows Blocked

Document:

Detection:
Confirmed

Connection Attempt:
Confirmed

Successful Communication:
Not observed

Control Outcome:
Blocked

Do not report successful access.

Firewall Shows Allowed but No IDS Alert

This may be normal.

Investigate context rather than assuming detection failure.

Destination Has No Domain

Continue with:

• IP

• process

• firewall

• endpoint

• timing

Do not invent a hostname.

DNS Query Exists but No Connection

Record:

DNS resolution observed.

Subsequent connection not established from available evidence.

Endpoint Process Data Is Missing

Document the telemetry gap.

Do not attribute the traffic to a process without evidence.

Same Destination Appears on Many Hosts

Determine whether it is:

• approved shared infrastructure

• software update service

• cloud platform

• security service

• genuinely suspicious common destination

Traffic Is Encrypted

Encryption does not prevent investigation.

You can still analyze available metadata such as:

• source

• destination

• port

• timing

• process

• domain

• volume

• security-control outcomes

Evidence Requirements

Capture:

Evidence 01

Original network alert.

Evidence 02

Case scope.

Evidence 03

Network Alert Profile.

Evidence 04

Source Asset Profile.

Evidence 05

Destination Profile.

Evidence 06

Communication Model.

Evidence 07

Detection Profile.

Evidence 08

Firewall Outcome.

Evidence 09

Firewall Event Register.

Evidence 10

Connection Frequency Register.

Evidence 11

Process-to-Network Correlation.

Evidence 12

Process Network Register.

Evidence 13

DNS Correlation.

Evidence 14

DNS Register.

Evidence 15

Proxy correlation.

Evidence 16

Endpoint correlation.

Evidence 17

Authentication correlation.

Evidence 18

Segmentation Context Register.

Evidence 19

Expected Communication Baseline.

Evidence 20

Traffic Volume Register.

Evidence 21

Related destinations.

Evidence 22

Related source hosts.

Evidence 23

Related Alert Register.

Evidence 24

Correlation Matrix.

Evidence 25

Network Activity Chain.

Evidence 26

Master Timeline.

Evidence 27

Network Scope.

Evidence 28

Asset Scope.

Evidence 29

User Scope.

Evidence 30

Security Control Outcome Matrix.

Evidence 31

Positive security controls.

Evidence 32

Telemetry gaps.

Evidence 33

Hypothesis Matrix.

Evidence 34

Containment Decision Matrix.

Evidence 35

Escalation Summary.

Evidence 36

Network Evidence Register.

Evidence 37

Final Network Investigation Register.

Evidence 38

Mission Challenge worksheet.

Mission Deliverables

Complete:

• network case opened

• original alert preserved

• investigation window established

• source asset identified

• source IP mapped to correct asset/time

• destination identified

• network direction determined

• port/protocol analyzed

• service context established

• detection signature understood

• firewall action determined

• allowed/blocked status validated

• connection frequency analyzed

• periodicity assessed

• responsible process identified where telemetry exists

• parent-process context reviewed

• DNS evidence correlated

• proxy evidence correlated

• endpoint evidence correlated

• authentication evidence correlated

• segmentation context reviewed

• expected vs observed communication compared

• traffic volume reviewed

• related destinations searched

• related source hosts searched

• related alerts correlated

• duplicate alerts consolidated

• master timeline created

• network scope determined

• asset scope determined

• user scope determined

• control outcomes documented

• positive security controls documented

• telemetry gaps documented

• competing hypotheses evaluated

• disposition assigned

• severity assigned

• confidence assigned separately

• containment recommendation documented

• escalation decision documented

• final Network Alert Investigation Report completed

Lab Report Template

# Lab 08 — Network Security Alert Investigation

## Executive Summary

## Mission Objective

## Case Information

## Initial Alert

## Investigation Scope

## Source Asset Analysis

## Destination Analysis

## Network Direction

## Port, Protocol & Service Analysis

## IDS / IPS Analysis

## Firewall Analysis

## Connection Frequency Analysis

## Process-to-Network Correlation

## DNS Correlation

## Proxy Correlation

## Endpoint Correlation

## Authentication Correlation

## Segmentation Analysis

## Expected vs Observed Communication

## Traffic Volume Analysis

## Related Sources

## Related Destinations

## Related Alerts

## Network Activity Chain

## Master Timeline

## Network Scope

## Asset Scope

## User Scope

## Security-Control Outcomes

## Positive Security Controls

## Telemetry Gaps

## Hypothesis Analysis

## Final Disposition

## Severity

## Confidence

## Known Impact

## Containment Recommendations

## Escalation Decision

## Evidence Register

## Remaining Questions

## Limitations

## Conclusion

Knowledge Check

Question 1 — Does an IDS alert prove an attack succeeded?

No.

It means traffic matched the detection logic.

Question 2 — Does a firewall deny event prove compromise?

No.

It may demonstrate that the security control successfully prevented communication.

Question 3 — Does allowed outbound traffic mean malicious communication?

No.

The destination, process, user, service, and business context must be evaluated.

Question 4 — Why is process-to-network correlation valuable?

It connects network activity to the application or process responsible for generating it.

Question 5 — Does periodic network traffic prove command-and-control activity?

No.

Many legitimate applications communicate at regular intervals.

Question 6 — Does a DNS lookup prove successful network communication?

No.

DNS resolution and subsequent connection establishment are separate events.

Question 7 — Does outbound traffic prove data exfiltration?

No.

Evidence must establish that unauthorized sensitive information was transferred.

Question 8 — Why investigate internal-to-internal traffic?

Because lateral communication, segmentation violations, and unauthorized access can occur entirely inside the network.

Question 9 — Why separate severity from confidence?

A potentially serious event can have incomplete evidence, resulting in high severity but medium or low confidence.

Question 10 — What is the central question of this lab?

“What network activity triggered the alert, was the communication actually allowed or successful, and does the correlated evidence support expected traffic, suspicious behavior, or a security incident?”

Skills Achieved

After completing this lab, you should understand:

• network security alert triage

• IDS/IPS alert interpretation

• firewall-event analysis

• source/destination investigation

• network-direction analysis

• port/protocol interpretation

• service-context analysis

• connection-frequency analysis

• periodicity assessment

• process-to-network correlation

• DNS correlation

• proxy correlation

• endpoint correlation

• authentication correlation

• segmentation analysis

• traffic-volume analysis

• related-alert correlation

• network timeline reconstruction

• network incident scoping

• security-control validation

• containment planning

• SOC escalation

• network incident reporting

Professional Takeaway

A weak network investigation looks like:

IDS Alert
   ↓
External IP
   ↓
Port 443
   ↓
Malware Communication
   ↓
Host Compromised

A professional network investigation looks like:

Network Alert
      ↓
Source Asset
      ↓
Destination
      ↓
Port / Protocol / Service
      ↓
Direction
      ↓
Allowed / Blocked
      ↓
Process Attribution
      ↓
DNS / Proxy
      ↓
Endpoint + Authentication
      ↓
Related Sources / Destinations
      ↓
Segmentation Context
      ↓
Timeline
      ↓
Scope
      ↓
Evidence-Based Disposition

Always distinguish:

IDS Alert
   ≠
Attack Success

Firewall Allow
   ≠
Malicious Traffic

Firewall Deny
   ≠
Compromise

External Destination
   ≠
Malicious Destination

Port 443
   ≠
Legitimate Traffic

Periodic Traffic
   ≠
Command-and-Control

DNS Query
   ≠
Successful Connection

Outbound Connection
   ≠
Data Exfiltration

Multiple Alerts
   ≠
Multiple Incidents

Internal Traffic
   ≠
Trusted Traffic Automatically

The strongest SOC analyst does not ask only:

“What did the IDS detect?”

They ask:

“Which asset generated the traffic, which process and user were responsible, where did it go, was it allowed, what other telemetry supports the event, how far did the activity extend, and what evidence demonstrates actual security impact?”

What’s Next?

➡️ Lab 09 — DNS & Web Traffic Investigation

In the next lab, you will go deeper into DNS, HTTP/HTTPS, proxy, and web activity.

You will investigate:

• DNS queries

• DNS responses

• domain-to-IP relationships

• repeated domain lookups

• unusual domains

• client attribution

• web requests

• URLs

• HTTP methods

• response codes

• proxy actions

• redirects

• downloads

• user and process context

• endpoint correlation

• domain/URL IOC correlation

• multi-host activity

• timeline reconstruction

The methodology becomes:

Client → DNS Query → Resolution → Web Request → Response → User/Process → Correlation → Scope → Disposition

The central question will be:

“What domain or web resource did the system attempt to reach, what happened after resolution, which user or process initiated the activity, and does the complete evidence support normal browsing, suspicious communication, or a security incident?”