Chapter 2: Reconnaissance and Enumeration

Reconnaissance is where a penetration test is won or lost before a single exploit is attempted. Everything that

follows - vulnerability identification, exploitation, post-exploitation - depends on the accuracy of the picture you

build here. A tester who rushes reconnaissance attacks the wrong systems, misses the real attack surface, and

trips alarms that a careful tester would never have set off. A tester who does reconnaissance well walks into the

exploitation phase already knowing which doors exist, which ones are locked, which ones are watched, and

which ones nobody remembers are there.

This chapter covers the full reconnaissance arc: learning without touching the target, learning by probing it, and

turning raw findings into a validated target list. The PenTest+ exam treats reconnaissance as a discipline of

judgment, not a toolbox tour. You will be asked which technique fits a constraint, what a piece of output actually

proves, and where the line between authorized testing and unauthorized access sits. Those are the questions

this chapter trains.

1. Active versus passive reconnaissance

Every reconnaissance technique falls on one side of a single dividing line: does it send traffic to the target, or

does it not? That distinction drives the rest of the chapter, because it decides what you can learn, how likely you

are to be noticed, and whether a technique is even permitted under a given engagement's rules.

1.1 Passive reconnaissance: learning without touching the target

Passive reconnaissance gathers information from sources that already hold it: registration databases, public

DNS data, certificate logs, search engines, code repositories, job postings, and social media. You never send a

packet to the target's systems. The target's logs record nothing, because from their perspective nothing

happened. A WHOIS lookup queries a registrar's database, not the target. A certificate transparency search

queries a public log, not the target. A Shodan query searches Shodan's own database of banners it collected

earlier, not the target's live hosts.

Passive reconnaissance has two limits you must respect. First, it only shows what has already been published or

observed. A host that was never indexed, a subdomain that was never certified, and a service behind a firewall

that never answered a scan will not appear in any public source. Second, passive data goes stale. A banner

Shodan recorded six months ago may describe a service that has since been patched, moved, or retired. Passive

findings are leads, not facts, until something active confirms them.

1.2 Active reconnaissance: probing, and paying for it in noise

Active reconnaissance sends traffic to the target and reads the response: a DNS query to the target's name

server, a port scan against its addresses, a request to its web server, a zone transfer attempt. Active techniques

answer questions passive sources cannot. They confirm whether a host is alive, which ports are open, which

software versions answer, and how the target reacts to unusual input. They also create evidence. Every probe

lands in a log somewhere: a firewall log, an intrusion detection alert, a web server access log. A loud active scan

against a monitored target will be noticed, and in a real engagement that can mean the client's defenders start

hunting you, the test's stealth objective fails, or - if you exceeded scope - a very uncomfortable phone call.

1.3 Choosing: a judgment call, not a preference

Consider an authorized test of CertCrack.com's public presence. The rules of engagement permit passive

collection freely but limit active scanning to a defined address range during business hours, with a ban on

denial-of-service-style techniques. The right sequence is:

1. Collect everything passive first: WHOIS, DNS records, certificate logs, search results, and job postings.

Build a list of domains, addresses, and technologies.

2. Sort that list by confidence and value. A subdomain named in a certificate log is a strong lead. A guessed

subdomain is a weak one.

3. Probe only the in-scope addresses from step 2, starting with the quietest techniques that answer the

question: a DNS query before a port scan, a single service probe before a full scan.

4. Record every active probe and its result. If a defender asks what you did and when, your notes are the

answer.

5. Stop and reassess whenever a result contradicts the passive picture. A host that passive sources say is a

web server but that answers nothing on port 80 or 443 is telling you something - a firewall, a moved

service, or a dead lead.

Figure 5: Active versus passive reconnaissance spectrum, from silent public-source collection to noisy direct probing, with detection risk

rising at each step (illustrated)

2. OSINT: learning from public sources

OSINT is the highest-value, lowest-risk reconnaissance available, and it is where most engagements should

spend their first hours. The trick is knowing which public source answers which question, and how to read each

source without over-claiming what it proves.

2.1 WHOIS and domain registration data

A WHOIS record answers ownership and history questions. The creation date tells you whether a domain is a

long-standing asset or a freshly registered lookalike. The name servers tell you who operates the DNS, which is

often the target's provider or a clue to its infrastructure. The registrar and status codes tell you whether the

domain is locked against transfer, which matters for social engineering scenarios the exam sometimes tests.

What WHOIS does not tell you is anything about live systems: it is a registration record, not a network map.

Scenario: during an authorized test, CertCrack.com's team asks whether an unfamiliar domain,

certcrack-support.com, belongs to them. WHOIS shows it was registered three weeks ago through a different

registrar, with name servers unrelated to CertCrack.com's infrastructure. That combination - young domain,

different registrar, different name servers - is the classic shape of a lookalike domain registered for phishing,

and it goes into the report as a finding even though no technical attack has happened yet.

2.2 DNS records as public information

DNS is a public directory by design. Anyone may query it, and its records describe the target's infrastructure in

surprising detail. The records that matter most in reconnaissance:

• A and AAAA records map names to addresses. They are the starting point for every target list.

• MX records name the mail servers, which reveals the mail provider and sometimes an on-premises mail

gateway worth probing.

• NS records name the authoritative servers, which reveals the DNS provider and the servers that might

accept a zone transfer.

• TXT records carry verification strings, sender policy entries, and sometimes secrets that were pasted in by

mistake. A TXT record is never a place for a password, but testers find them there regularly.

• SOA records name the primary name server and give serial and timing values, which help identify the DNS

platform.

• SRV records advertise services such as directory services and voice systems, which reveal internal

architecture.

• CNAME records alias one name to another, which can lead you from a branded name to a cloud provider

hostname and from there to the provider's infrastructure.

2.3 Certificate transparency logs

Certificate transparency is the single richest passive source for subdomain discovery. Search a log (the public

crt.sh interface is the usual tool) for certcrack.com and you will see certificates for the main site, for staging

hosts, for internal tools that someone once exposed, and for short-lived test hosts whose certificates expired

years ago. Each entry gives you a subdomain, an issuer, and a date range. The date range matters: a certificate

issued last month for a new subdomain suggests active development, while a certificate from four years ago

suggests a retired host that may still answer.

2.4 theHarvester: aggregating public sources

theHarvester automates the boring part of OSINT: it queries many public sources for one domain and

aggregates the results into hosts, email addresses, and IP addresses. You give it a domain and a set of sources -

search engines, certificate logs, DNS data, public breach and code sources - and it returns what those sources

already know. Its value is breadth, not depth: it finds the addresses and names that any single source might

miss, and it saves hours of manual searching.

Read theHarvester output critically. It reports what sources claimed, and sources disagree. An email address

from an old breach dump may belong to a former employee. A host from a search engine cache may no longer

exist. Treat every line as a lead to verify with a direct, in-scope check, and treat email addresses as sensitive data:

they go in the report's evidence handling, not in casual notes or chat messages.

2.5 Shodan: searching what is already exposed

Shodan is a search engine for internet-connected devices. It continuously scans the public internet, records the

banners services return, and lets you search that database. A query can find every host in a country running a

particular product, every exposed database on a default port, or every host whose certificate names a given

organization. Common filters include hostname for a domain, org for an organization name, port for a service

port, product for a software product, os for an operating system, country for a location, net for an address

range, and ssl.cert.subject.cn for a certificate name.

Shodan's power creates its main exam trap. Searching Shodan is passive - you query Shodan's database, not the

target. But acting on a Shodan result, such as connecting to a host you found there, is active and requires

authorization. A tester who finds a CertCrack.com host in Shodan and immediately probes it has crossed from

passive to active without checking scope. The exam tests exactly this boundary.

2.6 Social media and breach data as public sources

Social media and breach data are OSINT sources with special handling rules. Public job postings reveal the

target's technology stack: a posting for an administrator of a specific firewall, database, or cloud platform tells

you what to expect in the environment. Public employee profiles reveal team structure, office locations, and

sometimes internal project names. Public code repositories reveal configuration fragments, internal hostnames,

and occasionally credentials that were committed by mistake.

Breach data requires the most care. Public breach corpora list email addresses and sometimes passwords

exposed in past incidents. As a reconnaissance source, breach data answers one legitimate question: are the

target's accounts already exposed elsewhere, and does the organization know? The rules are strict: use only

public breach sources, never attempt to log in with exposed credentials unless the engagement explicitly

authorizes credential testing, and never use breach data against individuals outside the engagement. Finding

that an employee's password appears in a breach is a finding about the organization's exposure. Using that

password is a separate act that needs separate authorization.

Figure 6: OSINT source map: which public source answers which recon question, from WHOIS and DNS to certificate logs, Shodan, and

social media (illustrated)

3. DNS enumeration

DNS enumeration turns the public directory into a target list. It is part passive and part active: reading published

records is quiet, but zone transfer attempts and brute-force subdomain guessing send queries the target's

name servers will see and log.

3.1 Record types that matter

Section 2.2 listed the records; enumeration is the act of collecting all of them systematically for a domain. Start

with the basics: query the authoritative name servers for NS, SOA, MX, TXT, and the common A records. Then

expand: ask for SRV records for common services, check for CNAME chains that lead to other providers, and look

for TXT records that disclose verification tokens or internal tooling. Each record type answers a different

question, and a complete enumeration answers them all before you move to scanning.

3.2 Zone transfer attempts

A zone transfer attempt is simple: ask a name server for an AXFR of the target zone. In a well-configured

environment the answer is a refusal, and that refusal is itself useful information - it tells you the DNS

administrators did their job. In a misconfigured environment the answer is the whole zone, which is the single

biggest reconnaissance windfall available: one query can replace hours of guessing. Attempting a transfer is

active and will be logged, so it belongs in the active phase, against in-scope name servers only.

3.3 NSEC walking

DNSSEC signs DNS data so resolvers can verify it has not been tampered with. Its NSEC records create a side

effect testers exploit. Each NSEC record names the next name in the zone, in canonical order, so that a resolver

can prove a name does not exist: the chain links every name to its successor. By querying names in sequence

and following the chain, an attacker can walk the entire zone and enumerate every subdomain, even though no

zone transfer was allowed.

NSEC walking matters for two exam reasons. First, it is the answer when a question describes enumerating a

zone whose transfers are refused but whose DNSSEC uses NSEC rather than NSEC3. Second, it illustrates a

recurring exam theme: a security control (DNSSEC) that creates a new disclosure (zone contents) as a side effect.

When a question asks which technique enumerates a DNSSEC zone, check whether it says NSEC or NSEC3 - NSEC

enables walking, NSEC3 defeats it.

3.4 dnsenum and fierce concepts

dnsenum and fierce automate DNS enumeration, and the exam tests what they do rather than their flags.

dnsenum queries for the standard record types, attempts a zone transfer, and then brute-forces subdomains

from a wordlist, optionally resolving each candidate and checking for wildcard records that would produce false

positives. fierce does similar work with a different emphasis: it can test a supplied subdomain list, attempt zone

transfers, and scan nearby address space for related hosts. The concepts that matter for both tools:

1. Start with record collection and a zone transfer attempt before guessing. Guessing is expensive and noisy;

a transfer, if allowed, makes it unnecessary.

2. Use a wordlist sized to the engagement. A small, targeted list of common names (www, mail, vpn, staging,

dev, api, admin) finds the usual hosts quietly. A huge list finds more but generates far more queries and

log noise.

3. Handle wildcard DNS. Some zones answer every query with the same address, which makes every

guessed name look real. Both tools check for this by querying a random name first and treating its answer

as the baseline to filter out.

4. Resolve and record. A subdomain that resolves to an address is a target; a subdomain that does not is

not. The output is a list of live names and addresses, ready for port scanning.

Figure 7: DNS enumeration workflow: record collection, zone transfer attempt, NSEC walking, then dictionary enumeration with wildcard

filtering (illustrated)

4. Service discovery and port scanning

Port scanning is the most recognizable reconnaissance activity and the most misunderstood. A scan does not

find vulnerabilities. It finds listening services. The vulnerability judgment comes later, when you match a service

and version against known flaws. Confusing those two stages is how testers over-claim findings and how exam

candidates pick wrong answers.

4.1 Port states: what a scan result actually means

The six port states, and what each proves:

• Open: a service is listening and answered. This is a confirmed target for further probing.

• Closed: the host answered with a reset, proving the host is up but nothing listens on that port. Closed is

useful negative information: the host exists, the port does not serve.

• Filtered: no answer. A firewall, filter, or dropped packet hides the truth. You cannot conclude the port is

closed or open.

• Unfiltered: the port answered in a way that proves it is reachable, but the scan type used cannot tell

whether it is open or closed. This state appears with ACK scans, which map firewall rules rather than

services.

• Open|filtered: the scan cannot distinguish open from filtered, typical of UDP scans and certain stealth

scans where no response could mean either.

• Closed|filtered: the scan cannot distinguish closed from filtered, typical of the IP ID idle scan.

4.2 Nmap scan types

Nmap is the standard port scanner, and the exam tests scan-type selection against constraints. The major types:

• SYN scan (-sS): sends a SYN and reads the SYN-ACK or RST reply without completing the handshake. It is

fast, quiet relative to a full connection, and requires elevated privileges because it crafts raw packets. This

is the default when privileges allow.

• Connect scan (-sT): completes the full TCP handshake using the operating system's normal connect call. It

works without elevated privileges but is noisier and slower, since every open port produces a full

connection in the target's logs.

• UDP scan (-sU): sends empty UDP datagrams and interprets ICMP unreachable messages as closed. UDP

scanning is slow and unreliable by nature: many services do not answer empty datagrams, and rate

limiting of ICMP messages makes results ambiguous. It is necessary anyway, because UDP services - DNS,

SNMP, NTP - are a major blind spot if skipped.

• ACK scan (-sA): sends ACK packets to map firewall rules. It distinguishes filtered from unfiltered ports but

cannot tell open from closed. Its purpose is firewall mapping, not service discovery.

• NULL, FIN, and Xmas scans (-sN, -sF, -sX): send packets with unusual flag combinations and interpret the

response. Closed ports answer with a reset; open ports stay silent. These stealth scans work against some

systems and fail against others (Windows hosts, for example, reset regardless), so their results need

confirmation with a SYN scan.

• Version detection (-sV): probes open ports to determine the service and version. This is where a scan stops

being a port list and starts being vulnerability intelligence, because versions map to known flaws.

• OS detection (-O): uses TCP/IP stack fingerprints to guess the operating system. It is a guess with a

confidence score, not a fact, and the exam treats it that way.

• Aggressive (-A): combines OS detection, version detection, script scanning, and traceroute. It is loud and

should only be used when stealth does not matter.

4.3 Timing and evasion trade-offs

Nmap timing templates (-T0 through -T5) trade speed against noise and reliability. Paranoid (-T0) and sneaky

(-T1) insert long delays between probes, making the scan hard to correlate but extremely slow. Polite (-T2) is

gentle on the target. Normal (-T3) is the default balance. Aggressive (-T4) is fast and suitable for a responsive

local network. Insane (-T5) risks overwhelming the target and losing accuracy.

Timing interacts with detection. A fast scan against a monitored target triggers rate-based intrusion detection

quickly. A slow scan may stay under thresholds but can take hours against a large range, and results from the

first hour may be stale by the last. Evasion techniques - fragmenting packets, using decoys, spoofing a source

address, randomizing port order - reduce detection further but complicate attribution of results and, in the case

of decoys, implicate innocent addresses in your scan traffic. The exam's position is consistent: evasion is a

technique to know, not a default to apply. Use it when the engagement's stealth requirement demands it,

document it, and never use decoys without understanding that someone else's addresses will appear in the

target's logs.

4.4 NSE: scripting the scanner

NSE's exam relevance is its category logic. Default scripts (-sC) run safe, broadly useful checks. Discovery scripts

enumerate further information about services. Vulnerability scripts check for specific flaws but do not exploit

them. Brute and exploit scripts cross into intrusive territory and require explicit authorization, because they

attempt authentication or exploitation rather than mere observation. A question that asks which NSE category

fits a task is really asking how intrusive the task is: discovery for enumeration, vulnerability for flaw checks, brute

and exploit only with clear authorization.

4.5 Reading scan output: a procedure

Raw Nmap output is easy to misread under exam pressure. Read it in this order:

1. Confirm the host state first. A host reported as down may simply be blocking ping; a scan run with host

discovery disabled can still find ports on it. Never conclude "nothing there" from a down verdict alone.

2. Read open ports and versions together. An open port without a version is an unfinished result; run

version detection before judging it.

3. Treat filtered ports as unknowns, not as closed. Note them for firewall-rule analysis rather than dismissing

them.

4. Compare UDP results with extra skepticism. An open|filtered UDP port is a weak result that needs a

service-specific probe to confirm.

5. Check the script output section last, and separate facts from script guesses. An NSE script that reports a

"possible" vulnerability is a lead for manual verification, not a finding.

6. Write the target list from confirmed results only: open ports with versions, on hosts confirmed alive.

Everything else goes on a follow-up list, not into the exploitation plan.

Figure 8: Nmap scan types compared: SYN, connect, UDP, ACK, and stealth flag scans, with privilege needs, noise level, and what each

result proves (illustrated)

5. Directory and virtual-host enumeration

Web servers hide more than their home pages. Old admin panels, backup files, test directories, API

documentation, and forgotten uploads live under predictable paths, and finding them is often the fastest route

from reconnaissance to a real finding. Directory enumeration guesses those paths from a wordlist and records

which ones answer.

5.1 Gobuster and ffuf

Gobuster and ffuf do the same job with different strengths. Gobuster is purpose-built for directory, DNS, and

virtual-host enumeration: its dir mode requests each wordlist entry as a path and reports the status codes that

come back; its dns mode brute-forces subdomains; its vhost mode brute-forces virtual hosts. ffuf is a

general-purpose web fuzzer: it replaces a keyword in a URL, header, or parameter with each wordlist entry, and

its filtering options (match or filter by status code, size, word count, line count, or response time) let you

separate real findings from noise. Gobuster is the simpler, faster choice for a standard directory sweep. ffuf is

the flexible choice when the target needs header fuzzing, parameter discovery, or fine-grained filtering.

5.2 Wordlists: choosing and trimming

Wordlists decide what you can find. The standard collections (the SecLists project's directory lists are the usual

starting point) contain tens of thousands of common paths, from admin and login to backup and config. A full

list against a large site is slow and noisy. Trim intelligently: check the site's robots.txt file and sitemap first, since

both list paths the owner considers worth indexing or excluding, and both are legitimate public sources. Match

extensions to the technology you already identified: a PHP application deserves .php, .bak, and .old entries; a

Java application deserves .jsp and .war; a static site deserves .html and .txt. Add target-specific words from the

site's own content - product names, department names, project names found in OSINT - because custom paths

never appear in generic lists, and custom paths are where the interesting forgotten content lives.

5.3 Virtual hosts: finding sites sharing an IP

Vhost enumeration works by sending requests to the same IP with different Host headers, one per wordlist

entry, and comparing responses against a baseline. The baseline is critical: send a request with a nonsense Host

header first and record its response size and status. A candidate vhost is only real if its response differs from the

baseline in size, content, or status. Without a baseline, every guess looks like a hit, because the server's default

site answers everything. Gobuster's vhost mode automates this comparison. The findings matter because a

forgotten vhost often runs older, less maintained software than the main site, and it shares the server's trust

and network position.

6. Recon-ng and Maltego workflows

Individual tools answer individual questions. Recon-ng and Maltego answer the harder question: how do all

these answers fit together? Both are aggregation and visualization tools, and the exam tests their workflows

rather than their installation.

6.1 Recon-ng: modules and workspaces

Recon-ng is a modular reconnaissance framework with a database at its center. You work inside a workspace,

load modules from its marketplace, set options (usually a source domain or a list of hosts), run the module, and

the results land in the workspace database, where later modules can use them. A typical workflow:

1. Create a workspace for the engagement so results stay separated from other tests.

2. Load a harvesting module and set the source domain. Run it to collect hosts, contacts, or netblocks from

public sources.

3. Load a resolution module and resolve the harvested names to addresses, which turns names into

scannable targets.

4. Load reporting modules to export the database as a list for the scanning phase, or as a report for the

client.

5. Query the database between steps. The database is the point: each module's output becomes the next

module's input, and the final export is only as good as the intermediate verification.

Recon-ng's discipline is its database hygiene. A workspace that mixes engagements, or that never purges stale

entries, produces target lists that include dead hosts and other clients' data. Keep one workspace per

engagement, verify harvested entries before they become scan targets, and treat the database as evidence: it

should be able to show, step by step, where every target came from.

6.2 Maltego: entities and transforms

Maltego visualizes reconnaissance as a graph. You start with entities: a domain, a company, a person, an email

address. You run transforms on them: a domain transform returns its DNS names, its mail servers, its name

servers, and its IP addresses; an IP transform returns its netblock and its reverse DNS; a person transform

returns associated email addresses and social profiles. Each transform adds nodes and edges, and the graph

grows into a map of the target's relationships: which domains share infrastructure, which people connect to

which organizations, which addresses belong together. The exam value of Maltego is relationship discovery - the

questions it answers are "what else is connected to this?" rather than "what port is open?"

6.3 A combined workflow

Recon-ng and Maltego complement each other when used in sequence:

1. Use Recon-ng to harvest broadly and cheaply: domains, hosts, and contacts from public sources, stored in

the workspace database.

2. Export the verified host and domain list from Recon-ng.

3. Seed a Maltego graph with the most interesting entities: the main domain, the mail provider, and any

unusual hosts the harvest found.

4. Run transforms outward from those seeds to find relationships the flat list hides: shared infrastructure,

related domains, and people connected to the organization.

5. Feed the graph's discoveries back into the target list, and verify each new target with a direct, in-scope

check before it enters the scanning phase.

Figure 9: Recon-ng to Maltego workflow: harvesting into a database, seeding a graph, running transforms, and feeding verified

discoveries back into the target list (illustrated)

7. Wireshark analysis for recon

Wireshark is usually taught as a packet analysis tool, but in reconnaissance it serves a specific purpose:

confirming what the network actually does, as opposed to what documentation or scan output claims. A tester

who captures traffic from their own lab, or who analyzes a packet capture the client provides, can answer

questions no scanner can: what protocols a host really speaks, what intervals its traffic follows, and what data its

requests expose.

7.1 What recon looks like on the wire

Reconnaissance traffic has signatures. A port scan appears as a burst of connection attempts to many ports

from one source, often with unusual flag combinations or half-open handshakes. A DNS enumeration appears

as a flood of queries for guessed names, most returning "no such domain." Beaconing appears as small, regular

connections at fixed intervals - the metronome pattern of malware checking in. DNS tunneling appears as

queries with long, high-entropy subdomain labels, often to a single domain, carrying data in the labels

themselves. Certificate inspection appears in TLS handshakes: the ClientHello's server name indication reveals

the hostname the client wanted, even when the traffic itself is encrypted.

7.2 Filters that answer recon questions

Wireshark's display filters turn a large capture into answers. A dns filter isolates name traffic; dns.qry.name

narrows it to queries for a specific name, and a filter for names containing long labels surfaces tunneling

candidates. A tcp.port filter isolates a service's traffic, and following a TCP stream reconstructs one conversation

end to end. An http.host filter shows which virtual hosts a client requested, which is vhost enumeration

observed rather than guessed. A filter on TLS handshake server names lists the hostnames clients actually

sought. The workflow is always the same: filter to the traffic type, look for the pattern (regularity, volume,

unusual labels, unexpected hosts), and then follow one example conversation to confirm what the pattern

means.

8. Reading and modifying recon scripts

Penetration testers rarely write every tool from scratch. They find scripts - Python port scanners, PowerShell

enumeration scripts, Bash automation - adapt them to the engagement, and run them. The exam tests this skill

directly: given a script, what does it do, what must change before it runs, and what is dangerous about running

it as-is? This section is about reading code with suspicion and modifying it with purpose.

8.1 Before you run someone else's script

Check a script in this order before it ever runs:

1. Read the whole script, not just the usage comment. Malicious or reckless behavior hides in the middle, not

the header.

2. List every network destination it contacts. A recon script should talk to the target and to public data

sources you recognize. A connection to an unknown server, especially one that receives data, is an

exfiltration or command-and-control indicator until proven otherwise.

3. Look for encoded content: long base64 strings, hex blobs, or compressed payloads that decode to

commands. Legitimate scripts rarely hide their logic.

4. Check for credentials, tokens, and keys, both hardcoded and read from files. A script that needs your

credentials should take them as input, not contain someone else's.

5. Check for destructive or intrusive actions: deletion commands, mass requests with no rate limiting,

authentication attempts, and exploit code. A script that claims to be reconnaissance but attempts

exploitation is mislabeled, and running it changes the engagement's authorization.

6. Check the scope variables: target lists, address ranges, and domain names. Replace every default target

with your authorized targets. A script whose default target is a public example or someone else's

infrastructure must never run unmodified.

7. Run it in an isolated lab first, against your own systems, and watch what it actually does before pointing it

at a client.

8.2 Python scripts: common modifications

Python is the most common language for recon tooling, using libraries for HTTP requests, DNS resolution, and

socket work. The modifications testers make most often:

• Change the target variable: a single hardcoded host becomes a list read from a file, so the script covers the

whole authorized range instead of one example host.

• Add output handling: results that only print to the screen become results written to a file, in a format (plain

text, CSV, or JSON) the report can use.

• Adjust timeouts and threading: a script that waits forever on a filtered port, or that fires a thousand

threads at once, gets a timeout value and a thread limit appropriate to the engagement's noise constraints.

• Change the user-agent string: a default library user-agent announces the script in every request log. A

realistic browser user-agent is quieter, and a custom one identifies the test in the client's logs if the

engagement wants attribution.

• Add error handling: a script that crashes on the first refused connection is useless against a large range.

Wrapping requests so failures are logged and the script continues is usually the first modification made.

8.3 PowerShell scripts: common modifications

PowerShell is the native enumeration language on Windows targets and in Windows-based labs. Its recon

cmdlets resolve names, test connectivity, and fetch web content, and its pipeline makes chaining results natural.

Common modifications mirror Python's, with Windows specifics:

• Replace hardcoded computer names or domains with parameters, so the script runs against the authorized

environment instead of the author's example.

• Change output from console display to exported files, since PowerShell's default table output truncates

long values that the report needs in full.

• Adjust authentication: a script that assumes the current user's credentials may need explicit credentials for

a different context, supplied securely rather than written into the script.

• Add throttling: a loop that queries every host in a large range without pauses can overwhelm a domain

controller or trigger account lockout thresholds. A short sleep between iterations is a standard,

exam-noted fix.

8.4 Bash scripts: common modifications

Bash glues command-line tools together: dig and host for DNS, whois for registration, curl for web requests,

grep and awk for parsing. Bash recon scripts are usually short loops over a list, and their modifications are

correspondingly simple:

• Change the input list: a loop over a hardcoded handful of names becomes a loop over a wordlist file or a

target file.

• Change the tool flags: a dig query that asks for one record type becomes a query for several, or a curl

request that follows redirects gains the flags the engagement needs.

• Add output redirection: loop results that scroll past on screen become an appended results file, often with

a timestamp per line.

• Add rate limiting: a loop with no pause between iterations becomes a loop with a short sleep, for the same

noise and reliability reasons as in PowerShell.

8.5 A script-review procedure

Put the checks and the modifications together into a repeatable procedure for any script you did not write:

1. Read the script end to end and summarize in one sentence what it does.

2. List its network destinations, its credential handling, and its destructive or intrusive actions.

3. Replace all default targets with authorized targets and all default credentials with secure inputs.

4. Make the modifications the engagement needs: output to file, timeouts, threading or rate limits, and

realistic request headers.

5. Run it against your own lab systems first and compare its actual behavior with your summary from step 1.

6. Only then run it against the engagement's targets, and keep the modified script as evidence of what was

actually executed.

Chapter check

1. During an authorized test, a tester wants to learn about CertCrack.com's infrastructure without sending any

traffic to its systems. Which technique fits?

A. A SYN scan of the company's address range

B. A zone transfer attempt against its name servers

C. Searching certificate transparency logs for its domains

D. A connect scan of its web servers

2. Which DNS record identifies the servers that receive mail for a domain?

A. MX

B. NS

C. SOA

D. CNAME

3. A tester attempts a zone transfer against a target's name server and receives a refusal. What is the correct

conclusion and next step?

A. The domain has no DNS records, so enumeration should stop

B. The name server is offline and should be reported as down

C. The zone is empty and port scanning should begin immediately

D. The transfer was properly refused; continue with dictionary-based subdomain enumeration and

certificate log searching

4. A scan reports port 443 as filtered and port 22 as closed on the same host. What do these results mean?

A. Both ports have no service listening

B. Port 443 is hidden by a filter and its state is unknown, while port 22 is confirmed closed

C. Port 443 is open and port 22 is blocked by a firewall

D. Both ports are blocked by a firewall and cannot be assessed

5. Which Shodan filter finds hosts belonging to a specific organization?

A. hostname:

B. port:

C. org:

D. net:

6. When enumerating virtual hosts, why is a baseline request with a nonsense Host header sent first?

A. To test whether the server supports encrypted connections

B. To measure the server's response time under load

C. To record the default site's response so real vhosts can be distinguished from it

D. To obtain the server's TLS certificate

7. Before running a reconnaissance script found online, a tester reads it and finds a request that sends the

script's results to an unfamiliar server. What is the most important action?

A. Check how many stars the script has online

B. Verify the script's file size matches the download page

C. Confirm the script runs on the latest language version

D. Remove the unfamiliar request and run the script in an isolated lab first

8. A DNSSEC-signed zone uses NSEC records rather than NSEC3. What does this make possible?

A. Zone transfers to any requester

B. Enumerating the zone by following the NSEC chain from name to name

C. Encrypting all DNS responses in the zone

D. Blocking all subdomain guessing attempts

Answer key: 1. C - 2. A - 3. D - 4. B - 5. C - 6. C - 7. D - 8. B

Recon Toolkit: The OSINT and Survey Tools

Chapter 2 introduced active and passive reconnaissance and the workhorses — Nmap, Recon-ng, Maltego, theHarvester, Shodan. The official objectives name a second tier of recon tools that the exam tests by name: the subdomain enumerator, the OSINT automator, the web archive, the DNS visualizer, the email finder, and the two wireless recon resources. Each gets a box below; the comparison table at the end is the revision view.