Why This Lab Is Different Step Up from Lab 003
Lab 003 analyzed a compromised machine inside a network — an infected Windows workstation beaconing outward to a C2 server on a predictable 60-second interval. The scenario was relatively contained: one infected host, one C2 address, one malware family, clean beaconing signature.
This lab inverts that perspective entirely. Instead of watching malware phone home, we are analyzing a public-facing web server being attacked from the internet over seven consecutive days. The pcap file name tells the story: seven-days-of-scans-and-probes-and-web-traffic. What looks like noise at first glance is actually multiple distinct attackers, multiple attack vectors, and a server that — as this analysis will show — defended itself on every front while unknowingly advertising its own vulnerabilities in every response it sent.
This is harder than Lab 003 for three reasons. There is no single infected host to pivot from. There is no clean beaconing pattern to anchor the analysis. And not everything that looks suspicious is malicious — distinguishing normal internet background noise from genuine attack traffic is a core SOC analyst skill that this lab exercises directly.
Key insight before starting: 313,968 packets generating only 4MB of data means an average of roughly 13 bytes per packet. Real file transfers produce much larger packets. Small average packet size is the first indicator that this capture is dominated by scanning and probing — not data movement.
Identifying the Victim Server
Unlike Lab 003, there is no DHCP or Kerberos traffic to pivot from — this is a public internet server, not a domain-joined Windows workstation. The identification methodology changes completely. Instead of asking "whose machine is this?", the question becomes "what is this machine, and what is it running?"
The answer came from the server itself. Apache — like most web servers — includes a Server header in every HTTP response, including error responses. Filtering to any HTTP response and examining the headers revealed the server's identity immediately.
HTTP/1.1 400 Bad Request Date: Thu, 12 Mar 2026 14:25:08 GMT Server: Apache/2.4.58 (Ubuntu) ← exact version disclosed Content-Length: 324 Connection: close Content-Type: text/html; charset=iso-8859-1 Same header appeared in 200 OK, 404 Not Found, and 400 Bad Request responses. Every response the server sent — including error pages — disclosed its exact software version and operating system to every requestor.
The MAC address Rebox_cb:72:42 (OUI prefix 00:16:3c) confirmed the server is running on Xen hypervisor — the virtualization platform used by many cloud hosting providers. This is a cloud-hosted Virtual Private Server (VPS), sitting directly on the public internet with no firewall or reverse proxy in front of it.
Why version disclosure matters: Apache/2.4.58 (Ubuntu) is a precise attack surface fingerprint. An attacker receiving this response can immediately query the CVE database for vulnerabilities specific to Apache 2.4.58. The server is telling every scanner exactly what to target. This is not a vulnerability by itself — but it makes every other vulnerability easier to exploit. The fix is a single configuration line: ServerTokens Prod in apache2.conf, which reduces all responses to just Server: Apache with no version.
Protocol Hierarchy — Reading 7 Days at a Glance
Statistics → Protocol Hierarchy gives the first map of what seven days of internet-facing traffic looks like. The distribution tells a clear story before a single filter is applied.
Lab 003 vs Lab 008 — a critical difference: In Lab 003, HTTP traffic at 2.3% stood out because it was abnormally low for a corporate network — all traffic should have been HTTPS. Here, HTTP at 100% stands out because this is a public server in 2026 with no TLS. Both situations are suspicious, but for opposite reasons. Context determines meaning.
Four Attack Vectors — Analysis
Vector 1 — Mass SYN Port Scan
Filtering for TCP SYN packets with no corresponding ACK revealed the dominant attack pattern across the entire capture.
tcp.flags.syn == 1 and tcp.flags.ack == 0 and ip.dst == 203.161.44.208 Result: 108,506 packets Ports: Multiple — spanning well-known, registered, and ephemeral ranges Duration: Distributed across the entire 7-day capture window How a SYN scan works: Attacker sends SYN → "Is this port open?" Server sends SYN-ACK → "Yes, something is listening" ← open port Server sends RST → "Nothing here" ← closed port Attacker never completes the handshake — moves to next port
108,506 half-open connections over seven days is not a human typing commands — it is an automated tool, most likely Nmap or a similar scanner, systematically probing every port on the server to build a complete map of what services are exposed. This is reconnaissance — the attacker learning the attack surface before choosing how to strike.
What a SYN scan tells an attacker: Every open port is a potential entry point. Closed ports are confirmed dead ends. The scan result is essentially a blueprint of the server's exposed services — which the attacker then researches for known vulnerabilities. Port 80 being open and unfiltered is the direct result of this reconnaissance being useful.
Vector 2 — Backup File Exfiltration Attempt
Frame 66678 contained a GET request for /back_up.zip from external IP 54.70.53.60. Three red flags appeared in the request headers alone — before checking the response.
GET /back_up.zip HTTP/1.1 Host: 203.161.44.208 ← raw IP, not a domain — scanner behavior User-Agent: Chrome/143.0.0.0 ← Chrome 143 did not exist in March 2026 Upgrade-Insecure-Requests: 1 ← requests HTTPS but connecting on port 80 Accept-Encoding: gzip, deflate ← no br — automated tool, not a real browser Three indicators of a spoofed/automated request: 1. Raw IP in Host header — real users type domain names 2. Nonexistent browser version — fabricated user agent string 3. Contradictory headers — "prefer HTTPS" on an HTTP connection
Following the TCP stream to frame 66680 confirmed the server's response.
HTTP/1.1 404 Not Found Date: Thu, 12 Mar 2026 13:20:17 GMT Server: Apache/2.4.58 (Ubuntu) Content-Length: 276 <p>The requested URL was not found on this server.</p> Verdict: the file does not exist. No data was exfiltrated. The attack technique — requesting a predictably-named backup file from a web server's root — is a common opportunistic attack. Administrators who leave backup files publicly accessible have been compromised this way. This server was not.
Vector 3 — Web Shell Upload Attempt with EICAR Payload
Frame 67748 contained the most technically interesting packet in the capture — a POST request to /upload.exe carrying a 68-byte hex-encoded payload.
POST /upload.exe HTTP/1.1 Host: www.baidu.com ← Host header spoofed to different domain User-Agent: Mozilla/5.0 Content-Length: 68 Source IP: 163.123.236.83 Destination: 203.161.44.208 Payload (hex): 58354f2150254041505b345c505a58353428505e2937434329377d2445494341522d 5354414e444152442d414e544956495255532d544553542d46494c452124482b482a Decoded (CyberChef → From Hex): X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* This is the EICAR test string — a harmless sequence that every antivirus engine recognizes as a test signature. It is used by security researchers to verify that AV detection is working without deploying real malware. Why it matters here: the PAYLOAD was harmless, but the MECHANISM was not. A POST to a path ending in .exe via a web form is the standard technique for uploading a web shell — a backdoor that gives the attacker a command interface on the server. The attacker was testing whether the upload endpoint accepted executable content. The server rejected it.
Decoding the payload — using CyberChef: CyberChef (gchq.github.io/CyberChef) is a browser-based data transformation tool used by analysts to detect, decode, and analyze payloads without executing them. Paste the hex string into CyberChef, add the "From Hex" operation, and the plaintext payload appears instantly. This is the safe way to examine potentially malicious content — no execution, no risk.
The server's response in frame 67786 confirmed the upload was rejected: HTTP/1.1 400 Bad Request. The attacker's spoofed Host header pointing to www.baidu.com while the actual destination was 203.161.44.208 caused Apache to reject the malformed request entirely.
Vector 4 — RADIUS Authentication Probe
Frame 220 revealed a UDP probe targeting port 1812 — the RADIUS authentication protocol used by VPNs, routers, and wireless controllers for centralized login management.
Probe (inbound): Source: 205.210.31.197 Destination: 203.161.44.208 Protocol: UDP Destination Port: 1812 (RADIUS) Server response: ICMP Type 3 Code 3: Destination Unreachable — Port Unreachable Translation: nothing is listening on port 1812. The attacker was testing whether a RADIUS server was running — if found, it would have been a target for credential brute-force attacks against network authentication. The probe failed.
Findings & Verdict
An automated port scanner conducted sustained reconnaissance against 203.161.44.208 across the entire 7-day capture, probing across a wide port range. The scan mapped every open service on the server and produced a complete blueprint of its attack surface. Port 80 being open and unfiltered was confirmed by this scan and directly enabled the HTTP-based attacks that followed.
No single source IP dominated the scan — the traffic originated from multiple addresses, consistent with a distributed scanning infrastructure or a network of compromised hosts used as scanning proxies.
External IP 54.70.53.60 attempted to download /back_up.zip from the server root using a spoofed browser user agent (Chrome 143 — a version that did not exist at the time of the capture). The server returned HTTP 404 — the file was not present. The attack failed.
This technique — requesting predictably-named backup files from web server roots — succeeds against servers where administrators leave compressed backups publicly accessible during maintenance. The file's absence protected this server. The more robust fix is a firewall rule blocking direct access to non-web files regardless of their presence.
External IP 163.123.236.83 attempted to upload a file to /upload.exe using the EICAR antivirus test string as payload — a technique used to test whether a web server will accept and store executable content before deploying a real payload. The server returned HTTP 400 Bad Request, rejecting the malformed request. The spoofed Host header pointing to www.baidu.com caused the rejection.
This was a probe, not a full attack — the EICAR payload confirmed the attacker was testing the upload mechanism rather than deploying a real web shell. Had the upload succeeded, the attacker would have had a persistent remote access backdoor on the server.
Every HTTP response sent by the server — including 200 OK, 404 Not Found, and 400 Bad Request error pages — contained the exact software version and operating system: Apache/2.4.58 (Ubuntu). This information was delivered to every scanner, bot, and attacker that made any HTTP request during the 7-day window.
With the exact version known, an attacker can query the CVE database for vulnerabilities specific to Apache 2.4.58 and attempt targeted exploits. The fix requires one line in apache2.conf: ServerTokens Prod. This reduces all server headers to just Server: Apache — confirming the software type without revealing the version.
The server operated exclusively on HTTP port 80. Port 443 probes from external scanners received TCP error responses — nothing was listening. Every request sent to the server and every response returned was fully readable in Wireshark without any decryption step.
For a web server handling any user data, credentials, or sensitive content, unencrypted HTTP is a critical misconfiguration. In this analysis, the plaintext channel was an advantage for the defender — the EICAR payload, the backup file request, and all attack traffic was fully visible. In a real investigation involving legitimate user traffic, the same unencrypted channel would expose user credentials and session data to any network observer.
Frame 79353 showed a TCP RST,ACK from the server to 172.234.207.202 on port 3053 — flagged initially as a potential data relay. The RST,ACK flag combination means the server refused the connection, not initiated data transfer. An inbound probe hit port 3053, found nothing listening, and the server reset the connection. This is normal server behavior and not an indicator of compromise.
Wireshark Filter Reference — Internet-Facing Server Triage
The filters below form a repeatable workflow for analyzing traffic hitting a public web server. They differ from the Lab 003 workflow — there is no DHCP or Kerberos to pivot from. Instead the methodology starts with scale (how much traffic?), then structure (what kinds?), then specifics (what did attackers actually do?).
NIST SP 800-171 Control Mapping
Lessons Learned
Any Public Server Is Under Constant Attack — This Is Normal
Seven days of scans, probes, spoofed browser headers, and executable upload attempts is not unusual — it is the baseline reality for any IP address exposed to the public internet. Automated scanners run continuously, probing every reachable IP for open ports and known vulnerabilities. A SOC analyst seeing this volume of inbound SYN packets on a public server should not immediately escalate to incident response — the first job is to distinguish the background noise from genuine targeted activity.
Follow the Response, Not Just the Request
The most important frames in this entire analysis were the responses — not the attacks. The 404 on /back_up.zip and the 400 on /upload.exe changed the severity of those findings from Critical to High. A request alone tells you what was attempted. The response tells you what actually happened. Always follow the TCP stream.
RST,ACK Means Refused — Not Exfiltrated
The connection from the server to 172.234.207.202 looked alarming at first — an outbound connection to an unknown external IP. The RST,ACK flags resolved it immediately: the server slammed the door shut. Understanding TCP flag combinations is the difference between a false positive escalation and a correctly dismissed finding.
The Biggest Risk Was Passive, Not Active
None of the four attack vectors succeeded. But the server was broadcasting its exact software version to every requestor for the entire seven-day window. The passive information disclosure finding — Apache/2.4.58 (Ubuntu) in every response — required no attack to exploit. It just required an attacker to read the response. The most impactful remediation was not blocking a specific attack but changing one configuration line that reduced the server's intelligence value to every future scanner.
The SOC Rules This Analysis Produces
Rule 1 — SYN scan alert: Any source IP sending more than 100 TCP SYN packets to a single destination within 60 seconds, with fewer than 10% completing the handshake, constitutes a port scan. Log the source IP and rate-limit further connections.
Rule 2 — Executable upload alert: Any HTTP POST request with a URI containing .exe, .dll, .ps1, .bat, or .msi should generate an immediate alert regardless of the server's response. Probe today, real payload tomorrow.
Rule 3 — Spoofed user agent flag: Any HTTP request with a User-Agent containing a browser version number that does not match any released version at the time of the request should be tagged as a likely automated tool or scanner.
Next Lab
Lab Log 009 will build on this analysis by introducing command-line tools for network analysis — moving from Wireshark's GUI to terminal-based workflows using tshark, the command-line version of Wireshark, to automate the triage process demonstrated here.