Lab 09 DNS & Web Traffic Investigation

Mission Overview

Welcome to Lab 09 — DNS & Web Traffic Investigation.

In Lab 08, you investigated network security alerts by analyzing source and destination systems, ports, protocols, firewall actions, IDS/IPS detections, processes, and related telemetry.

Now you will investigate two telemetry sources that frequently provide the missing context behind those alerts:

DNS and web traffic.

DNS can show which domains a system attempted to resolve.

Proxy and web telemetry can show what happened after resolution.

Endpoint telemetry can help determine which process or user initiated the activity.

When these sources are correlated, the SOC can reconstruct a sequence such as:

User / Process
      ↓
DNS Query
      ↓
Domain Resolution
      ↓
Web Connection
      ↓
URL Request
      ↓
HTTP Response
      ↓
Download / Redirect
      ↓
Endpoint Activity

But every stage must be proven separately.

Mission Goal: Investigate simulated DNS and web activity, determine which client, user, or process generated it, reconstruct domain-to-web activity, identify suspicious patterns, correlate related endpoint and network telemetry, determine organizational scope, and produce an evidence-based SOC disposition.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	DNS & Web Traffic Investigation
Secondary Skill	Proxy and Network Correlation
Environment	GoHackersCloud SOC Analyst Lab
Evidence	Simulated DNS + proxy/web + endpoint + SIEM logs
Primary Outcome	DNS & Web Investigation Report
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

• investigate suspicious DNS activity

• identify the requesting client

• interpret DNS queries and responses

• correlate domains with resolved IP addresses

• distinguish resolution from communication

• investigate repeated DNS activity

• analyze web/proxy logs

• interpret URLs and HTTP methods

• interpret HTTP response codes

• analyze allowed and blocked web requests

• investigate redirects

• investigate downloads

• correlate DNS and web activity

• correlate activity with endpoint processes

• associate user context where evidence exists

• investigate multiple affected hosts

• distinguish IOC matches from compromise

• reconstruct DNS/web timelines

• determine incident scope

• document security-control outcomes

• produce a professional SOC investigation report

Investigation Methodology

Use:

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

A more complete workflow is:

Alert / Indicator
       │
       ▼
Identify Client
       │
       ▼
Analyze DNS Query
       │
       ▼
Analyze DNS Response
       │
       ▼
Domain → IP
       │
       ▼
Search Web / Proxy
       │
       ▼
URL / Method / Response
       │
       ▼
Allowed / Blocked
       │
       ▼
User + Process
       │
       ▼
Endpoint / Network Correlation
       │
       ▼
Related Hosts
       │
       ▼
Timeline + Scope
       │
       ▼
Disposition

The core principle is:

DNS tells you what a system attempted to resolve. Web telemetry helps determine what happened next. Neither source should be interpreted in isolation.

Part 1 — Create the Investigation Workspace

Create:

SOC-Labs/
└── Lab-09/
    ├── 01-Scope/
    ├── 02-Alert/
    ├── 03-DNS/
    │   ├── Queries/
    │   └── Responses/
    ├── 04-Domains/
    ├── 05-Web-Traffic/
    ├── 06-Proxy/
    ├── 07-Redirects/
    ├── 08-Downloads/
    ├── 09-Endpoint/
    ├── 10-Network/
    ├── 11-IOCs/
    ├── 12-Correlation/
    ├── 13-Scope/
    ├── 14-Timeline/
    ├── 15-Evidence/
    ├── 16-Findings/
    └── 17-Report/

Create:

Lab-09-DNS-Web-Traffic-Investigation.md

Part 2 — Open the Investigation Case

Example:

CASE ID:
GHC-SOC-2026-009

CASE TITLE:
DNS & Web Traffic Investigation

STATUS:
Investigating

INITIAL PRIORITY:
P2

ANALYST:

DATE:

Part 3 — Review the Initial Alert

Assume the SOC receives:

ALERT ID:
ALT-DNS-001

ALERT:
Suspicious Domain Query

CLIENT:
10.10.20.45

DOMAIN:
account-update.example.test

TIME:
15:21 UTC

QUERY TYPE:
A

DNS ACTION:
Allowed

INITIAL SEVERITY:
Medium

Do not conclude:

Suspicious Domain
      ↓
DNS Query
      ↓
Compromised Host

Instead ask:

Which system generated the query, why was the domain requested, what IP was returned, was a subsequent connection made, which user or process generated it, and what happened afterward?

Part 4 — Preserve the Original Alert

Record:

DNS ALERT PROFILE

Alert ID:

Timestamp:

Client IP:

Client Host:

Domain:

Query Type:

Response:

Resolved Address:

DNS Server:

Security Action:

Rule / Detection:

Initial Severity:

Evidence Reference:

Part 5 — Establish the Investigation Window

Example:

Alert Time:
15:21 UTC

Initial Window:
15:05–15:40 UTC

If earlier or later related events appear, expand the window.

Document every expansion.

Part 6 — Identify the Client

Create:

CLIENT PROFILE

Client IP:

Hostname:

Operating System:

User:

Department:

Business Role:

Criticality:

Network Segment:

Endpoint Protection:

Normal Web Usage:

Expected DNS Server:

Remember:

Client IP ≠ Permanent Endpoint Identity

Correlate the address with the event timestamp.

Part 7 — Understand the DNS Event

A simplified DNS sequence is:

Client
   │
   │ Query: account-update.example.test
   ▼
DNS Resolver
   │
   │ Response: 203.0.113.50
   ▼
Client

This demonstrates resolution activity.

It does not prove the client subsequently communicated with the returned address.

Part 8 — Record the DNS Query

Create:

DNS QUERY PROFILE

Time:

Client:

User:
If known

Domain:

Query Type:

Resolver:

Response Code:

Answer:

TTL:
If supplied

Security Verdict:

Action:

Process:
If available

Part 9 — Understand Common DNS Query Types

You may encounter:

Type	General Purpose
A	IPv4 address
AAAA	IPv6 address
CNAME	Alias/canonical-name relationship
MX	Mail server
TXT	Text/policy information
NS	Name server
PTR	Reverse lookup

The record type alone does not indicate malicious behavior.

Part 10 — Analyze the DNS Response

Record:

DOMAIN:
account-update.example.test

QUERY TYPE:
A

ANSWER:
203.0.113.50

RESPONSE:
Successful

TIME:
15:21 UTC

Then determine whether the returned address appears elsewhere in the investigation.

Part 11 — Build the DNS Event Register

Time	Client	Domain	Type	Answer	Action
15:21	10.10.20.45	account-update.example.test	A	203.0.113.50	Allowed

Part 12 — Distinguish DNS Stages

Always distinguish:

Domain Queried
     ≠
Domain Resolved

Domain Resolved
     ≠
Connection Established

Connection Established
     ≠
Malicious Activity

Malicious Domain Contact
     ≠
Host Compromise Automatically

Part 13 — Investigate Failed DNS Queries

You may encounter:

NXDOMAIN

which generally indicates the requested name did not resolve.

A failed lookup may still be useful evidence.

It may reflect:

• mistyped hostname

• stale configuration

• removed infrastructure

• application behavior

• suspicious automated activity

Do not classify from NXDOMAIN alone.

Part 14 — Build the DNS Response Register

Domain	Response	Answer	Count	Assessment
account-update.example.test	Success	203.0.113.50
missing.example.test	NXDOMAIN	None

Part 15 — Analyze Query Frequency

Determine whether the client queried the domain:

Once

Repeatedly

Periodically

In bursts

Create:

Time	Client	Domain	Response
15:21	WIN-FIN-02	account-update.example.test	Success
15:26	WIN-FIN-02	account-update.example.test	Success
15:31	WIN-FIN-02	account-update.example.test	Success

Part 16 — Interpret Repeated Queries Carefully

Repeated DNS queries can result from:

• normal applications

• browsers

• software updates

• telemetry agents

• cloud services

• failed connectivity

• short TTL values

• automated suspicious processes

Therefore:

Repeated DNS Query ≠ Command-and-Control

Part 17 — Investigate the Domain

Record:

DOMAIN PROFILE

Domain:

First Seen:

Last Seen:

Clients:

Resolved IPs:

Query Count:

Web Activity:

Security Verdict:
If supplied

Related Alert:

Expected Business Use:

Assessment:

Part 18 — Evaluate Domain Characteristics

Look for evidence such as:

• unusual naming

• brand imitation

• excessive subdomains

• unexpected business context

• domain appearing in phishing evidence

• threat-intelligence classification supplied by the lab

Do not visit the domain directly.

Part 19 — Compare with Previous Cases

Suppose Lab 06 contained:

Phishing URL:
https://account-update.example.test/login

and Lab 09 shows:

DNS Query:
account-update.example.test

This creates useful correlation:

Phishing Email
      ↓
URL
      ↓
DNS Query

But it still does not prove the web page was successfully accessed.

Part 20 — Search for the Resolved IP

Search supplied telemetry for:

203.0.113.50

across:

• firewall

• proxy

• EDR

• network alerts

• SIEM

Create:

RESOLVED-IP CORRELATION

Domain:

Resolved IP:

Client:

Connection Found:
Yes / No

Protocol:

Port:

Action:

Time:

Evidence:

Part 21 — Correlate DNS to Network Connection

Example:

15:21:04
DNS Query

15:21:04
Response: 203.0.113.50

15:21:06
TCP connection to 203.0.113.50:443

Now the evidence supports:

DNS resolution followed by a network connection.

It still does not establish application-level activity by itself.

Part 22 — Build the DNS-to-Network Register

DNS Time	Domain	Resolved IP	Connection Time	Port	Action

Part 23 — Search Proxy/Web Telemetry

Look for activity associated with:

• client IP

• user

• domain

• URL

• resolved IP

• investigation time

Create:

WEB EVENT PROFILE

Time:

Client:

User:

Method:

URL:

Domain:

Destination IP:

Status:

Proxy Action:

Category:

Bytes:

User-Agent:
If supplied

Downloaded File:
If supplied

Part 24 — Understand URL Components

Example:

https://account-update.example.test/login?id=100
│       │                           │      │
Scheme  Host                        Path   Query

Record:

Scheme:

Host:

Port:

Path:

Query:

Fragment:
If present

Do not manually browse suspicious URLs.

Part 25 — Build the URL Register

URL ID	Time	Client	URL	Action	Assessment
URL-01

Part 26 — Analyze HTTP Methods

Common methods include:

GET
POST
HEAD

In SOC investigation:

• GET may represent resource retrieval.

• POST may represent submitted data.

But:

HTTP POST ≠ Credential Theft

Many legitimate applications use POST requests.

Context is required.

Part 27 — Build the HTTP Method Register

Time	User	URL	Method	Status	Assessment
			GET
			POST

Part 28 — Understand HTTP Response Codes

Useful categories include:

2xx → Successful processing

3xx → Redirection

4xx → Client-side request issue

5xx → Server-side error

A response code provides application context but is not a security verdict.

Part 29 — Build the Response Register

Time	URL	Method	Status	Action
		GET	302
		GET	200

Part 30 — Interpret HTTP 200 Carefully

Always distinguish:

HTTP 200
   ≠
Legitimate Website

It generally indicates the web server successfully handled the request.

A malicious site can also return HTTP 200.

Part 31 — Investigate Redirects

Example:

Initial URL
     ↓
HTTP 302
     ↓
Redirect Domain
     ↓
HTTP 302
     ↓
Final Destination

Create:

REDIRECT CHAIN

Initial URL:

Redirect 01:

Redirect 02:

Final URL:

Final Domain:

Final Status:

Security Assessment:

Part 32 — Build the Redirect Register

Step	Time	URL/Domain	Status	Destination
1			302
2			302
3			200

Do not manually follow suspicious redirects.

Part 33 — Investigate Web Filtering Outcome

Possible outcomes:

Allowed

Blocked

Warned

Redirected

Quarantined

Unknown

Record:

WEB SECURITY OUTCOME

URL:

Domain:

User:

Host:

Security Category:

Proxy Action:

Browser Access:

Downloaded Content:

Assessment:

Part 34 — Distinguish Attempt from Access

If the proxy blocked the request:

Web Request
     ↓
Proxy Block

then do not report:

User successfully visited malicious website

unless other evidence supports it.

Part 35 — Investigate Downloads

If telemetry identifies a download, record:

DOWNLOAD PROFILE

Time:

User:

Host:

URL:

Filename:

File Type:

Size:

Hash:
If supplied

Proxy Action:

Endpoint Detection:

Execution:
Yes / No / Unknown

Part 36 — Distinguish Download Stages

Always separate:

URL Requested
      ≠
File Downloaded

File Downloaded
      ≠
File Opened

File Opened
      ≠
File Executed

File Executed
      ≠
Endpoint Compromised Automatically

Part 37 — Correlate Downloads with Endpoint Telemetry

Example:

15:22
Web request

15:22
File downloaded

15:23
File created on endpoint

15:24
Process execution

15:24
EDR alert

This creates a much stronger activity chain.

Part 38 — Build the Web-to-Endpoint Register

Time	Web Event	File	Endpoint Event	Evidence
	Download		File Created
			Process Started

Part 39 — Identify the Responsible Process

Where telemetry exists, determine which process initiated the web activity.

Possible examples:

chrome.exe
edge.exe
firefox.exe
powershell.exe
application.exe

Do not classify a process solely by its name.

Part 40 — Build the Process-to-Web Register

Time	Host	User	Process	Domain	URL

Part 41 — Analyze Parent Process Context

Example:

explorer.exe
     │
     ▼
chrome.exe
     │
     ▼
account-update.example.test

may represent user browsing.

Compare with:

InvoiceViewer.exe
     │
     ▼
powershell.exe
     │
     ▼
account-update.example.test

The second chain provides significantly different investigative context.

Part 42 — Determine User Context

Create:

USER WEB PROFILE

User:

Host:

Authentication Status:

Browser / Process:

Normal Browsing Pattern:

Expected Domain:

Business Purpose:

Recent Phishing Case:

Recent Endpoint Alert:

Assessment:

Part 43 — Correlate Authentication Evidence

Ask whether suspicious web activity follows:

• new login

• unusual login

• privileged session

• remote access

• VPN activity

Do not infer causation solely from timing.

Part 44 — Build the Authentication Correlation Register

Time	User	Auth Event	Web Event	Relationship

Part 45 — Investigate Multiple Clients

Search the suspicious domain across DNS logs.

Create:

Client	User	Query Count	Web Access	Status
WIN-FIN-02	finance-user	3	Yes	Investigating
WIN-HR-04	hr-user	1	Blocked	Review

Part 46 — Distinguish Domain Scope from Compromise Scope

Suppose:

Domain Queried:
10 hosts

Web Connection:
4 hosts

Web Access Allowed:
2 hosts

File Download:
1 host

Execution:
0 confirmed

Then:

10 domain queries
      ≠
10 compromised hosts

Part 47 — Investigate Related Domains

A case may contain:

Initial Domain
      ↓
Redirect Domain
      ↓
Content Domain

Search each identified indicator across authorized telemetry.

Part 48 — Build the Domain Relationship Register

Domain	Relationship	Clients	Web Activity
Domain-A	Initial
Domain-B	Redirect
Domain-C	Final

Part 49 — Investigate Related IP Addresses

One domain may resolve to multiple addresses.

Likewise, multiple domains may resolve to shared infrastructure.

Do not automatically infer common malicious ownership.

Part 50 — Build the Domain-to-IP Matrix

Domain	IP	First Seen	Last Seen	Clients

Part 51 — Search IOC Activity

Search the supplied telemetry for:

Domain

URL

Resolved IP

Redirect Domain

Downloaded File Hash

Build:

IOC	DNS	Proxy	Endpoint	Network	Email
Domain	✓	✓			✓
URL		✓			✓
IP				✓
Hash			✓

Part 52 — Interpret IOC Matches Correctly

Remember:

IOC Match ≠ Compromise

An indicator match should trigger investigation.

It should not replace investigation.

Part 53 — Investigate Security-Control Outcomes

Determine whether controls:

• detected domain

• blocked resolution

• blocked URL

• prevented download

• quarantined file

• terminated process

Create:

Control	Detection	Prevention	Evidence
DNS Security
Proxy
Firewall
EDR

Part 54 — Identify Positive Security Controls

Examples:

DNS security blocked the domain.

Proxy prevented web access.

Web filtering blocked the download.

EDR quarantined the downloaded file.

Firewall prevented outbound communication.

User reported the suspicious website.

Positive controls reduce actual exposure and should appear in the report.

Part 55 — Investigate Possible Credential-Phishing Activity

If the web evidence relates to Lab 06, determine whether the user:

Reached phishing page

Submitted form

Generated subsequent authentication activity

But:

POST Request ≠ Credentials Submitted Automatically

You may know data was submitted without knowing its exact contents.

Part 56 — Correlate Identity Activity After Web Access

Example:

15:21
DNS query

15:21
Web request

15:22
Phishing page loaded

15:24
POST request

15:32
Unexpected authentication

This sequence deserves escalation.

But evidence must still establish what each event means.

Part 57 — Build the Identity Correlation Register

Time	User	Web Activity	Identity Activity	Assessment

Part 58 — Investigate Possible Automated Communication

If no interactive browser activity exists, ask whether traffic was generated by:

• application

• service

• endpoint agent

• suspicious process

• scheduled activity

Create:

AUTOMATION PROFILE

Host:

Process:

Parent Process:

User Context:

Domain:

Frequency:

Interactive User:
Yes / No / Unknown

Expected Application:
Yes / No / Unknown

Assessment:

Part 59 — Analyze Periodicity

Example:

15:00
Query

15:05
Query

15:10
Query

15:15
Query

This is periodic.

But:

Periodicity ≠ Malicious Beaconing Automatically

Compare with process and application context.

Part 60 — Build the Periodicity Register

Event	Interval	Count	Process	Expected
DNS Query	5 min	12
Web Request	5 min	12

Part 61 — Investigate Unusual Query Volume

High DNS volume can have many explanations.

Examples:

• application behavior

• browser activity

• endpoint security software

• configuration problem

• service discovery

• suspicious automated behavior

Do not label unusual volume as tunneling without supporting evidence.

Part 62 — Identify Telemetry Gaps

Examples:

No endpoint process mapping

Proxy bypass possible

DNS logs missing for part of window

Encrypted HTTPS content

No user attribution

NAT obscures client identity

No file hash available

No identity telemetry

Create:

Gap	Investigation Impact	Confidence Effect
No process telemetry	Cannot identify requesting process	Medium

Part 63 — Build the Master DNS/Web Timeline

Example:

15:18
Phishing email delivered

15:20
User opened email

15:21:02
DNS query for account-update.example.test

15:21:03
DNS response returned 203.0.113.50

15:21:05
Proxy observed HTTPS request

15:21:05
Request allowed

15:21:06
HTTP redirect observed

15:21:07
Final web resource requested

15:22
File downloaded

15:23
File created on endpoint

15:24
Endpoint alert generated

15:32
Unexpected authentication observed

15:40
SOC investigation started

This timeline connects multiple SOC domains.

Part 64 — Build the Activity Chain

Example:

Phishing Email
      │
      ▼
User Click
      │
      ▼
DNS Query
      │
      ▼
Domain Resolution
      │
      ▼
Web Request
      │
      ▼
Redirect
      │
      ▼
Download
      │
      ▼
Endpoint Event
      │
      ▼
Identity Activity

Only include stages supported by evidence.

Part 65 — Determine DNS Scope

Create:

DNS SCOPE

Primary Domain:

Related Domains:

Resolved IPs:

Clients:

Users:

Query Count:

First Seen:

Last Seen:

Blocked Queries:

Successful Responses:

Part 66 — Determine Web Scope

Create:

WEB SCOPE

Domains Accessed:

URLs:

Users:

Hosts:

Allowed Requests:

Blocked Requests:

Redirects:

Downloads:

Files:

First Seen:

Last Seen:

Part 67 — Determine Endpoint Scope

Create:

ENDPOINT SCOPE

Hosts with DNS Query:

Hosts with Web Request:

Hosts with Download:

Hosts with Execution:

Hosts with Endpoint Alert:

Hosts Requiring Investigation:

Part 68 — Determine User Scope

Create:

USER SCOPE

Users Receiving Related Email:

Users Querying Domain:

Users Accessing URL:

Users Downloading Content:

Users with Identity Anomalies:

Privileged Users:

Unknown User Attribution:

Part 69 — Separate Exposure Levels

A useful model is:

Level 1
Domain Query

Level 2
Domain Resolved

Level 3
Web Connection

Level 4
Web Resource Accessed

Level 5
Content Downloaded

Level 6
Content Executed

Level 7
Security Impact Observed

This prevents overstatement.

Part 70 — Build the Exposure Matrix

Host	DNS	Web	Download	Execution	Impact
WIN-FIN-02	Yes	Yes	Yes	Unknown	Review
WIN-HR-04	Yes	Blocked	No	No	None observed

Part 71 — Build Investigation Hypotheses

Hypothesis 1 — Expected Browsing

Expected user
+
approved domain
+
browser process
+
normal activity

Hypothesis 2 — False Positive / Benign Domain

Security alert
+
legitimate business service
+
no suspicious correlation

Hypothesis 3 — Phishing Interaction

Phishing email
+
matching URL
+
DNS query
+
web request

Hypothesis 4 — Suspicious Automated Communication

Non-browser process
+
unexpected domain
+
repeated communication

Hypothesis 5 — Potential Security Incident

Suspicious domain
+
web access
+
download or suspicious process
+
endpoint/identity correlation

Part 72 — Create the Hypothesis Matrix

Hypothesis	Supporting Evidence	Contradicting Evidence	Confidence
Expected browsing
Benign/false positive
Phishing interaction
Automated communication
Security incident

Part 73 — Determine the SOC Disposition

Use consistent classifications.

Expected Activity

DNS/web activity matches approved business use.

Benign

Activity is harmless.

False Positive

Detection logic triggered on legitimate behavior.

Suspicious

Evidence is anomalous but incomplete.

Confirmed Phishing Interaction

Evidence supports interaction with the phishing infrastructure.

Potential Security Incident

Multiple telemetry sources support possible compromise.

Confirmed Security Incident

Evidence establishes unauthorized malicious activity and relevant impact.

Inconclusive

Available evidence cannot support a reliable conclusion.

Part 74 — Example — Domain Queried but Blocked

DISPOSITION:
Suspicious DNS Activity — Blocked

HOST:
WIN-HR-04

DOMAIN:
account-update.example.test

EVIDENCE:
The endpoint attempted to resolve a domain associated with the
simulated phishing investigation.

DNS security blocked the request.

SUBSEQUENT WEB ACTIVITY:
Not observed.

DOWNLOAD:
Not observed.

ENDPOINT IMPACT:
Not observed.

SEVERITY:
Low

CONFIDENCE:
High

POSITIVE CONTROL:
DNS security prevented further access.

Part 75 — Example — Phishing URL Accessed

DISPOSITION:
Confirmed Phishing Interaction

USER:
finance-user

HOST:
WIN-FIN-02

EVIDENCE:
The phishing domain identified in the email investigation was
resolved by the recipient endpoint.

Proxy telemetry recorded a subsequent web request to the matching
URL.

The request was allowed.

DOWNLOAD:
Not observed.

CREDENTIAL SUBMISSION:
Unconfirmed.

ENDPOINT COMPROMISE:
Not established.

SEVERITY:
Medium

CONFIDENCE:
High

Part 76 — Example — Potential Security Incident

DISPOSITION:
Potential Security Incident

HOST:
WIN-FIN-02

USER:
finance-user

EVIDENCE:
The endpoint resolved and accessed a suspicious domain associated
with the phishing case.

Web telemetry recorded a file download.

Endpoint telemetry subsequently recorded execution-related
activity associated with the downloaded file.

Unexpected authentication activity was also identified during
the investigation window.

KNOWN IMPACT:
Requires additional endpoint and identity investigation.

SEVERITY:
High

CONFIDENCE:
High

ESCALATION:
Required.

Part 77 — Assign Severity

Consider:

• domain classification

• user interaction

• privileged user involvement

• allowed vs blocked access

• download

• execution

• endpoint activity

• identity anomalies

• number of hosts

• critical asset involvement

• control effectiveness

Part 78 — Assign Confidence Separately

Example:

Phishing Interaction:
Confirmed

Confidence:
High

Credential Exposure:
Possible

Confidence:
Low

Endpoint Compromise:
Potential

Confidence:
Medium

This is more precise than one generic confidence score.

Part 79 — Determine Containment Recommendations

Depending on evidence:

• block domain

• block URL

• block related IP

• remove related phishing emails

• quarantine downloaded file

• isolate affected endpoint

• protect affected account

• revoke sessions

• increase monitoring

• preserve logs

Document actions rather than performing disruptive changes unless explicitly authorized.

Part 80 — Build the Containment Decision Matrix

Action	Required	Reason	Impact	Approval
Block domain
Block URL
Block IP
Quarantine file
Isolate endpoint
Protect account

Part 81 — Determine Escalation

Escalate when:

• phishing URL was successfully accessed

• suspicious file downloaded

• execution suspected

• unexpected authentication follows interaction

• privileged user affected

• multiple hosts contacted the indicator

• suspicious automated communication exists

• security controls failed to prevent activity

• containment is required

Part 82 — Build the Escalation Package

ESCALATION SUMMARY

Case ID:

Alert:

Primary Domain:

Related Domains:

Resolved IPs:

Primary Host:

Primary User:

DNS Activity:

Web Activity:

Proxy Action:

Redirects:

Downloads:

Process:

Endpoint Correlation:

Identity Correlation:

Other Hosts:

Other Users:

Known Impact:

Unconfirmed Concerns:

Severity:

Confidence:

Containment Recommendation:

Evidence References:

Part 83 — Build the DNS/Web Evidence Register

Evidence ID	Source	Description
EV-WEB-01	SIEM	Original alert
EV-WEB-02	DNS	Query evidence
EV-WEB-03	DNS	Resolution evidence
EV-WEB-04	Firewall	Connection
EV-WEB-05	Proxy	Web request
EV-WEB-06	Proxy	Redirect
EV-WEB-07	Endpoint	Process activity
EV-WEB-08	Email	Related phishing URL
EV-WEB-09	Identity	Related authentication

Part 84 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
DNS & Web Traffic Investigation

Case ID:

Analyst:

Date:


INITIAL ALERT

Alert ID:

Alert:

Time:

Client:

Domain:

Query Type:

Initial Severity:


CLIENT

IP:

Hostname:

User:

Department:

Role:

Criticality:

Network Segment:


DNS ANALYSIS

Domain:

Query Type:

Resolver:

Response:

Resolved IP:

Query Count:

First Seen:

Last Seen:

DNS Security Action:


DOMAIN ANALYSIS

Expected Business Domain:
Yes / No / Unknown

Related Phishing Case:
Yes / No

Related Domains:

Related IPs:

Assessment:


NETWORK CORRELATION

Resolved IP:

Connection Observed:
Yes / No

Port:

Protocol:

Allowed / Blocked:

Connection Time:


WEB ANALYSIS

URL:

Method:

Status:

Proxy Action:

Redirect:

Final URL:

Bytes:

User-Agent:
If available


DOWNLOAD

File:

Type:

Hash:

Downloaded:
Yes / No

Endpoint Observed:
Yes / No

Execution:
Yes / No / Unknown


PROCESS CORRELATION

Process:

Parent:

User:

Host:

Expected Process:

Automated:
Yes / No / Unknown


EMAIL CORRELATION

Related Email:

Sender:

Recipient:

URL Match:

Timeline Match:


IDENTITY CORRELATION

Unexpected Authentication:

MFA Activity:

Source:

Time:

Relationship:


SCOPE

Hosts Querying Domain:

Hosts Accessing URL:

Users:

Downloads:

Executions:

Identity Anomalies:


SECURITY CONTROLS

DNS Security:

Proxy:

Firewall:

EDR:

Email Security:


TELEMETRY GAPS

Gap 01:

Impact:

Gap 02:

Impact:


FINAL ASSESSMENT

Disposition:

DNS Activity:
Expected / Suspicious / Malicious / Inconclusive

Web Interaction:
Confirmed / Not Observed / Unknown

Download:
Confirmed / Not Observed / Unknown

Execution:
Confirmed / Not Observed / Unknown

Compromise:
Confirmed / Potential / Not Established

Severity:

Confidence:

Known Impact:

Escalation:
Yes / No

Containment:
Yes / No

Remaining Questions:

Ready for SIEM Search & Correlation:
Yes / No

Part 85 — What Not to Do

Do not:

Browse suspicious domains directly

Click suspicious URLs

Follow suspicious redirects manually

Download suspicious files for testing

Execute downloaded content

Submit credentials to suspicious websites

Attempt to interact with external threat infrastructure

Assume DNS query means web access

Assume successful DNS response means connection

Assume HTTP 200 means legitimate content

Assume HTTP POST means credentials were stolen

Assume redirect means malicious activity

Assume download means execution

Assume IOC match means compromise

Assume periodic DNS means command-and-control

Assume high DNS volume means DNS tunneling

Assume encrypted traffic means malicious traffic

Block production domains without approval

Delete evidence

Overstate impact

The professional rule is:

Reconstruct activity from existing telemetry instead of recreating potentially dangerous activity yourself.

Troubleshooting

DNS Query Exists but No Web Request Exists

Possible explanations include:

• user/application did not continue

• security control blocked activity

• browser prefetch

• application lookup

• missing proxy telemetry

Document:

DNS resolution observed.

Subsequent web interaction not established.

Web Request Exists but DNS Evidence Is Missing

Possible explanations:

• cached DNS response

• alternate resolver

• missing logs

• direct IP connection

Do not invent the missing query.

Domain Resolved to Multiple IP Addresses

Document all observed addresses and correlate each with network telemetry.

Proxy Shows Blocked

Do not report successful web access unless another telemetry source demonstrates it.

HTTP 200 Is Observed

It demonstrates successful request handling, not benign content.

POST Request Is Observed

Document the method.

Do not claim credential theft without supporting evidence.

Download Is Observed but Endpoint Execution Is Missing

Record:

Download:
Confirmed

Execution:
Not established

Same Domain Appears Across Many Hosts

Determine whether the domain is:

• common business infrastructure

• shared cloud infrastructure

• advertising/analytics

• security tooling

• part of the simulated suspicious campaign

Scope before escalating.

Evidence Requirements

Capture:

Evidence 01

Original alert.

Evidence 02

Investigation scope.

Evidence 03

Client Profile.

Evidence 04

DNS Query Profile.

Evidence 05

DNS Event Register.

Evidence 06

DNS Response Register.

Evidence 07

Query frequency analysis.

Evidence 08

Domain Profile.

Evidence 09

Resolved-IP correlation.

Evidence 10

DNS-to-Network Register.

Evidence 11

Web Event Profile.

Evidence 12

URL Register.

Evidence 13

HTTP Method Register.

Evidence 14

Response Register.

Evidence 15

Redirect chain.

Evidence 16

Web Security Outcome.

Evidence 17

Download Profile.

Evidence 18

Web-to-Endpoint Register.

Evidence 19

Process-to-Web Register.

Evidence 20

User Web Profile.

Evidence 21

Authentication correlation.

Evidence 22

Multiple-client analysis.

Evidence 23

Domain Relationship Register.

Evidence 24

Domain-to-IP Matrix.

Evidence 25

IOC Correlation Matrix.

Evidence 26

Security Control Outcome Matrix.

Evidence 27

Identity Correlation Register.

Evidence 28

Automation Profile.

Evidence 29

Periodicity Register.

Evidence 30

Telemetry Gap Register.

Evidence 31

Master DNS/Web Timeline.

Evidence 32

Activity Chain.

Evidence 33

DNS Scope.

Evidence 34

Web Scope.

Evidence 35

Endpoint Scope.

Evidence 36

User Scope.

Evidence 37

Exposure Matrix.

Evidence 38

Hypothesis Matrix.

Evidence 39

Containment Decision Matrix.

Evidence 40

Escalation Package.

Evidence 41

DNS/Web Evidence Register.

Evidence 42

Mission Challenge worksheet.

Mission Deliverables

Complete:

• SOC case opened

• original alert preserved

• investigation window established

• client identified

• client IP mapped to correct host/time

• DNS query analyzed

• query type identified

• DNS response analyzed

• resolved addresses documented

• failed responses reviewed

• query frequency analyzed

• domain profile created

• domain compared with previous case evidence

• resolved IP searched across telemetry

• DNS-to-network correlation completed

• proxy/web telemetry reviewed

• URLs analyzed safely

• HTTP methods reviewed

• response codes reviewed

• redirects reconstructed

• web filtering outcome documented

• downloads investigated

• endpoint telemetry correlated

• responsible process identified where possible

• user context established

• authentication activity correlated

• related clients searched

• related domains searched

• related IP addresses searched

• IOC matrix completed

• security-control outcomes documented

• positive controls documented

• potential credential-phishing evidence evaluated

• automated activity considered

• periodicity analyzed

• telemetry gaps documented

• master timeline reconstructed

• activity chain reconstructed

• DNS scope determined

• web scope determined

• endpoint scope determined

• user scope determined

• exposure levels distinguished

• hypotheses evaluated

• final disposition assigned

• severity assigned

• confidence assigned separately

• containment recommendations documented

• escalation decision documented

• final DNS & Web Investigation Report completed

Lab Report Template

# Lab 09 — DNS & Web Traffic Investigation

## Executive Summary

## Mission Objective

## Case Information

## Initial Alert

## Investigation Scope

## Client Analysis

## DNS Query Analysis

## DNS Response Analysis

## Query Frequency Analysis

## Domain Analysis

## Domain-to-IP Analysis

## Network Correlation

## Web / Proxy Analysis

## URL Analysis

## HTTP Method Analysis

## HTTP Response Analysis

## Redirect Analysis

## Download Analysis

## Process Correlation

## Endpoint Correlation

## User Context

## Email Correlation

## Identity Correlation

## IOC Correlation

## Related Host Analysis

## Security-Control Outcomes

## Positive Security Controls

## Telemetry Gaps

## Master Timeline

## Activity Chain

## DNS Scope

## Web Scope

## Endpoint Scope

## User Scope

## Exposure Assessment

## Hypothesis Analysis

## Final Disposition

## Severity

## Confidence

## Known Impact

## Containment Recommendations

## Escalation Decision

## Evidence Register

## Remaining Questions

## Limitations

## Conclusion

Knowledge Check

Question 1 — Does a DNS query prove the client visited a website?

No.

A DNS query demonstrates name-resolution activity.

Question 2 — Does successful DNS resolution prove a connection occurred?

No.

Network telemetry is required to establish subsequent communication.

Question 3 — Does HTTP 200 mean the website is legitimate?

No.

A malicious web server can return a successful response.

Question 4 — Does HTTP POST prove credentials were stolen?

No.

POST is widely used by legitimate applications. Additional evidence is required.

Question 5 — Why correlate DNS with proxy telemetry?

DNS identifies the requested domain, while proxy/web telemetry can help establish subsequent application-level interaction.

Question 6 — Does a file download prove execution?

No.

Download and execution are separate events.

Question 7 — Why identify the responsible process?

It helps distinguish interactive browsing, legitimate application activity, and potentially suspicious automated communication.

Question 8 — Does periodic DNS activity prove malware beaconing?

No.

Many legitimate applications generate periodic DNS and network traffic.

Question 9 — Why investigate the same domain across multiple hosts?

To determine organizational exposure and distinguish a single-host event from broader activity.

Question 10 — What is the central question?

“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?”

Skills Achieved

After completing this lab, you should understand:

• DNS investigation

• DNS query interpretation

• DNS response analysis

• domain-to-IP correlation

• DNS frequency analysis

• web/proxy log analysis

• URL analysis

• HTTP method interpretation

• HTTP response interpretation

• redirect-chain analysis

• download investigation

• process-to-web correlation

• user attribution

• endpoint correlation

• identity correlation

• IOC correlation

• multi-host scoping

• DNS/web timeline reconstruction

• exposure assessment

• security-control validation

• containment planning

• SOC escalation

• investigation reporting

Professional Takeaway

A weak investigation looks like:

Suspicious Domain
      ↓
DNS Query
      ↓
Malware
      ↓
Compromised Host

A professional investigation looks like:

Suspicious Domain
      ↓
Identify Client
      ↓
DNS Query
      ↓
DNS Response
      ↓
Resolved IP
      ↓
Network Connection?
      ↓
Proxy / Web Request?
      ↓
Allowed / Blocked?
      ↓
Redirect / Download?
      ↓
User + Process
      ↓
Endpoint + Identity
      ↓
Other Hosts
      ↓
Timeline
      ↓
Scope
      ↓
Evidence-Based Disposition

Always distinguish:

DNS Query
   ≠
Web Access

DNS Resolution
   ≠
Connection

Connection
   ≠
Malicious Activity

HTTP 200
   ≠
Legitimate Content

HTTP POST
   ≠
Credential Theft

URL Request
   ≠
File Download

File Download
   ≠
Execution

IOC Match
   ≠
Compromise

Periodic DNS
   ≠
Command-and-Control

Many DNS Queries
   ≠
DNS Tunneling

The strongest analyst does not stop at:

“This endpoint queried a suspicious domain.”

They continue until they can explain:

“Which endpoint and process generated the query, what address was returned, whether a subsequent web connection occurred, what the web server returned, whether content was downloaded or executed, what other systems were involved, and what security impact the evidence actually demonstrates.”

What’s Next?

➡️ Lab 10 — SIEM Search, Filtering & Event Correlation

In the next lab, you will bring together the evidence sources used throughout the SOC track and investigate them from the perspective of a centralized SIEM.

You will work with:

• time-range selection

• event filtering

• host searches

• username searches

• IP searches

• domain searches

• event-type searches

• field-based filtering

• pivots between data sources

• related-event discovery

• alert-to-event validation

• authentication events

• endpoint telemetry

• DNS events

• firewall events

• proxy events

• email events

• timeline construction

• saved searches

• evidence export

• investigation documentation

The methodology becomes:

Alert → Search → Filter → Pivot → Correlate → Timeline → Scope → Conclusion

And the central question will be:

“Can you use centralized security telemetry to move from one alert to the complete set of related events needed to explain what actually happened?”