Free Offensive Security Enumeration and Reconnaissance Practice Test 2026

Master Enumeration and Reconnaissance with free offensive security practice questions covering active and passive reconnaissance, Nmap scanning, service enumeration, OSINT, and mapping the attack surface. Each question includes a detailed explanation — no signup required. This domain accounts for 18% of the mock exam and maps to skills tested across eJPT, OSCP, PNPT, OSWE, and OSEP.

Key Enumeration and Reconnaissance Topics

Free Enumeration and Reconnaissance 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 — Enumeration & Reconnaissance

You are performing an internal network penetration test from a Linux attack box on the 10.10.20.0/24 subnet. The client has explicitly warned that legacy industrial control systems on this VLAN are extremely fragile and must not be impacted by aggressive scanning. You want to identify live hosts and their top services with minimal risk, while also fingerprinting OS and versions where possible. Which of the following Nmap approaches is the MOST appropriate starting point in this situation?

  1. A. Run a fast TCP connect scan with OS detection and default scripts against the entire subnet: nmap -sT -O -sC -T4 10.10.20.0/24
  2. B. Run a ping sweep followed by a targeted SYN scan with version detection and conservative timing: nmap -sn 10.10.20.0/24 nmap -sS -sV --version-intensity 3 -T2 -Pn -F -oA safe_scan 10.10.20.0/24 (Correct answer)
  3. C. Use Masscan to quickly identify all open ports, then feed the results to Nmap for service detection: masscan 10.10.20.0/24 -p1-65535 --rate 100000 -oX masscan.xml nmap -sV -iL <(awk -F '"' '/port/{print $8}' masscan.xml)
  4. D. Skip host discovery and run a full TCP SYN scan with OS detection and all ports on the subnet: nmap -sS -O -p- -T3 -Pn 10.10.20.0/24

Correct answer: B

Explanation: The key constraints are: (1) internal /24 network, (2) fragile ICS systems, (3) need to identify live hosts and top services, (4) minimize risk and noise. Why B is correct: - The workflow in B is cautious and methodical: 1) `nmap -sn 10.10.20.0/24` - `-sn` (ping scan only) discovers live hosts without port scanning. - This is relatively low impact: ICMP echo, ARP, and possibly a few light probes depending on privileges. 2) `nmap -sS -sV --version-intensity 3 -T2 -Pn -F -oA safe_scan 10.10.20.0/24` - `-sS`: SYN scan is less intrusive than full TCP connect (`-sT`) because it doesn’t complete the handshake. - `-sV`: service version detection, but with `--version-intensity 3` (default is 7) to reduce the number of probes and aggressiveness. - `-T2`: conservative timing, fewer parallel probes, more spacing between packets — important for fragile systems. - `-Pn`: skip host discovery for the second phase because you already know which hosts are up; Nmap will treat all targets as online, avoiding extra discovery probes. - `-F`: scan only the top 100 most common ports, which is usually enough to identify major services (HTTP, SMB, RDP, SSH, etc.) while reducing traffic. - `-oA safe_scan`: saves results in all formats for later analysis. - This combination balances information gathering with safety and is consistent with real-world methodology when ICS/fragile systems are involved. Why the others are wrong: A: `nmap -sT -O -sC -T4 10.10.20.0/24` - `-sT`: TCP connect scan completes the full three-way handshake for each port, which is more intrusive and heavier on fragile systems than a SYN scan. - `-O`: OS detection sends multiple crafted probes; on sensitive ICS networks, OS detection can be risky and is often disabled or used only on selected hosts after coordination. - `-sC`: runs the default script set, which includes scripts that can be quite chatty or even state-changing in some edge cases. - `-T4`: aggressive timing, more parallelism and less delay between packets — exactly what you want to avoid on fragile networks. - No separation between discovery and targeted scanning; it hits everything at once. C: Masscan with high rate then Nmap - `masscan 10.10.20.0/24 -p1-65535 --rate 100000` is extremely aggressive. Masscan at 100k packets/second can easily overwhelm fragile devices or network gear. - Full port range (`-p1-65535`) is unnecessary for an initial safe recon; it generates a huge amount of traffic. - Even though feeding Masscan results into Nmap is a valid technique in many tests, the rate and scope here directly conflict with the requirement to avoid impacting ICS. D: `nmap -sS -O -p- -T3 -Pn 10.10.20.0/24` - `-p-`: scans all 65,535 TCP ports on every host — very heavy for a first pass, especially on a sensitive VLAN. - `-O`: OS detection again adds extra probes that may be risky. - `-Pn`: skips host discovery and assumes all 256 IPs are up, causing unnecessary scanning of non-existent hosts and more traffic overall. - While `-sS` and `-T3` are more moderate than some options, this is still far from a "minimal risk" approach. In a real exam or engagement, the approach in B demonstrates awareness of: - Separating host discovery from port scanning. - Using conservative timing and reduced version intensity. - Limiting port scope initially. - Respecting client constraints about fragile systems. Domain: Enumeration & Reconnaissance

Sample Question 2 — Enumeration & Reconnaissance

During an external black-box web application assessment, you discover a login portal at https://app.example.com. A quick Nmap scan shows only ports 80 and 443 open. You want to perform deeper reconnaissance to identify hidden directories, virtual hosts, and potential dev/staging endpoints without causing obvious disruption or triggering basic WAF rules. You have the following constraints: - You must respect robots.txt disallow rules. - You want to avoid noisy, obviously malicious wordlists (e.g., "raft-large-directories.txt" with exploit names). - You suspect there may be additional vhosts like dev.example.com or api.example.com not visible in DNS. Which of the following combined workflows BEST aligns with these goals?

  1. A. Use Gobuster for aggressive directory brute-forcing and then run a full Nikto scan: gobuster dir -u https://app.example.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 80 -x php,asp,aspx,js,txt -k nikto -h https://app.example.com
  2. B. Use ffuf for both vhost and directory enumeration with a common, non-malicious wordlist, honoring robots.txt and using a baseline response for filtering: # 1) Virtual host fuzzing ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt:FUZZ \ -u https://app.example.com/ \ -H "Host: FUZZ.example.com" \ -fs 0 -mc 200,301,302 -t 20 # 2) Directory enumeration (respecting robots.txt) ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt:FUZZ \ -u https://app.example.com/FUZZ \ -fc 404 -mc 200,301,302 -t 20 (Correct answer)
  3. C. Use masscan to identify any hidden ports, then run wfuzz with a large payload list ignoring HTTP status codes: masscan app.example.com -p1-65535 --rate 50000 wfuzz -c -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-big.txt --hc 0 https://app.example.com/FUZZ
  4. D. Use Nmap NSE scripts http-enum and http-vhosts only, with aggressive timing: nmap -p80,443 --script http-enum,http-vhosts -T5 app.example.com

Correct answer: B

Explanation: The scenario focuses on web-focused enumeration and recon with constraints: - Respect robots.txt disallow rules. - Avoid obviously malicious/noisy wordlists. - Enumerate both hidden directories and virtual hosts. - Avoid triggering basic WAF rules and being too noisy. Why B is correct: 1) Virtual host enumeration with ffuf: ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt:FUZZ \ -u https://app.example.com/ \ -H "Host: FUZZ.example.com" \ -fs 0 -mc 200,301,302 -t 20 - `-H "Host: FUZZ.example.com"`: classic vhost fuzzing technique. The DNS A record for app.example.com is used, but the Host header is varied to discover name-based vhosts (e.g., dev.example.com, api.example.com) that resolve to the same IP but aren’t in public DNS. - `-w ...subdomains-top1million-5000.txt`: a relatively common, non-exploit-heavy wordlist focused on subdomains; not full of payloads or exploit strings. - `-mc 200,301,302`: match typical success/redirect codes to identify real vhosts. - `-fs 0`: filter by size (here, ignoring zero-length responses) to reduce noise; in practice, you’d calibrate this based on baseline responses. - `-t 20`: moderate concurrency, not excessively noisy. 2) Directory enumeration with ffuf: ffuf -w /usr/share/seclists/Discovery/Web-Content/common.txt:FUZZ \ -u https://app.example.com/FUZZ \ -fc 404 -mc 200,301,302 -t 20 - `common.txt`: a standard, relatively small and non-malicious wordlist for content discovery. It doesn’t contain obviously exploit-specific paths that might trigger WAFs. - `-fc 404`: filter out 404 responses. - `-mc 200,301,302`: focus on likely valid content or redirects. - `-t 20`: again, moderate concurrency. - Respecting robots.txt: while not explicitly shown in the command, a proper workflow would first manually review `https://app.example.com/robots.txt` and then ensure that disallowed paths are either removed from the wordlist or excluded via ffuf filters. The question is about the *approach* and tools; ffuf plus a curated wordlist is consistent with respecting robots.txt. This combined workflow: - Uses a modern, flexible tool (ffuf) suitable for both vhost and directory fuzzing. - Uses reasonable wordlists and filters to reduce noise. - Aligns with real-world OSCP/PNPT/OSWE-style recon. Why the others are wrong: A: Gobuster + Nikto - `gobuster dir ... directory-list-2.3-medium.txt -t 80 -x php,asp,aspx,js,txt -k` - `directory-list-2.3-medium.txt` is fairly large and can be noisy; not necessarily malicious, but heavier than needed initially. - `-t 80` is quite high concurrency for an external target and more likely to trigger rate-limiting or WAF. - No mention of respecting robots.txt; Gobuster doesn’t do this automatically. - `nikto -h https://app.example.com` - Nikto is very signature-based and noisy; it often triggers WAFs and is not subtle. - It sends many known exploit paths and outdated checks, conflicting with the requirement to avoid obviously malicious wordlists/requests. - Also, this option doesn’t address virtual host enumeration at all. C: Masscan + wfuzz - `masscan app.example.com -p1-65535 --rate 50000` - Very aggressive for an external web app; scanning all 65k ports at 50k packets/sec is noisy and unnecessary when Nmap already showed only 80/443. - Likely to trigger IDS/WAF or upstream provider alerts. - `wfuzz ... directory-list-2.3-big.txt --hc 0` - `directory-list-2.3-big.txt` is extremely large and noisy for an initial recon. - `--hc 0` (hide code 0) effectively doesn’t filter by HTTP status codes; this is the opposite of using a baseline and filtering, and will produce a lot of noise. - No explicit handling of robots.txt. - Again, no vhost enumeration here; only directories. D: Nmap NSE http-enum and http-vhosts with `-T5` - `nmap -p80,443 --script http-enum,http-vhosts -T5 app.example.com` - `http-enum` can be useful but is limited compared to dedicated fuzzers like ffuf/gobuster. - `http-vhosts` can sometimes discover vhosts, but it’s not as flexible as ffuf with a curated wordlist. - `-T5` is very aggressive timing; not ideal for a stealthy external assessment. - Nmap’s HTTP enumeration is not as controllable in terms of respecting robots.txt or avoiding certain paths. - This approach is too coarse and not as effective for deep directory/vhost recon as ffuf with tuned wordlists and filters. In a real exam or engagement, B demonstrates: - Understanding of Host header-based vhost enumeration. - Use of modern fuzzing tools (ffuf) with tuned filters and wordlists. - Awareness of noise/WAF considerations and robots.txt constraints. Domain: Enumeration & Reconnaissance

Sample Question 3 — Enumeration & Reconnaissance

You are performing an external black-box assessment against corp.example.com. A preliminary TCP SYN scan with Nmap returns almost no open ports, but you strongly suspect a stateful firewall is rate-limiting or silently dropping your probes. You want to (1) discover as many open ports as possible, (2) avoid triggering basic IDS signatures, and (3) keep the scan reasonably fast. Which of the following approaches is the MOST appropriate next step for enumeration & reconnaissance?

  1. A. Use Nmap with a full connect scan and aggressive timing to punch through filtering: nmap -sT -T5 -p- corp.example.com
  2. B. Use Masscan to quickly identify candidate open ports, then feed them into a slower, stealthier Nmap scan with service detection: masscan corp.example.com -p1-65535 --rate 5000 -e tun0 --wait 5 -oG masscan.gnmap nmap -sS -sV -Pn -p$(grep -oE 'Ports: [0-9]+' masscan.gnmap | cut -d' ' -f2 | tr '\n' ',' | sed 's/,$//') corp.example.com (Correct answer)
  3. C. Switch to an Nmap UDP scan with default timing and OS detection to bypass the firewall: nmap -sU -O -T3 -p- corp.example.com
  4. D. Use Nmap idle scan with a random internet host as a zombie to fully evade the firewall: nmap -sI 8.8.8.8 -p- corp.example.com

Correct answer: B

Explanation: The scenario: external black-box, likely stateful firewall / rate-limiting, initial SYN scan finds little. You want more coverage, avoid obvious signatures, and keep it reasonably fast. Why B is correct: - Masscan is designed for very fast, large-scale port discovery. It sends raw packets and can be tuned with --rate to avoid overwhelming the target or tripping basic thresholds. - The workflow in B is realistic and commonly used in real engagements: 1) Use Masscan to quickly enumerate candidate open ports across the full range. 2) Parse Masscan output to extract ports. 3) Run a focused Nmap SYN scan (-sS) with service detection (-sV) only on those ports. - The command: - masscan corp.example.com -p1-65535 --rate 5000 -e tun0 --wait 5 -oG masscan.gnmap - -p1-65535: full TCP range. - --rate 5000: moderate packet rate; not too noisy but still fast. - -e tun0: explicitly choose the VPN interface (common in remote testing). - --wait 5: wait for late responses. - -oG: grepable output for easy parsing. - nmap -sS -sV -Pn -p$(...) corp.example.com - -sS: SYN scan, more stealthy than -sT. - -sV: service/version detection for meaningful enumeration. - -Pn: skip host discovery (we already know it’s up; avoids ICMP filters). - -p$(...): only scan ports Masscan reported as open, reducing noise and time. - This combo is modern, realistic, and aligns with OSCP/PNPT/OSEP-style workflows. Why A is wrong: - nmap -sT -T5 -p- corp.example.com - -sT (TCP connect) is noisier than -sS and relies on the OS’s connect() calls, which are easier to log and rate-limit. - -T5 is very aggressive and likely to: - Trigger IDS/IPS signatures. - Hit firewall rate limits harder. - Full port range with -T5 from the internet is often counterproductive in a filtered environment. - This does not balance stealth and speed; it just pushes harder. Why C is wrong: - nmap -sU -O -T3 -p- corp.example.com - -sU: UDP scanning is slow, noisy, and often heavily filtered externally. - -O: OS detection sends additional probes that may be blocked or rate-limited. - Full UDP range from the internet is rarely efficient and will not directly solve the problem of limited TCP visibility. - The question is about discovering as many open ports as possible under suspected TCP filtering; switching to full-range UDP is not the best next step. Why D is wrong: - nmap -sI 8.8.8.8 -p- corp.example.com - Idle scan (-sI) requires a suitable zombie host with predictable IPID behavior. - Public DNS servers like 8.8.8.8 are not valid zombies; their IPID behavior is not suitable and they’re heavily used. - Even if a valid zombie existed, full-range idle scanning is extremely slow and fragile. - Idle scan is a niche technique, not the most appropriate or efficient next step here. In modern offensive workflows, using Masscan for fast discovery followed by targeted Nmap enumeration (as in B) is a standard, effective enumeration & reconnaissance pattern.

Sample Question 4 — Enumeration & Reconnaissance

During an internal assessment, you compromise a Linux jump host (10.10.5.10) that has access to an internal subnet 10.10.20.0/24. Your VPN only reaches 10.10.5.0/24, and direct scanning of 10.10.20.0/24 from your Kali box fails. You want to enumerate live hosts and open TCP ports on 10.10.20.0/24 using Nmap from your Kali machine, leveraging the compromised host as a pivot via SSH. Which of the following configurations BEST achieves this while keeping the workflow compatible with standard Nmap usage on your Kali box?

  1. A. Create a local dynamic SOCKS proxy via SSH and configure Nmap to use it directly: ssh -D 1080 -q -C -N user@10.10.5.10 nmap -sS -Pn -p1-1000 --proxy socks4://127.0.0.1:1080 10.10.20.0/24
  2. B. Use SSH local port forwarding to forward a single internal host, then run Nmap against the forwarded local port: ssh -L 8080:10.10.20.50:80 user@10.10.5.10 nmap -sV -p80 127.0.0.1 -Pn
  3. C. Use SSH to create a SOCKS proxy on Kali, then use proxychains to transparently tunnel Nmap scans through the pivot: ssh -D 1080 -q -C -N user@10.10.5.10 # /etc/proxychains4.conf contains: socks5 127.0.0.1 1080 proxychains nmap -sT -Pn -p1-1000 10.10.20.0/24 (Correct answer)
  4. D. Run Nmap directly on the compromised host over SSH with X11 forwarding: ssh -X user@10.10.5.10 'nmap -sS -Pn -p1-1000 10.10.20.0/24'

Correct answer: C

Explanation: The scenario: you have a pivot host (10.10.5.10) that can reach 10.10.20.0/24, but your Kali cannot. You want to run Nmap from Kali, using the compromised host as a pivot, in a way that fits standard workflows. Why C is correct: - The approach in C is a classic and realistic pivoting technique: 1) Establish a dynamic SOCKS proxy via SSH from Kali to the pivot: ssh -D 1080 -q -C -N user@10.10.5.10 - -D 1080: create a SOCKS proxy on 127.0.0.1:1080. - -q -C -N: quiet, compressed, no remote command. 2) Configure proxychains to use that SOCKS proxy (socks5 127.0.0.1 1080). 3) Run Nmap through proxychains: proxychains nmap -sT -Pn -p1-1000 10.10.20.0/24 - proxychains intercepts connect() calls and tunnels them through the SOCKS proxy, effectively making Nmap’s TCP connect scan (-sT) originate from the pivot host. - This keeps the workflow on Kali, works well for TCP connect scans, and is widely used in OSCP/PNPT/OSEP-style pivoting. Why A is wrong: - nmap --proxy socks4://127.0.0.1:1080 is not valid for raw port scanning. - Nmap’s proxy support is limited and primarily for NSE scripts like http-* over HTTP/SOCKS proxies, not for arbitrary SYN or connect scans across a network range. - Even if Nmap had some proxy support, it would not transparently tunnel all scan types the way proxychains does. - So this command will not behave as intended for full TCP port scanning of 10.10.20.0/24. Why B is wrong: - ssh -L 8080:10.10.20.50:80 user@10.10.5.10 - This forwards a single TCP port (local 8080 -> remote 10.10.20.50:80). - It is useful for accessing a specific service (e.g., a web app) but not for scanning an entire subnet. - nmap -sV -p80 127.0.0.1 -Pn - This only scans 127.0.0.1:80, which corresponds to the forwarded 10.10.20.50:80. - You cannot enumerate all hosts or ports on 10.10.20.0/24 this way. - This is service tunneling, not network pivoting for broad enumeration. Why D is wrong: - ssh -X user@10.10.5.10 'nmap -sS -Pn -p1-1000 10.10.20.0/24' - This runs Nmap on the compromised host itself, which is valid in some scenarios, but: - You lose direct control over raw packets from Kali (no packet capture, no direct integration with your local tooling). - You rely on Nmap being installed and allowed on the pivot host. - X11 forwarding (-X) is irrelevant here; Nmap is CLI-based. - While technically possible, it does not match the requirement to keep the workflow compatible with standard Nmap usage on your Kali box (e.g., integrating with local scripts, logging, and tooling). The question is clearly steering toward a pivot-tunneling solution. Thus, using SSH -D + proxychains to transparently tunnel Nmap scans through the pivot (C) is the best and most exam-realistic enumeration & reconnaissance approach.

Sample Question 5 — Enumeration & Reconnaissance

You are enumerating a web server discovered on 10.0.3.15:8080 during an internal engagement. A basic Nmap scan shows: PORT STATE SERVICE VERSION 8080/tcp open http Jetty 9.4.z-SNAPSHOT Direct browsing to http://10.0.3.15:8080/ returns a generic 404 page. You suspect there may be hidden applications or virtual hosts. DNS does not resolve any obvious subdomains for the internal domain corp.local. You want to efficiently discover hidden HTTP paths and potential virtual hosts for further exploitation. Which of the following combined enumeration strategies is the MOST appropriate next step?

  1. A. Run a full TCP connect scan against the host to look for more services, then manually guess URLs: nmap -sT -p- 10.0.3.15 # Then try random paths like /admin, /login in the browser
  2. B. Use Gobuster for directory brute forcing on the non-standard port and FFUF for virtual host fuzzing with a Host header wordlist: # Directory enumeration on port 8080 gobuster dir -u http://10.0.3.15:8080/ -w /usr/share/wordlists/dirb/common.txt -x php,asp,aspx,js,txt -t 50 # Virtual host fuzzing using a generic wordlist and the internal domain ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u http://10.0.3.15:8080/ -H "Host: FUZZ.corp.local" -fs 404 (Correct answer)
  3. C. Use Nikto to scan the server and rely on its built-in checks to find all hidden paths and vhosts: nikto -h http://10.0.3.15:8080/
  4. D. Use Nmap NSE scripts http-enum and http-vhosts to automatically discover all directories and virtual hosts: nmap -p8080 --script http-enum,http-vhosts 10.0.3.15

Correct answer: B

Explanation: The scenario: Jetty on 8080, generic 404 at root, likely hidden apps or vhosts. DNS doesn’t show obvious subdomains. You want efficient discovery of hidden paths and potential virtual hosts. Why B is correct: - B combines two realistic, complementary enumeration techniques: 1) Directory brute forcing on the non-standard port with Gobuster: gobuster dir -u http://10.0.3.15:8080/ -w /usr/share/wordlists/dirb/common.txt -x php,asp,aspx,js,txt -t 50 - -u: target URL including port 8080. - -w: common directory/file wordlist. - -x: file extensions to try (common for web apps). - -t 50: reasonable concurrency for internal networks. - This is standard practice to find hidden paths like /app/, /api/, /admin/, etc. 2) Virtual host fuzzing with FFUF using the Host header: ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -u http://10.0.3.15:8080/ -H "Host: FUZZ.corp.local" -fs 404 - -w: subdomain wordlist. - -u: base URL with port 8080. - -H "Host: FUZZ.corp.local": fuzz the Host header to discover vhosts like app.corp.local, dev.corp.local. - -fs 404: filter responses with size equal to the 404 baseline, highlighting anomalies. - This combination is modern, tool-appropriate, and directly targets both hidden paths and virtual hosts, which is exactly what the scenario calls for. Why A is wrong: - nmap -sT -p- 10.0.3.15 - A full port scan can be useful, but it doesn’t address the specific problem of hidden HTTP paths or vhosts on the already-discovered Jetty service. - “Then try random paths like /admin, /login in the browser” is ad-hoc and inefficient. - This is not an efficient or systematic enumeration strategy compared to using Gobuster/FFUF. Why C is wrong: - nikto -h http://10.0.3.15:8080/ - Nikto is useful for quick checks of common misconfigurations and known vulnerabilities. - However, it is not a comprehensive directory brute-forcer or vhost fuzzer. - It will not “find all hidden paths and vhosts”; its coverage is limited and signature-based. - Relying solely on Nikto misses many modern, custom paths and virtual hosts that wordlist-based fuzzing can uncover. Why D is wrong: - nmap -p8080 --script http-enum,http-vhosts 10.0.3.15 - http-enum: can identify some common directories and applications, but it is not as thorough or configurable as dedicated fuzzers like Gobuster. - http-vhosts: attempts to discover virtual hosts, but it is limited and not as flexible as FFUF with a large, tuned wordlist and response-size filtering. - Nmap NSE scripts are useful, but they are not the primary tools for deep web content and vhost enumeration in modern workflows. - They will not “automatically discover all directories and virtual hosts”; coverage is limited. In real OSCP/OSWE/OSEP-style engagements, combining directory brute forcing (Gobuster/FFUF) with Host-header-based vhost fuzzing (FFUF, wfuzz, Burp Intruder) on the correct port is the most effective enumeration & reconnaissance strategy, which is exactly what option B describes.

Sample Question 6 — Enumeration & Reconnaissance

You are performing an external black-box assessment against a /24 target range. You want to quickly identify live hosts and their top open TCP ports, then later perform detailed scans only against those hosts. Which of the following Nmap workflows is the most appropriate and efficient for the initial enumeration phase?

  1. A. Run: nmap -sS -p- -A -T4 203.0.113.0/24 to discover all ports and services in a single comprehensive scan.
  2. B. Run: nmap -sn 203.0.113.0/24 to identify live hosts, then: nmap -sS -sV --top-ports 100 -T4 -iL live_hosts.txt against the discovered IPs. (Correct answer)
  3. C. Run: nmap -Pn -sV --script=vuln 203.0.113.0/24 to skip host discovery and directly enumerate vulnerabilities on all IPs.
  4. D. Run: nmap -sU --top-ports 100 -T4 203.0.113.0/24 to quickly identify the most common open UDP services and live hosts.

Correct answer: B

Explanation: The question focuses on efficient, realistic enumeration: quickly finding live hosts and their top TCP ports, then doing deeper scans later. Why B is correct: - Command 1: nmap -sn 203.0.113.0/24 - -sn: Ping scan only (no port scan). This is fast and designed for host discovery. - This gives you a list of live hosts which you can save to live_hosts.txt. - Command 2: nmap -sS -sV --top-ports 100 -T4 -iL live_hosts.txt - -sS: SYN scan (stealthy and efficient for TCP). - -sV: Version detection on discovered open ports. - --top-ports 100: Scan the 100 most common TCP ports instead of all 65535, which is appropriate for an initial pass. - -T4: Faster timing template, reasonable for external scans when you want speed. - -iL live_hosts.txt: Only scan hosts previously identified as up. This matches a realistic workflow: discovery → focused enumeration → later deeper scans (e.g., full -p- or targeted scripts) only on interesting hosts. Why A is wrong: - nmap -sS -p- -A -T4 203.0.113.0/24 - -p-: All 65535 TCP ports on 256 hosts is very slow for an initial pass. - -A: Enables OS detection, version detection, script scanning, and traceroute; heavy and noisy. - This is more like a later-stage deep scan, not an efficient initial enumeration. Why C is wrong: - nmap -Pn -sV --script=vuln 203.0.113.0/24 - -Pn: Treats all hosts as up, skipping host discovery, which wastes time on non-existent hosts. - --script=vuln: Runs vulnerability scripts on all hosts; heavy and slow for a /24. - This is not an efficient first step; you typically do vuln scripts after you know which hosts and services are present. Why D is wrong: - nmap -sU --top-ports 100 -T4 203.0.113.0/24 - -sU: UDP scan is significantly slower and more error-prone than TCP scanning. - The question explicitly asks for top open TCP ports; this scans UDP only. - UDP enumeration is usually a secondary phase after you’ve mapped TCP services. Relevant technique: - Efficient external recon typically uses a two-stage approach: 1) Host discovery (nmap -sn or masscan with ICMP/TCP SYN to a few ports). 2) Focused TCP port and service enumeration on live hosts (--top-ports, -sS, -sV), then deeper scans as needed.

Offensive Security Prep Pack Overview

Other Offensive Security Domains

Start the free offensive security Enumeration and Reconnaissance practice test now | 10-question quick start | All offensive security domains | All Sample Tests