A web application at 10.0.10.20 receives a request from analyst laptop 10.0.10.50, while a later burst of traffic from 10.0.30.66 reaches toward both internal subnets. The attacker does not need to log in to create evidence. Each packet records where traffic came from, where it was headed, and which protocol carried it. The defender’s question is how one captured session can reveal both expected web traffic and suspicious probing without treating the capture as an unreadable stream of bytes.
Our fixed lab contains the analyst laptop and web application on 10.0.10.0/24, a DNS resolver at 10.0.10.53, and a database at 10.0.20.10. A firewall and router connects those networks through 10.0.10.1 and 10.0.20.1; the attacker VM sits separately at 10.0.30.66. The capture begins with DNS and web traffic, then includes the attacker VM contacting addresses across the two internal networks. We will return to these exact addresses throughout the course, so a later filter or alert always has a known baseline.
The diagram fixes the devices, addresses, and captured traffic in one place:
This diagram shows why the later scan matters. A client request to the web application has an expected purpose, while repeated connections from 10.0.30.66 to many destinations may indicate reconnaissance. If prevention fails and the firewall permits unwanted traffic, the packet capture remains a detection source because it records the source address, destination address, protocol, and timing. Network Service Discovery is ATT&CK technique T1046 in ATT&CK v20, October 2026, and defenders can detect its network pattern through firewall logs, flow records, or packet captures.
The captured request becomes understandable when we view it through encapsulation, the process of placing one protocol’s data inside another protocol’s header. For example, the browser’s GET /login request needs more than its text. The network must also carry a destination port, destination IP address, and local network destination.
The OSI model and TCP/IP model organize that same work differently. OSI describes seven layers, while TCP/IP commonly groups the packet into application, transport, internet, and link layers. Neither model is a separate network. Both describe the Ethernet frame that Wireshark recorded.
For one request from 10.0.10.50 to 10.0.10.20, which information identifies the local delivery, the host delivery, the receiving service, and the requested page? The packet stack below keeps those boundaries visible:
This stack shows the answer from outside inward. Ethernet uses MAC addresses to deliver the frame across the local link. IPv4 carries 10.0.10.50 and 10.0.10.20 so routers can forward the packet between networks. TCP uses port 51514 and port 80 to identify the conversation endpoints, and HTTP carries GET /login as application data. A packet analyst can therefore ask a different question at each layer instead of searching every field at once.
Header order Read packet fields from link delivery through host delivery and service delivery before interpreting the application request.
Because the frame contains several layers at once, Wireshark’s packet details pane expands them as separate protocol entries. Ethernet II exposes Layer 2 MAC fields, Internet Protocol Version 4 exposes Layer 3 addresses, and Transmission Control Protocol exposes Layer 4 ports and control flags. An Hypertext Transfer Protocol entry appears only when Wireshark can identify visible HTTP data.
Not every frame contains an HTTP request. Before the first GET /login, TCP establishes the connection with a SYN from 10.0.10.50 and a SYN/ACK reply from 10.0.10.20. Those packets still identify the two hosts and ports, but they carry no page request. The reference output below extracts fields from the same flow without claiming to execute against any system: