11 - Network Analysis for Incident Detection

Network Analysis for Incident Detection

Objectives: By the end of this topic, you will be able to…

• Distinguish the three types of network telemetry used in security operations
• Map attacker activity to observable traffic patterns across the attack lifecycle
• Identify a compromised host and its user from DHCP, Kerberos, and LDAP traffic
• Trace a malware C2 channel from an IDS alert to its domain and HTTP payload
• Extract and structure network indicators of compromise (IOCs) from a packet capture
• Use Zeek to generate structured network logs from raw traffic
• Write a Suricata detection rule based on observed malware behavior

---

Network analysis in security operations

Network analysis is one of the primary tools available to a security operations center (SOC) analyst investigating an incident. Unlike endpoint forensics — which requires access to a specific machine — network evidence is collected passively at chokepoints (firewalls, switches, taps) and covers the entire environment. This makes it invaluable for answering the questions an incident responder always asks: What happened? When? To which systems? What data left the network?

The network analyst’s job is not simply to read packets. It is to distinguish normal traffic from anomalous traffic, extract evidence, and produce a timeline that supports a broader investigation.

---

Types of network telemetry

Security teams work with three complementary forms of network data, each with different trade-offs in granularity, storage cost, and detection capability:

Type	What is captured	Tools	Best used for
Full packet capture (PCAP)	Every byte of every packet, including payload	tcpdump, Wireshark	Deep inspection, payload analysis, forensics
Flow data (NetFlow / IPFIX)	Connection metadata only: source/dest IP, port, protocol, bytes, duration	nfdump, ntopng	Anomaly detection, volume analysis, long-term retention
Network logs	Parsed, protocol-aware records per session	Zeek (formerly Bro), Suricata	Structured querying, correlation, IOC matching

In practice, most organizations store flow data continuously and full PCAPs only for a rolling window (e.g., 24–72 hours), because full PCAP storage is expensive at scale. Detection rules trigger targeted PCAP captures when an alert fires.

---

The attack lifecycle in network traffic

Every phase of an intrusion leaves a characteristic network footprint. Knowing what to look for at each stage directs the analyst’s attention:

Phase	What the attacker does	Observable network pattern
Reconnaissance	Port scanning, service enumeration	Many SYN packets to sequential ports with no established connections; OS fingerprinting probes
Initial access	Exploiting a web app, phishing link, credential stuffing	Unusual HTTP POST volumes; authentication failures in rapid succession; connections to suspicious external IPs
Command & control (C2)	Maintaining persistent access from compromised host	Periodic outbound connections (beaconing) at fixed intervals; DNS queries for algorithmically generated domains (DGA); long-duration low-bandwidth sessions
Lateral movement	Spreading through the internal network	SMB/RDP connections between internal hosts that don’t normally communicate; LDAP enumeration queries; pass-the-hash artifacts
Exfiltration	Sending data out of the network	Large outbound transfers to external IPs; data in DNS TXT records (DNS tunneling); unusual volumes for non-standard ports

---

Detection-oriented protocol analysis

Rather than reading protocols for their own sake, incident detection trains the analyst to ask: what does malicious use of this protocol look like? The protocols below are the ones directly relevant to investigating a compromised Windows host on an Active Directory network.

DHCP

Every time a Windows device joins a network it broadcasts a DHCP Request to obtain an IP address. This packet contains two pieces of information that are invaluable for host identification:

• Option 12 (Hostname): the machine’s configured name, sent in plaintext
• Ethernet source address: the device’s MAC address, visible in every frame it transmits

DHCP is passive and automatic — the machine exposes this information simply by being on the network. An analyst who cannot access Active Directory logs can still identify a host by its DHCP traffic alone. The exchange follows four steps: Discover → Offer → Request → Acknowledge (DORA). The Request packet is the most useful because it originates from the client and includes the hostname option.

DNS

DNS is abused heavily because it is almost never blocked at the perimeter. For investigation, DNS is the bridge between IP addresses and domain names — including the domain names that malware uses.

Normal	Suspicious
Queries for known domains, low NXDOMAIN rate	High NXDOMAIN rate (DGA)
Short, consistent query intervals	Beaconing-interval queries to a single domain
Short labels, common TLDs	Long random-looking subdomains (tunneling)
Small responses	Large TXT responses carrying encoded data

DNS responses also let you work backwards from a known-malicious IP to the domain name: filter for DNS answers containing that IP address (dns.a == <IP>) to recover the domain the malware resolved.

HTTP

Unencrypted HTTP exposes the full request and response, including headers and body. For malware analysis this is ideal: the C2 channel, the URI the malware posts to, the data it sends, and any User-Agent it declares are all readable. Key indicators:

• User-Agent strings: malware often uses outdated, absent, or hardcoded User-Agent values that do not match normal browser patterns
• URI patterns: paths like /gate.php, /update, /fingerprint are common C2 naming conventions
• Request bodies: information-stealers send victim profile data (hardware ID, hostname, username) in POST bodies before exfiltrating credentials

When traffic moves to HTTPS, payload content is hidden but the destination hostname (via Server Name Indication in the TLS handshake) and JA3 fingerprint of the TLS client still remain visible.

Kerberos and LDAP

Kerberos is the authentication protocol used by Windows Active Directory. When a user logs in, the client sends an AS-REQ (Authentication Service Request) to the domain controller. This packet contains the CNameString field — the username — in plaintext, before any encryption occurs. This makes Kerberos traffic one of the most reliable sources for recovering the account name associated with a specific host IP.

LDAP (Lightweight Directory Access Protocol) is used to query Active Directory for user and group information. When a workstation resolves a user’s profile, the domain controller responds with directory attributes such as cn (common name, i.e. the user’s full name), mail, and memberOf. Both Kerberos and LDAP traffic flow between workstations and the domain controller, making them visible in any capture of internal network traffic.

---

Network indicators of compromise (IOCs)

A network IOC is an observable artifact in traffic that suggests malicious activity. Common categories:

IOC type	Examples	Extraction method
IP address	C2 server IP, scanner IP	tshark -T fields -e ip.src -e ip.dst
Domain name	C2 domain, DGA domain	DNS log or tshark -Y dns -T fields -e dns.qry.name
URL	Malware download path	tshark -Y http.request -T fields -e http.host -e http.request.uri
JA3 hash	TLS client fingerprint	Zeek ssl.log or ja3 package
User-Agent	Malware HTTP header	tshark -Y http -T fields -e http.user_agent
File hash	Malware transferred over HTTP	Extract objects in Wireshark, hash with sha256sum

IOCs feed into threat intelligence platforms (MISP, OpenCTI) and SIEM correlation rules. An IOC by itself is weak evidence; IOCs in combination across multiple data sources become high-confidence alerts.

---

Introduction to Zeek

Zeek (formerly Bro) is a network security monitor that reads packet captures or live traffic and produces structured, tab-separated log files — one per protocol. Instead of reading raw packets, an analyst can query these logs like a database.

Key Zeek log files:

Log file	Content
conn.log	Every TCP/UDP/ICMP flow: IPs, ports, duration, bytes
dns.log	Every DNS query and response
http.log	HTTP requests: method, host, URI, user-agent, status
ssl.log	TLS connections: server name, JA3, certificate info
files.log	Files transferred over HTTP, SMB, SMTP
weird.log	Protocol anomalies Zeek detected automatically

Installing Zeek on Kali Linux

Kali Linux is based on Debian 13, so use the Debian 13 binary package from the Zeek project:

# Add the repository
echo 'deb http://download.opensuse.org/repositories/security:/zeek/Debian_13/ /' | sudo tee /etc/apt/sources.list.d/security:zeek.list
 
# Import the GPG key
curl -fsSL https://download.opensuse.org/repositories/security:zeek/Debian_13/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/security_zeek.gpg > /dev/null
 
# Install Zeek
sudo apt update && sudo apt install zeek

Zeek installs to /opt/zeek/. Add its binaries to your PATH so you can run zeek and zeek-cut from any directory:

echo 'export PATH=$PATH:/opt/zeek/bin' >> ~/.zshrc
source ~/.zshrc

Once installed, Zeek can analyze any PCAP file offline:

mkdir zeek-output && cd zeek-output
zeek -r ../capture.pcap
ls *.log

---

Hands-on lab

Requirements: Kali Linux with Wireshark, tshark, Zeek, Suricata. The PCAP file (2026-01-31-traffic-analysis-exercise.pcap) is available for download on Moodle under the Class 11 materials.

Scenario

Your SOC’s intrusion detection system fired the following alert on 2026-01-27 at 23:05 UTC:

ET MALWARE Lumma Stealer Victim Fingerprinting Activity
Source: 10.1.21.0/24  →  153.92.1.49:80

Lumma Stealer is an information-stealing malware sold as a service on criminal forums. After infecting a Windows host, it fingerprints the victim machine — collecting hostname, username, hardware ID, and installed software — and sends this profile to a command-and-control server before exfiltrating credentials, browser cookies, and cryptocurrency wallets.

Your job is to work backwards from this alert to answer six questions the SOC manager needs answered within the hour:

1. What is the IP address of the infected Windows client?
2. What is its MAC address?
3. What is its hostname?
4. What user account was logged in at the time?
5. What is that user’s full name?
6. What domain is hosted at 153.92.1.49 — the server that triggered the alert?

You have one file: 2026-01-31-traffic-analysis-exercise.pcap. Work through the parts below in order.

---

Part 1: Survey the capture

Before chasing the alert, orient yourself. Know the shape of the traffic before narrowing your focus.

1. Parse the capture with Zeek to generate structured logs:

mkdir lab11-logs && cd lab11-logs
zeek -r ../2026-01-31-traffic-analysis-exercise.pcap
ls *.log

2. Get a protocol breakdown — -q suppresses per-packet output so only the summary is printed; -z io,phs generates a protocol hierarchy statistics table:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap -q -z io,phs

3. List all unique IP addresses present. tshark outputs source and destination as two tab-separated columns per packet; tr converts each tab to a newline so sort -u deduplicates across both columns:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -T fields -e ip.src -e ip.dst \
  | tr '\t' '\n' | sort -u

4. Confirm the alert IP appears in the capture — with -z conv,tcp, the display filter must be passed as the third argument inside the -z option (not via -Y), otherwise tshark ignores it:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -q -z "conv,tcp,ip.addr==153.92.1.49"

5. Check for automatic anomaly detection:

zeek-cut name addl < weird.log | sort | uniq -c | sort -rn

Question

How many unique internal IPs (10.1.21.0/24) appear in the capture? What protocols make up the majority of traffic? Does weird.log flag anything immediately? For each answer, identify which command produced it and explain why that specific command gives you that information — not just what the output shows.

---

Part 2: Identify the infected host

The infected machine contacted an external C2 server. Its IP, MAC address, and hostname are all visible in routine network protocols — you do not need to inspect malware payloads to find them.

DHCP is the most reliable source: when a Windows machine joins the network, it broadcasts a DHCP Request that includes its hostname (option 12) and its MAC address is visible as the Ethernet source.

1. Filter DHCP traffic and extract host identification fields. dhcp.option.hostname extracts DHCP Option 12 — the hostname the client declares in its Request packet. -E header=y prints field names as a header row so the output is self-labeling:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -Y "dhcp" \
  -T fields -e eth.src -e ip.src -e dhcp.option.hostname \
  -E header=y

2. Cross-check with ARP — the MAC will appear as the sender hardware address:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -Y "arp" \
  -T fields -e arp.src.hw_mac -e arp.src.proto_ipv4 \
  | sort -u

3. Confirm the hostname via DNS — the infected host likely queried the domain controller:

zeek-cut id.orig_h query < dns.log \
  | sort -u | grep "^10\.1\.21\."

In Wireshark, use the filter dhcp and open a DHCP Request packet. Expand Bootstrap Protocol → Options → Option: (12) Host Name for the hostname, and read the MAC from the Ethernet II → Source field.

Question

Record the IP address, MAC address, and hostname of the infected client. Do they belong to a single consistent machine? How did you confirm this? Which DHCP packet type (Discover, Offer, Request, or Acknowledge) is most useful for host identification, and why?

---

Part 3: Identify the user account

The hostname tells you which machine was infected. The user account tells you whose credentials and data were at risk. On a Windows Active Directory network, Kerberos authentication traffic reveals usernames in plaintext — even when the authentication itself is encrypted.

1. Extract Kerberos principal names from authentication requests. CNameString is the client principal name field in the AS-REQ (Authentication Service Request) — it is transmitted in plaintext before any encryption is negotiated:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -Y "kerberos.CNameString" \
  -T fields -e ip.src -e kerberos.CNameString \
  | sort -u

2. Filter to requests originating from the infected host IP:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -Y "kerberos.CNameString and ip.src == <INFECTED_IP>" \
  -T fields -e kerberos.CNameString \
  | sort -u

3. For the user’s full name, extract it from SAMR (Security Account Manager Remote) traffic — the workstation queries the domain controller via QueryUserInfo, which returns the full name stored in Active Directory:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -Y "samr" \
  -T fields -e samr.samr_UserInfo21.full_name \
  | sort -u | grep -v '^$'

In Wireshark: filter kerberos, find a KRB5 AS-REQ packet from the infected host, expand Kerberos → as-req → req-body → cname → cname-string to read the account name. For the full name, filter samr and look for QueryUserInfo response packets containing the Full Name field.

Question

What is the username of the logged-in account? What is their full name? Explain why Kerberos gives you the username but not the full name, and why SAMR is the right protocol to retrieve it. What does the presence of Kerberos traffic tell you about the network environment?

---

Part 4: Trace the C2 channel

With the victim identified, shift focus to the malicious traffic that triggered the alert. Understand what the malware was communicating and to whom.

1. Isolate all traffic to and from the C2 IP:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -Y "ip.addr == 153.92.1.49" \
  -T fields -e frame.time -e ip.src -e ip.dst -e tcp.dstport \
  -E header=y

2. Find the domain name the malware used to reach this IP. dns.a filters on the IP address in a DNS A record response — this lets you work backwards from a known IP to the domain that resolved to it:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -Y "dns.a == 153.92.1.49" \
  -T fields -e dns.qry.name -e dns.a

3. Examine the HTTP requests the malware sent — this is the victim fingerprinting activity:

tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -Y "http.request and ip.addr == 153.92.1.49" \
  -T fields -e http.host -e http.request.uri -e http.request.method -e http.user_agent

4. Check Zeek’s HTTP log for a structured view:

zeek-cut ts id.orig_h id.resp_h method host uri user_agent \
  < lab11-logs/http.log | grep "153\.92\.1\.49"

5. Inspect the request bodies to understand what data Lumma transmitted. In Wireshark, filter http and ip.addr == 153.92.1.49, right-click a POST request, and select Follow → TCP Stream to read the full exchange.

Question

What domain resolved to 153.92.1.49? What URIs did the malware request? What data fields appear in the request — what specifically was the malware “fingerprinting”? Explain how dns.a == <IP> works: does it match DNS queries or DNS responses, and why does that distinction matter?

---

Part 5: Extract and structure IOCs

Compile your findings into a structured IOC table. This is the artifact you hand to the threat intelligence team so the indicators can be blocked and shared across the organization.

# All external IPs the capture contacted.
# grep -Ev excludes RFC1918 private ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and loopback.
tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -T fields -e ip.dst \
  | grep -Ev '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)' \
  | sort | uniq -c | sort -rn
 
# All DNS domains queried
tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -Y "dns.flags.response == 0" \
  -T fields -e dns.qry.name | sort | uniq
 
# HTTP indicators
tshark -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -Y "http.request" \
  -T fields -e http.host -e http.request.uri -e http.user_agent \
  | sort | uniq

Build a table with at least 6 IOCs in this format:

Type	Value	Confidence	Source
IP address	153.92.1.49	High	IDS alert + PCAP confirmation
Domain	…	…	…
URL	…	…	…
User-Agent	…	…	…

Question

Which IOC type is most durable — least likely to change if the attacker rotates infrastructure? Which is least durable? What does this imply for your blocking strategy? For the external IP list, explain what the grep -Ev regex is doing — what address ranges does it exclude, and why are those excluded rather than included?

---

Part 6: Write and test a detection rule

The IDS rule that fired was named ET MALWARE Lumma Stealer Victim Fingerprinting Activity. In this part you will write a Suricata rule that reproduces that detection, run it against the same PCAP, and verify it fires.

Install Suricata:

sudo apt install suricata -y

Write the rule. Suricata rules must be written as a single line. Open a text editor and create lumma.rules:

nano lumma.rules

Enter the rule below — all on one line — replacing <METHOD> with the HTTP method from Part 4, and <URI_PATH> with the path component of the URI (e.g. /api/set_agent). Two important distinctions:

• http.uri matches the path only — everything after the domain, starting with /. Do not put the hostname here.
• http.host matches the Host header — the domain name (whitepepper.su). These are separate sticky buffers.
• Use the path, not the query string: /api/set_agent matches all requests to that endpoint regardless of the id and token parameters, which change per victim.

alert http $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Lumma Stealer Victim Fingerprinting Activity";flow:established,to_server;http.method; content:"<METHOD>";http.uri; content:"<URI_PATH>";classtype:trojan-activity;sid:9000001;rev:1;)

Save and exit (Ctrl+O, Enter, Ctrl+X).

Run Suricata against the PCAP:

mkdir suricata-output
sudo suricata -c /etc/suricata/suricata.yaml \
  -r ../2026-01-31-traffic-analysis-exercise.pcap \
  -S lumma.rules \
  -l suricata-output/ \
  -k none

The -S flag loads only your rules file, ignoring the default ruleset. The -k none flag skips checksum validation, which is necessary for PCAPs captured with hardware checksum offloading.

Verify the rule fired:

cat suricata-output/fast.log

Each matching packet produces one line in fast.log with a timestamp, the alert message, and the source and destination addresses. Count the alert lines and compare that number against the C2 requests you identified in Part 4.

If fast.log is empty, your rule did not match. Re-check the method and URI path — use tshark to confirm the exact values directly from the PCAP before editing lumma.rules and re-running.

Evaluate your rule:

• True positive rate: How many times did the rule fire? Does the count match the number of C2 requests from Part 4?
• False positive risk: What makes /api/set_agent distinctive enough to avoid firing on legitimate traffic?
• Evasion: Name one change the attacker could make that would prevent your rule from firing. How would you modify the rule to catch that variant?

Question

The original IDS signature fired on port 80 HTTP traffic. If the attacker had used HTTPS on port 443 instead, what would still be visible in the traffic? What would be hidden? Would your Suricata rule still fire?

---

Submission

ZIP archive containing:

• lab11-logs/ — your Zeek log directory
• iocs.csv — structured IOC table
• lumma.rules — your Suricata rule file
• suricata-output/fast.log — alert output confirming the rule fired
• Report (3–4 pages) answering all six SOC questions with evidence, covering:
  1. How you identified the infected host and user (which protocols, which fields)
  2. What the malware communicated to the C2 server
  3. Your IOC table with confidence ratings
  4. Your Suricata rule, the alert count from fast.log, and your evasion evaluation
  5. Reflection: what would an analyst lose if this traffic had been encrypted with TLS?

---

Key concepts

Term	Definition
Wireshark	Graphical packet analyzer used for deep inspection of individual frames
Sniffing	Passive capture of network traffic passing through an interface
IPS	Systems that detect (IDS) or block (IPS) malicious network activity in real time
IOC	Observable artifact in network traffic or system logs indicating a compromise
DNS	Protocol that resolves domain names to IP addresses; commonly abused for C2 and tunneling
DHCP	Protocol that assigns IP addresses; DHCP requests expose hostname and MAC address
Kerberos	Authentication protocol used by Active Directory; AS-REQ packets expose usernames in plaintext
LDAP	Protocol for querying Active Directory; used to retrieve user attributes such as full name
C2	Command and control: the channel an attacker uses to communicate with compromised hosts

---

Navigation: ← Previous | Home | Next →