Lab Environment
This lab moves from a controlled Docker environment to a real-world malware pcap. Previous labs — Lab Log 001 and Lab Log 002 — generated traffic intentionally — Nmap scans, tcpdump captures — in an isolated container. This exercise uses a packet capture from malware-traffic-analysis.net (2026-02-28), a site maintained by security researchers that publishes real malware traffic captures for analyst training.
The scenario: an IDS alert fired. An internal IP was flagged for suspicious outbound connections to 45.131.214.85 over TCP port 80. The pcap of that traffic has been retrieved. The task is to identify the infected machine and document what the malware was doing — the same workflow a SOC analyst runs before escalating to incident response.
Methodology — The Standard Host Identification Workflow
When a SOC analyst receives a pcap linked to a suspicious IP alert, the first objective is always the same: identify the machine and user behind that IP. The three-step workflow below applies to any Windows Active Directory environment.
Step 1 — DHCP: Machine Identity
DHCP (Dynamic Host Configuration Protocol) is how a Windows machine announces itself when it boots. The DHCP Request packet contains the machine's self-reported identity: its MAC address, hostname, and the IP address it is requesting. One filter, one packet, three answers.
Key rule: Always examine the Request packet, not the ACK. The Request comes from the client and contains the client's information. The ACK comes from the DHCP server and contains the server's configuration. If you want to know about the machine, read what the machine said.
dhcp → Click the Request packet (source: 0.0.0.0) → Expand packet details and look for: Client MAC address Option (12) Host Name Option (50) Requested IP Address
Step 2 — Kerberos: User Identity
DHCP identifies the machine. Kerberos identifies the person logged into it. Every Windows domain login generates a Kerberos AS-REQ — the machine telling the domain controller "this user wants to authenticate." The CNameString field inside the AS-REQ contains the username.
kerberos → Find an AS-REQ packet in the Info column → Expand: req-body → cname → cname-string → CNameString = username → realm = Active Directory domain name
Step 3 — HTTP: Malware Behavior
With machine and user identified, the next step is understanding what the malware was doing. HTTP traffic is unencrypted — every request and response is fully readable. Filtering to non-Microsoft HTTP strips out Windows Update noise and surfaces only suspicious external connections.
http.request and !(http.host contains "microsoft") and !(http.host contains "windowsupdate") and !(http.host contains "msocsp") → Eliminates Windows Update background noise → What remains is worth investigating
Protocol Hierarchy — Reading the Capture at a Glance
Before applying any filters, Statistics → Protocol Hierarchy gives an immediate map of the entire capture. The distribution of protocols tells a story about the environment and where to focus attention.
Analyst note: HTTP at only 2.3% stands out because modern legitimate web traffic is almost entirely HTTPS. Unencrypted HTTP in 2026 is either legacy software, a misconfigured application, or malware that does not bother encrypting its C2 communications. All three warrant investigation.
Host Identification
Applying the DHCP and Kerberos filters in sequence produced all four required identifiers within minutes of opening the capture.
DHCP Analysis — Packet 2 (DHCP Request)
Filtering to dhcp returned 4 packets. Packet 2 was the Request — the client's self-introduction to the network. The machine's identity was in the DHCP options fields.
Packet 2 — DHCP Request (source: 0.0.0.0 → 255.255.255.255) Client MAC address: Intel_b2:4d:ad (00:19:d1:b2:4d:ad) Option (50) Requested IP Address: 10.2.28.88 Option (12) Host Name: DESKTOP-TEYQ2NR Packet 104 — DHCP ACK Server 10.2.28.1 confirmed IP assignment to 10.2.28.88
Kerberos Analysis — AS-REQ Packets
Filtering to kerberos returned 16 packets. Expanding any AS-REQ and navigating to req-body → cname → cname-string revealed the username. The realm field confirmed the Active Directory domain.
AS-REQ — Authentication Service Request req-body: cname: CNameString: brolf ← username realm: EASYAS123 ← Active Directory domain sname: SNameString: krbtgt ← Kerberos Ticket Granting Ticket
Confirmed Host Identity
Malware Behavior Analysis
With the infected host identified, the next step is understanding what the malware was doing. Applying the external HTTP filter stripped out Windows Update traffic, leaving only connections to non-Microsoft hosts. The result was unambiguous.
C2 Communication — POST to 45.131.214.85
Every non-Microsoft HTTP request in the capture was a POST to the same external IP — 45.131.214.85 — at the path /fakeurl.htm. This is the command-and-control server. The 264 POST requests were not user-initiated web traffic. They were automated check-ins from malware running on brolf's machine.
POST http://45.131.214.85/fakeurl.htm HTTP/1.1 Content-Type: application/x-www-form-urlencoded HTML Form URL Encoded payload: Key: CMD Value: POLL\nINFO=1\nACK=1\n Translation: POLL → "I am alive, do you have instructions for me?" INFO=1 → "Send me information back" ACK=1 → "Acknowledge this message" This is a beacon check-in. The malware reports its presence to the C2 server and waits for commands.
Why /fakeurl.htm? In this training exercise the URL was named obviously for educational purposes. In a real attack the path would be indistinguishable from legitimate traffic — /api/v2/telemetry or /assets/config.json. Detection cannot rely on the URL name — it must rely on the behavior: same destination, same payload structure, same interval, repeated hundreds of times.
Beacon Interval Analysis
Examining timestamps on consecutive POST packets revealed a consistent 60-second interval between check-ins after an initial burst of activity. This regularity is the defining characteristic of automated beaconing — no human produces network traffic at machine-precision intervals for 4+ hours.
Packet timestamps (seconds since capture start): T+45.04 POST /fakeurl.htm ← initial burst T+45.19 POST /fakeurl.htm T+45.55 POST /fakeurl.htm T+45.75 POST /fakeurl.htm T+105.93 POST /fakeurl.htm ← Δ 60.18s T+166.00 POST /fakeurl.htm ← Δ 60.07s T+226.08 POST /fakeurl.htm ← Δ 60.08s T+286.16 POST /fakeurl.htm ← Δ 60.08s T+346.34 POST /fakeurl.htm ← Δ 60.18s ... pattern continues for entire 15,600-second capture 264 total POST requests · ~60-second interval · machine-precision timing
The I/O Graph (Statistics → I/O Graph, filter: ip.dst == 45.131.214.85) confirmed the pattern visually — a perfectly regular sequence of single-packet spikes running continuously across the entire capture with no gaps or variation.
Findings
Host DESKTOP-TEYQ2NR (10.2.28.88, user: brolf) has been actively beaconing to external IP 45.131.214.85 via unencrypted HTTP POST for the entire duration of the capture. The malware survived at minimum one full working day without detection. The beacon payload CMD=POLL indicates the malware is in a listening state — waiting for commands from the operator.
The machine must be isolated immediately. The C2 channel is open and the operator can issue commands at any time.
The malware communicates over plain HTTP rather than HTTPS. This is unusual for modern malware — most contemporary C2 frameworks use TLS to evade detection. The unencrypted channel allowed full visibility into the beacon payload and command structure. The POLL/INFO/ACK command structure and 60-second beacon interval are characteristic of a remote access trojan (RAT) framework.
SMB2 and Active Directory traffic in the capture appears consistent with normal domain activity. No anomalous internal scanning, credential harvesting, or connections to other internal hosts from 10.2.28.88 were observed in this pcap. This does not confirm containment — the malware may use encrypted channels for lateral movement — but there is no evidence of active spreading behavior in this capture.
Wireshark Filter Reference — Analyst Workflow
The filters below form a repeatable workflow for host identification and malware behavior analysis in any Windows Active Directory pcap. Applied in sequence, they answer the four core questions of initial triage: what is the machine, who is the user, what external hosts is it talking to, and is the behavior automated or human.
Beaconing detection tip: After isolating traffic with ip.dst ==, right-click any column header → Column Preferences → add a column with type "Delta time displayed." Scroll through — if the same interval repeats consistently, that is automated beaconing. Use Statistics → I/O Graph with the same filter to visualize the pattern across the full capture.
NIST SP 800-171 Control Mapping
Lessons Learned
DHCP and Kerberos Are the First Two Filters in Any Windows Triage
The answer to "whose machine is this and who was logged in?" lives in two places in every Windows pcap: the DHCP Request packet and the Kerberos AS-REQ. These filters are not specific to this exercise or this malware family — they work on any pcap from any Windows Active Directory environment. The first two questions of any triage can be answered in under five minutes.
Beaconing Is Unmistakable Once You Know What to Look For
264 POST requests to the same external IP at 60-second intervals for 4.3 hours. No human behavior produces that pattern. The I/O Graph made it visually obvious — a perfectly regular sequence of spikes that no legitimate application generates. Recognizing the visual signature of beaconing transfers to every future pcap analysis regardless of malware family.
Unencrypted C2 Is a Gift to the Defender
This malware communicated over plain HTTP. The entire beacon payload — CMD=POLL\nINFO=1\nACK=1 — was readable in cleartext. When C2 is unencrypted, the defender can read exactly what the malware is saying, identify the command structure, and build precise detection rules. Always check HTTP first.
The SOC Rule This Analysis Produces
Recommended alert rule: Any internal IP sending more than 5 HTTP POST requests to the same external IP within a 10-minute window, where the POST payload contains CMD=POLL, constitutes a confirmed C2 beacon. Isolate the source host immediately and escalate to incident response.
Next Lab
Lab Log 004 will cover building a custom Wireshark analyst profile — color-coded packet rules, an optimized column layout including Delta Time, and a one-click filter toolbar that automates the workflow demonstrated in this lab. The profile will be documented as a reusable tool for any Windows environment triage.