Skip to main content

Chapter 3.1 Quiz - Reconnaissance, Scanning & Enumeration

Quiz Mode - All answers are hidden under collapsible sections. Attempt each question before revealing the answer.

Question 1

You run nmap -sS -T4 -p- 10.10.10.50 and observe that port 445 is filtered, but running nmap -sA -p 445 10.10.10.50 shows it as unfiltered. What does this tell you about the firewall rule protecting port 445, and what is your next step?

Reveal Answer

Answer: The firewall is using stateless packet filtering - it blocks inbound SYN packets (initial connection attempts) but does not track connection state, so ACK packets pass through.

Explanation:

  • -sS (SYN scan): sends TCP SYN - firewall drops it - filtered
  • -sA (ACK scan): sends TCP ACK - firewall has no stateful rule to block it - packet reaches host - host responds with RST - unfiltered

A stateful firewall tracks connection state. It would also drop the ACK packet because no corresponding SYN-ACK exchange exists in its state table, returning filtered for ACK scans too. A stateless ACL or simple packet filter only matches on static fields (flags, port, IP) - an ACK to port 445 with no corresponding state entry would still pass.

Next step: Use source port spoofing or ACK-based connection attempts to probe through the stateless filter:

# Source port spoofing (some stateless firewalls allow traffic from port 53 or 80)
nmap -sS --source-port 53 -p 445 10.10.10.50

# Hping3 ACK probe to confirm SMB reachability
hping3 -A -p 445 10.10.10.50      # Send ACK to port 445

# If ACK probes get RST back = host is alive and port is reachable at L3
# Try SYN with fake source port to bypass stateless rule:
hping3 -S -p 445 --sport 53 10.10.10.50

Defensive fix: Replace stateless ACL with a stateful firewall rule (iptables -m state --state NEW or equivalent). A proper rule: iptables -A INPUT -p tcp --dport 445 -m state --state NEW -j DROP.

MITRE ATT&CK: T1595.001 (Active Scanning: Port Scanning)

Question 2

A zone transfer attempt against ns1.target-corp.com succeeds and returns 847 records. Among them you find entries like dev-db01.internal.target-corp.com - 10.50.2.11 and vpn-gateway.target-corp.com - 203.0.113.45. What is the immediate operational value of this output, and what two records would you prioritize for follow-up enumeration?

Reveal Answer

Answer: The zone transfer provides a complete internal network map without active scanning - effectively the same intelligence that a multi-day scan would produce.

Operational value:

  • All internal hostnames and their IPs - eliminates the need for subdomain brute-forcing
  • Reveals naming conventions (e.g., dev-db01 - there are likely prod-db01, qa-db01)
  • Exposes both internet-facing (vpn-gateway) and internal (dev-db01) infrastructure simultaneously
  • Historical hostnames may reveal decommissioned infrastructure still accessible

Two records to prioritize:

  1. vpn-gateway.target-corp.com (203.0.113.45) - the VPN gateway is a high-value perimeter target. Enumerate the VPN software version, protocol (IPsec/SSL), and test for known CVEs. Compromising VPN credentials gives network-layer access.
# Identify VPN software and version
nmap -sV -p 443,500,4500,1194 203.0.113.45
nmap -p 443 --script ssl-cert,ssl-enum-ciphers 203.0.113.45
# Check for Pulse Secure, Fortinet, Citrix NetScaler - all have had critical CVEs
  1. dev-db01.internal.target-corp.com (10.50.2.11) - databases in dev environments commonly have weaker access controls, default credentials, or unpatched versions while holding sensitive data.
# After network access - enumerate database
nmap -sV -p 3306,5432,1433,1521 10.50.2.11   # MySQL, PostgreSQL, MSSQL, Oracle

Defensive fix: Restrict allow-transfer in BIND/named to only the authorized secondary nameserver IP. Verify with:

dig axfr @ns1.target-corp.com target-corp.com
# Should return: Transfer failed.

MITRE ATT&CK: T1590.002 (Gather Victim Network Information: DNS)

Question 3

You're running an Nmap scan from your attack box against a target that has a Snort IDS with the portscan preprocessor enabled. Which combination of Nmap flags would reduce your detection probability the most, and what residual risk remains?

Reveal Answer

Answer: -sS -T1 --randomize-hosts --data-length 25 -D decoy1,decoy2,ME --source-port 53

Flag-by-flag justification:

nmap -sS \                      # SYN scan - no completed connections, no app-layer logs
  -T1 \                         # Sneaky timing - 15s between probes (below threshold detectors)
  --randomize-hosts \            # Non-sequential scanning evades sequential scan signatures
  --data-length 25 \             # Random payload breaks content-based Snort signatures
  -D 10.0.0.1,10.0.0.5,ME \     # Decoys obscure true source IP in IDS logs
  --source-port 53 \             # Source port 53 may bypass stateless firewalls
  -n \                           # No DNS resolution (no DNS queries to resolver logs)
  -p 22,80,443,3389,445,8080 \  # Limit to key ports - fewer probes = lower anomaly score
  10.10.10.0/24

Why these work against portscan preprocessor:

  • Snort's portscan preprocessor triggers on a threshold of SYNs to multiple ports/hosts within a time window
  • -T1 spreads probes over long enough windows to stay below the default threshold
  • --randomize-hosts prevents the sequential pattern that portscan engines recognize
  • Decoys increase noise-to-signal ratio in IDS alerts

Residual risks:

  1. Decoy IPs must be live hosts - Snort can filter spoofed IPs by TTL inconsistencies or source validation
  2. If the target runs Zeek, even T1 scans are visible in conn.log as RST-only connections (no established sessions)
  3. Source port 53 is trivially defeated by any stateful firewall
  4. The scan still takes days at T1 across a /24 - operational window may not allow it

What no scan flag defeats: Physical TAPs feeding a SIEM with baseline behavioral analytics. Your scan profile deviates from normal traffic regardless of how slow it is.

MITRE ATT&CK: T1595.001 (Active Scanning: Port Scanning)

Question 4

Using only passive reconnaissance - no packets sent to the target - build the most complete picture possible of target-corp.com. List the five specific data sources you would query, what each reveals, and the CLI command for each.

Reveal Answer

Answer:

1. Certificate Transparency (crt.sh) - All subdomains

curl -s "https://crt.sh/?q=%.target-corp.com&output=json" | \
  jq -r '.[].name_value' | sed 's/\*\.//g' | sort -u

Reveals: Every subdomain that has ever had a TLS certificate issued - often 80%+ of the full subdomain inventory including staging, dev, internal-facing apps.

2. Shodan - Internet-facing services, banners, software versions

shodan search "hostname:target-corp.com" \
  --fields ip_str,port,product,version,os,org

Reveals: Open ports and services on all internet-facing IPs, software versions, OS, SSL cert details, HTTP response headers - without sending a single packet to the target.

3. BGP/ASN lookup - IP ranges

curl -s "https://api.bgpview.io/search?query_term=target+corporation" | \
  jq '.data.asns[].asn' | \
  xargs -I{} curl -s "https://api.bgpview.io/asn/{}/prefixes" | \
  jq -r '.data.ipv4_prefixes[].prefix'

Reveals: All IP ranges owned by the target organization, their ASN, upstream providers, and peering relationships - defines the complete network footprint.

4. GitHub / truffleHog - Leaked secrets and internal hostnames

trufflehog github --org=target-corporation --only-verified --json 2>/dev/null | \
  jq '{file:.SourceMetadata.Data.Github.file, detector:.DetectorName, raw:.Raw}'

Reveals: API keys, database connection strings, private keys accidentally committed, internal hostnames/URLs referenced in code comments or config files.

5. DNS + SPF/DMARC - Mail infrastructure and email security posture

for record in MX TXT NS SOA; do
    dig +short $record target-corp.com
done
dig +short TXT _dmarc.target-corp.com

Reveals: Mail server infrastructure, third-party services (Salesforce, SendGrid, Google Workspace), DMARC enforcement level (p=none = phishing viable), SPF authorized senders, and nameserver identity.

Combined output: Before sending a single packet to the target, you know their IP ranges, all subdomains, software running on internet-facing hosts, whether their developer committed credentials to GitHub, and whether their email can be spoofed. This is the foundation of a professional engagement.

MITRE ATT&CK: T1596 (Search Open Technical Databases), T1590 (Gather Victim Network Information), T1593 (Search Open Websites/Domains)

End of Chapter 3.1 Quiz - Reconnaissance, Scanning & Enumeration