Free Offensive Security Networking and Protocol Fundamentals Practice Test 2026

Master Networking and Protocol Fundamentals with free offensive security practice questions covering TCP/IP, the OSI model, common ports and services, DNS, DHCP, and packet analysis fundamentals every penetration tester needs. Each question includes a detailed explanation — no signup required. This domain accounts for 6% of the mock exam and maps to skills tested across eJPT, OSCP, PNPT, OSWE, and OSEP.

Key Networking and Protocol Fundamentals Topics

Free Networking and Protocol Fundamentals Sample Questions with Answers

Each question below includes 4 answer options, the correct answer, and a detailed explanation from the FlashGenius Offensive Security question bank.

Sample Question 1 — Networking & Protocol Fundamentals

You are performing an internal penetration test and have gained access to a Linux jump host on the 10.10.20.0/24 network. You suspect there is a misconfigured legacy application server that still accepts cleartext credentials. You capture traffic with tcpdump using: tcpdump -i eth0 -nn -s0 -A 'tcp port 21 or tcp port 23 or tcp port 80' After a few minutes, you see the following packets (sanitized): 12:01:14.123456 IP 10.10.20.45.49832 > 10.10.20.60.21: Flags [P.], seq 1:23, ack 1, win 229, length 22 E..@..@.@...........5...P..P....USER alice 12:01:14.223456 IP 10.10.20.45.49832 > 10.10.20.60.21: Flags [P.], seq 23:47, ack 1, win 229, length 24 E..@..@.@...........5...P..P....PASS Spring2025! 12:01:15.123456 IP 10.10.20.45.49834 > 10.10.20.60.80: Flags [P.], seq 1:120, ack 1, win 229, length 119 E..@..@.@...........5...P..P....POST /login HTTP/1.1 Host: legacy-app.local Content-Type: application/x-www-form-urlencoded Content-Length: 27 username=bob&password=test Which statement best explains the networking/protocol misconfiguration you should highlight in your report and how it impacts your attack strategy?

  1. A. The FTP service on 10.10.20.60 is using active mode instead of passive mode, which allows you to sniff credentials; you should recommend switching to passive FTP to fix this.
  2. B. The FTP service on 10.10.20.60 is running over cleartext TCP (port 21) without TLS, exposing credentials in transit; you can directly reuse the sniffed USER/PASS pair to authenticate to the FTP server. (Correct answer)
  3. C. The HTTP POST request to /login indicates that the web application is vulnerable to SQL injection because credentials are sent in the body; you should immediately attempt SQLi on the username parameter.
  4. D. The Telnet service on 10.10.20.60 is leaking credentials because it runs on port 21; you should brute-force Telnet using the captured password to gain shell access.

Correct answer: B

Explanation: The tcpdump output shows cleartext application-layer protocols and highlights a classic but still common misconfiguration: lack of encryption on sensitive services. Why B is correct: - The traffic is going to destination port 21 on 10.10.20.60, which is the standard port for FTP (not Telnet, not SSH). - The payload clearly shows FTP commands: - `USER alice\r\n` - `PASS Spring2025!\r\n` - FTP (RFC 959) is a cleartext protocol when used as plain FTP over TCP/21. Without explicit FTPS (AUTH TLS) or implicit FTPS (TCP/990), credentials and data are transmitted unencrypted. - Because you are on the same broadcast domain (10.10.20.0/24) and can sniff traffic, you can immediately reuse these credentials: - Example: - `ftp 10.10.20.60` - `Name (10.10.20.60:attacker): alice` - `Password: Spring2025!` - From an offensive perspective, this is a straightforward attack path: network-level sniffing → credential capture → direct service authentication → potential file exfiltration or planting web shells if the FTP root maps to a web directory. - From a reporting perspective, the misconfiguration is: "FTP service exposed internally without encryption (no FTPS/SFTP), allowing credential interception via passive sniffing on the local segment." Why A is wrong: - Active vs passive FTP relates to how the data channel is established (server vs client initiated) and firewall traversal, not whether credentials are encrypted. - Both active and passive FTP send `USER` and `PASS` in cleartext unless wrapped in TLS. - Switching to passive mode alone does not fix credential exposure; encryption (FTPS/SFTP or SSH-based alternatives) is required. Why C is wrong: - The HTTP POST to `/login` over port 80 is indeed cleartext, but the question asks for the *best* explanation of the misconfiguration and its impact on your attack strategy. - While HTTP over port 80 without TLS is also a misconfiguration for sensitive logins, the FTP example is more clearly exploitable immediately with known-good credentials (`alice` / `Spring2025!`). - The presence of credentials in a POST body does *not* by itself indicate SQL injection; that’s an application-layer vulnerability requiring further testing (e.g., Burp Repeater/Intruder with payloads like `' OR 1=1-- -`). - The question is about networking & protocol fundamentals, not web app logic flaws. Why D is wrong: - Telnet typically runs on TCP/23, not 21. The tcpdump filter includes `tcp port 23`, but the shown packets are clearly to port 21 (FTP) and 80 (HTTP). - The payload shows FTP commands (`USER`, `PASS`), not Telnet negotiation sequences (IAC, DO, DONT, WILL, WONT). - You cannot assume a Telnet service is running on port 21; that would be a non-standard and unjustified assumption. Key networking/protocol takeaways: - Port numbers and payloads must be correlated: port 21 + `USER/PASS` → FTP; port 80 + HTTP headers → HTTP. - Cleartext protocols (FTP, Telnet, HTTP) on flat internal networks are still highly exploitable via passive sniffing. - Proper remediation is to enforce encrypted protocols (FTPS/SFTP/SSH/HTTPS) and segment or monitor sensitive traffic, not just change modes or ports.

Sample Question 2 — Networking & Protocol Fundamentals

During an external black-box assessment, you run an initial scan with Masscan and follow up with Nmap for service enumeration: masscan 203.0.113.50 -p0-65535 --rate 5000 -e tun0 --wait 5 # Output (sanitized): Discovered open port 22/tcp on 203.0.113.50 Discovered open port 80/tcp on 203.0.113.50 Discovered open port 443/tcp on 203.0.113.50 You then run: nmap -sS -sV -Pn -p22,80,443 203.0.113.50 Nmap output (sanitized): PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0) 80/tcp open http nginx 1.18.0 (Ubuntu) 443/tcp open ssl/http nginx 1.18.0 (Ubuntu) You capture a few packets with tcpdump while browsing https://203.0.113.50/: tcpdump -i tun0 -nn -s0 -X 'host 203.0.113.50 and port 443' 13:22:10.123456 IP 198.51.100.10.51524 > 203.0.113.50.443: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 123 ecr 0,nop,wscale 7], length 0 13:22:10.123789 IP 203.0.113.50.443 > 198.51.100.10.51524: Flags [S.], seq 987654321, ack 123456790, win 65160, options [mss 1460,sackOK,TS val 456 ecr 123,nop,wscale 7], length 0 13:22:10.124000 IP 198.51.100.10.51524 > 203.0.113.50.443: Flags [.], ack 1, win 502, options [TS val 124 ecr 456], length 0 13:22:10.125000 IP 198.51.100.10.51524 > 203.0.113.50.443: Flags [P.], seq 1:518, ack 1, win 502, length 517 0000 16 03 01 02 00 01 00 01 fc 03 03 ... (ClientHello) Which of the following next steps best leverages your understanding of networking and protocol behavior to move toward an actual exploit path against this host?

  1. A. Run `nmap -sS -O 203.0.113.50` to fingerprint the OS and immediately attempt a generic TCP/IP stack-based remote code execution exploit against the kernel.
  2. B. Use `nmap --script ssl-enum-ciphers,ssl-cert -p443 203.0.113.50` to enumerate TLS configuration and certificate details, then assess for weak ciphers, protocol downgrades, or misissued certificates that could enable MITM or session decryption. (Correct answer)
  3. C. Run `nmap -sU -p53,123,161 203.0.113.50` because the presence of HTTPS on port 443 implies that DNS, NTP, and SNMP must also be open and vulnerable on the same host.
  4. D. Use `nmap -sV --version-light -p22 203.0.113.50` to confirm the SSH version, then immediately brute-force SSH with `hydra` because OpenSSH 8.9p1 is known to be trivially exploitable via default credentials.

Correct answer: B

Explanation: The scenario shows you have identified standard services (SSH, HTTP, HTTPS) and observed a normal TCP three-way handshake followed by a TLS ClientHello on port 443. The question asks which next step best uses protocol understanding to move toward a realistic exploit path. Why B is correct: - The tcpdump output shows TLS negotiation on port 443 (`16 03 01` → TLS record, version 1.x; ClientHello). - Modern external assessments often pivot from basic port discovery to *TLS configuration analysis* because misconfigurations can lead to: - Weak cipher suites (e.g., export-grade, NULL, RC4) → potential cryptographic attacks. - Support for deprecated protocols (SSLv3, TLS 1.0/1.1) → downgrade attacks. - Misissued or self-signed certificates → easier MITM in some threat models. - The Nmap NSE scripts `ssl-enum-ciphers` and `ssl-cert` are specifically designed for this: - `nmap --script ssl-enum-ciphers,ssl-cert -p443 203.0.113.50` - `ssl-enum-ciphers` enumerates supported protocols (TLS1.0–1.3), key exchange, ciphers, MACs, and reports known weaknesses. - `ssl-cert` extracts certificate details (CN, SANs, validity, key length, issuer), which can reveal: - Internal hostnames for further recon. - Weak key sizes or outdated signature algorithms. - From an offensive perspective, this can lead to: - Targeted downgrade attempts. - Exploiting legacy endpoints or virtual hosts discovered via certificate SANs. - Better positioning for credential interception or session hijacking in certain environments. - This step directly leverages protocol-level understanding (TCP handshake, TLS negotiation, cipher suites) and is realistic for 2024–2025 pentests. Why A is wrong: - `nmap -sS -O` (SYN scan + OS detection) is useful, but: - OS detection alone rarely yields an immediate, generic "TCP/IP stack RCE" in modern kernels. - Modern Linux/Ubuntu kernels behind a public-facing nginx are unlikely to have a trivial remote kernel exploit exposed directly on 22/80/443. - This option implies an unrealistic expectation: that OS fingerprinting directly leads to a generic TCP/IP stack RCE, which is not how modern external pentests typically progress. Why C is wrong: - There is no protocol-level implication that having HTTPS (443/tcp) means DNS (53/udp), NTP (123/udp), or SNMP (161/udp) must be open on the same host. - While scanning common UDP services can be useful, the reasoning given is flawed: service presence on one port does not logically require others. - Also, the question is about leveraging the *observed* protocol behavior (TCP handshake + TLS ClientHello), which this option ignores. Why D is wrong: - `nmap -sV --version-light -p22` is redundant: you already have the SSH version from the previous `-sV` scan (`OpenSSH 8.9p1 Ubuntu 3ubuntu0.3`). - OpenSSH 8.9p1 is a modern version; there is no widely known trivial RCE or default-credential issue inherent to that version. - Brute-forcing SSH is sometimes part of an engagement, but: - It is noisy and often against rules of engagement unless explicitly allowed. - It does not leverage any *protocol misconfiguration* or subtle behavior; it’s just credential guessing. - The claim that OpenSSH 8.9p1 is "known to be trivially exploitable via default credentials" is false; SSH does not ship with default logins by design. Key networking/protocol takeaways: - After identifying HTTPS, a protocol-aware next step is to analyze TLS configuration, not to assume unrelated services. - Nmap NSE scripts like `ssl-enum-ciphers` and `ssl-cert` are core tools for protocol-level recon on 443/tcp. - Understanding the TCP handshake and TLS ClientHello helps you interpret captures and choose meaningful follow-up enumeration rather than random or unrealistic exploit attempts.

Sample Question 3 — Networking & Protocol Fundamentals

You’re on an internal black-box engagement and have a foothold on a Linux host (10.10.10.5). You suspect that an internal web application is only accessible from this host’s network segment. You run the following commands: 1) On your Kali box: ip a | grep tun0 -> 10.8.0.12/24 (VPN interface) 2) From Kali to the compromised host: ssh -N -D 1080 attacker@10.10.10.5 3) On Kali, you configure Firefox to use SOCKS5 proxy 127.0.0.1:1080 and enable "Proxy DNS when using SOCKS v5". 4) From the compromised host, you run: netstat -tulnp | grep LISTEN -> tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN 1234/python3 You browse to http://127.0.0.1:8080 in Firefox but get no response. From the perspective of networking and protocol fundamentals, what is the MOST accurate explanation for why you cannot reach the internal web app?

  1. A. SOCKS5 proxies only support TCP over port 1080; they cannot forward HTTP traffic to other TCP ports like 8080.
  2. B. The SOCKS5 dynamic port forward is created on Kali, but the internal web server is bound to 127.0.0.1 on the remote host, which is not directly reachable via a SOCKS proxy without using the remote host’s loopback address as the target. (Correct answer)
  3. C. The SSH -D option only forwards traffic for remote hosts, not for services bound to 127.0.0.1 on the remote host; you must use -L for loopback-bound services.
  4. D. DNS resolution is failing over the SOCKS5 tunnel, so the browser cannot resolve 127.0.0.1 to the internal host’s loopback interface.

Correct answer: B

Explanation: The key is understanding how SOCKS5 dynamic port forwarding works and what 127.0.0.1 means in different contexts. You created a dynamic SOCKS proxy with: ssh -N -D 1080 attacker@10.10.10.5 This means: - Your browser connects to 127.0.0.1:1080 on Kali. - The SSH client speaks SOCKS5 and asks the SSH server (on 10.10.10.5) to connect to whatever host:port you request in the browser. - The destination host:port is interpreted from the perspective of the remote side (10.10.10.5), not Kali. The service is listening on the remote host as: 127.0.0.1:8080 (LISTEN on 10.10.10.5) For a SOCKS proxy, if you browse to http://127.0.0.1:8080, the SOCKS client tells the remote side to connect to 127.0.0.1:8080 from the remote side’s perspective. That is exactly what you want: the remote host’s loopback. So the *concept* is correct. However, the question states you get no response, and asks for the most accurate explanation from a networking fundamentals perspective. The subtle but critical point is that many browsers, when configured with a SOCKS proxy, will still treat 127.0.0.1 as a local bypass address (no proxy) unless explicitly configured otherwise. In that case, the browser connects directly to 127.0.0.1:8080 on Kali, where nothing is listening, instead of sending the request through the SOCKS proxy. Among the options, B is the closest to the correct reasoning: the internal web server is bound to 127.0.0.1 on the remote host, and you must ensure that the browser actually uses the SOCKS proxy to reach the remote host’s loopback. Practically, you would: - Ensure the browser does not bypass proxy for localhost/127.0.0.1, or - Use the remote host’s actual IP (e.g., http://10.10.10.5:8080) so the browser clearly sends the request via SOCKS. Why the other options are wrong: A) "SOCKS5 proxies only support TCP over port 1080; they cannot forward HTTP traffic to other TCP ports like 8080." - Incorrect. SOCKS5 is protocol-agnostic at layer 7; it forwards arbitrary TCP streams to any destination port (80, 8080, 443, 3389, etc.). Port 1080 is just the local listening port for the proxy on Kali. C) "The SSH -D option only forwards traffic for remote hosts, not for services bound to 127.0.0.1 on the remote host; you must use -L for loopback-bound services." - Incorrect. SOCKS5 via -D can absolutely connect to 127.0.0.1 on the remote host. The destination address is evaluated on the remote side. -L (local port forward) is another way to reach 127.0.0.1:8080 (e.g., ssh -L 8080:127.0.0.1:8080), but -D is not limited to non-loopback addresses. D) "DNS resolution is failing over the SOCKS5 tunnel, so the browser cannot resolve 127.0.0.1 to the internal host’s loopback interface." - Incorrect. 127.0.0.1 is not resolved via DNS; it is a hard-coded loopback address. DNS settings (including "Proxy DNS when using SOCKS v5") do not affect 127.0.0.1. Relevant technique: - Dynamic SOCKS tunneling for pivoting: ssh -N -D 1080 user@pivot_host - Ensure browser actually uses the proxy for the target address, or use the remote IP instead of 127.0.0.1.

Sample Question 4 — Networking & Protocol Fundamentals

During an internal assessment, you capture traffic on a flat /24 network using tcpdump: tcpdump -ni eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0 and port 445' You observe the following pattern between 10.0.5.23 and 10.0.5.40: 1) 10.0.5.23 → 10.0.5.40:445 [SYN] 2) 10.0.5.40 → 10.0.5.23:445 [SYN, ACK] 3) 10.0.5.23 → 10.0.5.40:445 [ACK] 4) 10.0.5.23 → 10.0.5.40:445 [PSH, ACK] (SMB negotiation) 5) 10.0.5.40 → 10.0.5.23:445 [RST] You then run an nmap scan from your attack box (10.0.5.50): nmap -sS -p445 10.0.5.40 PORT STATE SERVICE 445/tcp closed microsoft-ds From a networking and protocol behavior standpoint, what is the MOST likely explanation for why you see a successful TCP three-way handshake between 10.0.5.23 and 10.0.5.40, but nmap reports port 445 as closed from your host?

  1. A. Port 445 is in a TCP half-open state and only accepts connections from the first client that initiated the handshake, causing subsequent SYNs from other hosts to be rejected.
  2. B. A host-based firewall on 10.0.5.40 allows SMB connections only from specific IP ranges (including 10.0.5.23) and sends RSTs or drops SYNs from unauthorized IPs like 10.0.5.50. (Correct answer)
  3. C. Nmap’s -sS SYN scan cannot detect ports that complete a full three-way handshake; you must use -sT to see the port as open.
  4. D. The SMB service on 10.0.5.40 is using TCP Fast Open, which nmap’s SYN scan misinterprets as a closed port when the connection is not initiated from a domain-joined host.

Correct answer: B

Explanation: The captured traffic shows: - 10.0.5.23 can complete a full TCP three-way handshake with 10.0.5.40 on port 445. - After SMB negotiation starts, 10.0.5.40 sends an RST, likely due to application-level or firewall policy. - When you scan from 10.0.5.50, nmap reports port 445 as closed. This strongly suggests a host-based firewall or access control list (ACL) on 10.0.5.40 that: - Allows SMB (port 445) from certain IPs (e.g., 10.0.5.23, maybe domain controllers or management hosts). - Denies or actively resets connections from other IPs (like your attack box 10.0.5.50). From a networking fundamentals perspective: - A port can be "open" for some sources and "closed" or "filtered" for others, depending on firewall rules. - Nmap’s result reflects the behavior *toward your source IP*, not a global truth about the port. Why B is correct: - It directly matches the observed behavior: selective acceptance of connections based on source IP. - This is common in hardened Windows environments where Windows Firewall or endpoint security restricts SMB to specific subnets or hosts. Why the other options are wrong: A) "Port 445 is in a TCP half-open state and only accepts connections from the first client that initiated the handshake..." - TCP does not work this way. Ports are not "reserved" for a single client. The kernel maintains separate connection tuples (src IP, src port, dst IP, dst port). Multiple clients can connect simultaneously. - The three-way handshake from 10.0.5.23 completes, so the port is not half-open. C) "Nmap’s -sS SYN scan cannot detect ports that complete a full three-way handshake; you must use -sT to see the port as open." - Incorrect. -sS (SYN scan) is specifically designed to detect open ports by sending a SYN and interpreting the SYN/ACK response. It does *not* need to complete the handshake. If 10.0.5.40 sent a SYN/ACK to 10.0.5.50, nmap would mark the port as open. - The fact that nmap reports it as closed means 10.0.5.40 likely sends RST or no response to SYNs from 10.0.5.50. D) "The SMB service on 10.0.5.40 is using TCP Fast Open..." - TCP Fast Open does not cause nmap to misinterpret ports as closed based on domain membership. Nmap’s SYN scan logic is based on TCP flags (SYN/ACK vs RST), not on application-layer authentication or domain status. - There is no evidence of TCP Fast Open in the provided trace. Relevant offensive technique: - When you see a service reachable from one host but not from your attack box, consider pivoting through the allowed host: # From your box, pivot through 10.0.5.23 to reach 10.0.5.40:445 ssh -L 4450:10.0.5.40:445 user@10.0.5.23 nmap -sS -p445 127.0.0.1 -Pn - This leverages the allowed source IP to bypass host-based firewall restrictions.

Sample Question 5 — Networking & Protocol Fundamentals

You’re analyzing a packet capture from an external black-box test. You see repeated connection attempts from your own attack box (203.0.113.10) to a target (198.51.100.20) on TCP/22. The relevant packets are: 1) 203.0.113.10 → 198.51.100.20:22 [SYN] 2) 198.51.100.20 → 203.0.113.10:22 [ICMP type 3, code 13: Communication administratively prohibited] Your nmap command and output were: nmap -sS -p22 198.51.100.20 PORT STATE SERVICE 22/tcp filtered ssh From a networking and protocol fundamentals perspective, what is the MOST accurate interpretation of this behavior, and how should it influence your next step as an attacker?

  1. A. The host is down, and the ICMP message is generated by an upstream router; you should switch to a UDP scan (-sU) to confirm host liveness.
  2. B. A stateful firewall is explicitly blocking TCP/22 and returning ICMP type 3 code 13, indicating filtering; you should try scanning for alternative management ports (e.g., 2222, 22222) or fallback services like HTTPS for potential VPN or admin panels. (Correct answer)
  3. C. The target is using TCP wrappers (hosts.deny) to block your IP, which always results in ICMP type 3 code 13; you should spoof your source IP to bypass the restriction.
  4. D. SSH is rate-limiting new connections and temporarily rejecting them with ICMP type 3 code 13; you should slow down your scan using --scan-delay to avoid triggering the limit.

Correct answer: B

Explanation: The key is understanding ICMP type 3 (Destination Unreachable) with code 13 (Communication administratively prohibited). ICMP type 3, code 13 means: - A device (often a firewall or router) is actively telling you that communication is blocked by an administrative policy. - This is different from host-down scenarios (no response) or simple RSTs (closed port). Nmap interprets this as "filtered" because: - It cannot determine whether the port is open or closed; it only knows that something in the path is blocking the traffic. Why B is correct: - It correctly identifies that a stateful firewall or similar device is explicitly blocking TCP/22. - It suggests a realistic next step: look for alternative management or access paths, such as: - Non-standard SSH ports (2222, 22222, 8022, etc.). - HTTPS services that might expose VPN portals, admin panels, or jump hosts. - This aligns with offensive methodology: when a direct management port is filtered, pivot to discovering other exposed services that might grant access. Example follow-up commands: # Scan for common alternative SSH ports nmap -sS -p22,2222,22222,8022 198.51.100.20 # Broader top-ports scan to find HTTPS/VPN/admin panels nmap -sS --top-ports 1000 -sV 198.51.100.20 Why the other options are wrong: A) "The host is down... you should switch to a UDP scan (-sU)." - If the host were down, you would typically see no response at all, not an ICMP "administratively prohibited" message. - The ICMP response proves that some device on the path is up and enforcing a policy. - Switching to UDP does not "confirm liveness" in this context; ICMP already did. C) "The target is using TCP wrappers (hosts.deny)... you should spoof your source IP." - TCP wrappers (hosts.allow/hosts.deny) operate at the application layer on the host and typically result in TCP-level behavior (e.g., immediate close), not ICMP type 3 code 13 from a firewall. - IP spoofing is not practical for TCP-based attacks that require a full handshake and bidirectional communication; responses would go to the spoofed IP, not you. D) "SSH is rate-limiting new connections and temporarily rejecting them with ICMP type 3 code 13." - SSH daemons do not send ICMP type 3 code 13; that is a network-layer device (firewall/router) behavior. - Rate limiting usually manifests as delayed SYN/ACKs, dropped packets, or application-level banners, not ICMP administrative prohibitions. - --scan-delay is useful to avoid IDS/IPS or rate limits, but it does not bypass a hard firewall rule. Relevant technique: - Interpreting ICMP unreachable codes to distinguish between: - Host down (no response) - Port closed (RST) - Administratively filtered (ICMP type 3 code 13) - Adapting recon strategy when key ports (SSH/3389/VPN) are filtered by looking for alternate ingress points.

Sample Question 6 — Networking & Protocol Fundamentals

You are on an internal network assessment and capture the following packet using tcpdump while investigating intermittent connectivity issues to a web application: ```bash $ tcpdump -n -vvv -i eth0 'tcp port 80 and host 10.10.20.15' -c 6 13:10:01.123456 IP (tos 0x0, ttl 64, id 54321, offset 0, flags [DF], proto TCP (6)) 10.10.5.23.49832 > 10.10.20.15.80: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 123456 ecr 0], length 0 13:10:01.123789 IP (tos 0x0, ttl 61, id 1122, offset 0, flags [DF], proto TCP (6)) 10.10.20.15.80 > 10.10.5.23.49832: Flags [S.], seq 987654321, ack 123456790, win 65160, options [mss 1460,sackOK,TS val 654321 ecr 123456], length 0 13:10:01.124001 IP (tos 0x0, ttl 64, id 54322, offset 0, flags [DF], proto TCP (6)) 10.10.5.23.49832 > 10.10.20.15.80: Flags [.], ack 987654322, win 64240, options [TS val 123457 ecr 654321], length 0 13:10:01.124500 IP (tos 0x0, ttl 64, id 54323, offset 0, flags [DF], proto TCP (6)) 10.10.5.23.49832 > 10.10.20.15.80: Flags [P.], seq 123456790:123457190, ack 987654322, win 64240, length 400: HTTP: GET / HTTP/1.1 13:10:06.124900 IP (tos 0x0, ttl 61, id 1123, offset 0, flags [DF], proto TCP (6)) 10.10.20.15.80 > 10.10.5.23.49832: Flags [R], seq 987654322, win 0, length 0 13:10:06.125100 IP (tos 0x0, ttl 64, id 54324, offset 0, flags [DF], proto TCP (6)) 10.10.5.23.49832 > 10.10.20.15.80: Flags [F.], seq 123457190, ack 987654322, win 64240, length 0 ``` From a networking and protocol perspective, which issue is the MOST likely root cause impacting your ability to exploit this web application reliably?

  1. A. An application-layer HTTP timeout is closing idle connections before the response is sent
  2. B. A stateful firewall or load balancer is dropping idle TCP sessions due to an aggressive TCP idle timeout (Correct answer)
  3. C. TCP window scaling is misconfigured, causing the server to send a TCP RST instead of ACKs
  4. D. Path MTU discovery is failing, causing fragmentation and resulting in TCP resets

Correct answer: B

Explanation: The capture shows a clean TCP three-way handshake (S, S., ACK), followed by a PSH/ACK with an HTTP GET. Then there is a ~5 second gap before the server sends a TCP RST (reset) with no HTTP response. The client then attempts to close with FIN/ACK after the RST. Why B is correct: - The server responds to the SYN with SYN/ACK and acknowledges the client's ACK, so the TCP handshake is valid. - The client sends application data (HTTP GET) with PSH/ACK, but we never see an HTTP response. - After 5 seconds of apparent inactivity, the server sends a bare RST, which is typical when an intermediate device (stateful firewall, load balancer, or reverse proxy) decides the session is invalid or has timed out at the TCP state level. - Many enterprise load balancers/firewalls have aggressive TCP idle timeouts (e.g., 5 seconds for certain paths or misconfigured health checks), which can kill connections mid-request. This leads to intermittent failures and unreliable exploitation (e.g., large payloads, long-running RCE, or slow SQLi queries). - From an offensive perspective, this explains why long-running requests (e.g., time-based SQLi, blind RCE, or large file uploads) might fail or be inconsistent. Why the others are wrong: - A: Application-layer HTTP timeout would typically result in an HTTP error response (e.g., 408 Request Timeout, 504 Gateway Timeout) rather than a raw TCP RST at the transport layer. Here we see no HTTP response at all, just a TCP reset. - C: TCP window scaling issues usually manifest as stalled connections, repeated retransmissions, or zero-window probes, not an immediate RST after a short idle period. The windows look normal and there are no retransmissions shown. - D: Path MTU discovery problems cause fragmentation issues, ICMP "fragmentation needed" messages, or repeated retransmissions of large segments. The packets here are small (400 bytes of HTTP data) and there is no evidence of fragmentation or ICMP. A clean RST after a fixed idle period strongly suggests a stateful device timeout, not MTU issues. Relevant technique: - As a pentester, correlating TCP-level behavior with exploitation reliability is critical. If you suspect aggressive TCP timeouts, you might: - Use shorter, chunked requests or keep-alive probes. - Tunnel traffic (e.g., SSH/Chisel/Ligolo) to bypass the problematic middlebox. - Adjust tools like sqlmap or Burp to use shorter time-based delays or parallel requests. Domain: Networking & Protocol Fundamentals

Offensive Security Prep Pack Overview

Other Offensive Security Domains

Start the free offensive security Networking and Protocol Fundamentals practice test now | 10-question quick start | All offensive security domains | All Sample Tests