Ethical Hacking
Passive vs Active Reconnaissance
Lesson 6 introduced the distinction between passive and active reconnaissance. This lesson goes deeper — looking at the specific tools and techniques used in each phase, the point at which switching from passive to active changes your legal standing, and how experienced pen testers manage the transition between the two.
The core difference — contact with the target
The single most important distinction between passive and active reconnaissance is whether your activity reaches the target's systems. That is the line — not the tool you are using, not the information you are after, but whether packets are sent to infrastructure the target controls.
A WHOIS lookup queries a public registry server — not the target. A DNS lookup against a public resolver — not the target. Reading a LinkedIn profile — not the target. These are all passive. The moment you send a packet to an IP address the target owns, you have crossed into active reconnaissance — and that requires authorisation.
This matters practically because the same tool can be used in both passive and active modes. A DNS lookup run against a public resolver is passive. The same lookup run directly against the target's DNS server is active. The tool is identical. The legal and operational implications are completely different.
Side-by-side — passive and active techniques compared
Here is a direct comparison of the techniques used in each phase. Notice that many goals — discovering subdomains, identifying technologies, mapping the network — can be achieved through both passive and active means. The passive version takes longer and finds less. The active version is faster and more comprehensive, but it leaves a footprint on the target's systems.
Shodan appears in the passive column for a reason worth understanding. Shodan is a search engine that continuously scans the internet and indexes what it finds — open ports, running services, banners, TLS certificates. When you query Shodan, you are reading that index, not contacting the target directly. The scan that Shodan ran previously is what makes direct contact. Your query is passive.
The transition point — when passive becomes active
The transition from passive to active reconnaissance is not something that happens gradually. It is a hard line — and crossing it without authorisation turns an information-gathering exercise into an unauthorised computer access offence.
In a professional engagement, this transition is agreed in advance. The Rules of Engagement document will typically specify when active testing can begin — often defined by a date and time, a specific IP range, and a contact number to call if anything breaks. You do not move to active recon until all of that is confirmed in writing.
Every item on that checklist needs to be confirmed before your first active scan runs. Missing even one of them means you are either operating without full authorisation or without the safety net that protects you if something goes wrong mid-engagement.
Active reconnaissance in practice — the first scan
Once the active phase begins, the first thing most pen testers do is confirm that the passive recon picture is accurate and complete. Passive sources can be outdated — Shodan's last scan of a target might be weeks old. The live environment may have changed. The first active probes are often just confirmations of what the passive phase suggested.
The scenario: Your passive recon phase is complete. The client's IT team has whitelisted your IP address and confirmed the testing window is open. It is 9 AM on day two. You are beginning active reconnaissance against the logistics company's network. Your first task is to confirm which of the subdomains you found yesterday are actually live and responding.
# This script checks which subdomains from our passive recon are actually live
# It sends a real DNS query for each one — this is ACTIVE recon
# Only run this after your IP has been whitelisted and the testing window is open
# Loop through each subdomain name one at a time
for sub in www mail vpn portal staging; do
# Build the full subdomain and ask DNS what IP address it points to
# 2>/dev/null hides any error messages so the output stays clean
# grep "has address" filters out everything except the IP address line
result=$(host $sub.targetlogistics.com 2>/dev/null | grep "has address")
# -n "$result" checks if a result came back — if yes, the subdomain is live
if [ -n "$result" ]; then
echo "[LIVE] $sub.targetlogistics.com — $result" # print the subdomain and its IP
# If nothing came back, the subdomain did not resolve — it is down or does not exist
else
echo "[DOWN] $sub.targetlogistics.com"
fi
done # end of the loop — move to the next subdomain in the listBreaking it down:
Iterates through each subdomain from your passive recon list. In a real engagement you would have a much larger list — sometimes hundreds of subdomains to check. The loop handles all of them automatically without retyping the command each time.
Any IP starting with 192.168 is a private internal address — not reachable directly from the internet. The staging server sits on the internal network but its subdomain resolves publicly. Whether it can actually be accessed needs confirming in the next phase.
A live VPN gateway on a public IP is a high-value target. The next step is identifying the VPN software and its version number — done in the scanning phase — to check whether it is running a known vulnerable build. VPN software has been one of the most exploited categories in real-world attacks over the past five years.
Stealth vs speed — a real trade-off in active recon
Once you are in the active phase, you face a trade-off that every pen tester has to think about: speed versus stealth. Running aggressive, fast scans gives you more information quickly — but it also generates a lot of noise. Intrusion detection systems will flag it. Security analysts will notice. If your client has told you to test without notifying their security team, a noisy scan gives the game away.
On the other hand, a very slow and stealthy scan looks exactly like how a real attacker would operate — patient, methodical, designed not to trigger alerts. This is a better simulation but takes considerably longer to complete.
Aggressive scan
Fast, loud, comprehensive. Sends thousands of packets quickly. Completes in minutes. Almost certain to trigger IDS alerts and appear in security logs.
Best for: White box engagements where the security team is already informed, or when speed matters more than stealth.
Slow and stealthy scan
Spreads probes over hours or days with randomised timing and decoy traffic. Designed to look like normal background internet noise. Much harder to detect.
Best for: Black box or red team engagements where simulating a realistic attacker matters and the security team should not be tipped off.
Documenting everything from the first moment
One discipline that separates professional pen testers from amateurs is documentation. From the first passive search to the last active probe, everything gets recorded — what command was run, at what time, against which target, and what it returned. This serves three purposes.
It builds the report
Everything in your final report needs evidence. Screenshots, command output, timestamps. If you did not document it during the engagement, reconstructing it afterwards is either impossible or time-consuming. Notes taken in real-time are always more accurate than memory.
It protects you legally
If a client later claims you tested systems outside your scope or caused damage, your timestamped logs show exactly what you touched and when. Without documentation, it is your word against theirs.
It enables the retest
After the client patches the vulnerabilities you found, they often request a retest to verify the fixes. Without detailed notes on exactly what you did to trigger each finding, running the same test again is much harder than it should be.
A simple documentation log for the recon phase
Every command run during an engagement gets logged in a table like this — recording the exact time, what tool or source was used, which target it was run against, and what it returned. This is the actual working document a pen tester keeps open throughout the day. The last row below shows why this matters: Shodan revealed a critical CVE on the VPN server at 10:31 — found passively, before any active scan had touched that host.
Teacher's Note: The best pen testers are meticulous note-takers. Get into the habit of documenting every command and its output from the very first engagement — it will save you hours of reconstruction work later and make your reports significantly stronger.
Practice questions
Scenario:
Scenario:
Scenario:
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Lesson 8
Information Gathering Tools
The specific tools professionals use to gather intelligence — theHarvester, Maltego, Shodan, and more — with hands-on examples for each.