Passive vs active reconnaissance

Overview

Security objective. The asset being protected in this lesson is the information about your target and, on the defensive side, the target's ability to notice it is being studied. The threat is an outsider mapping a network's attack surface. As an authorized tester you learn to gather that map responsibly; as a defender you learn to detect the active half of it. By the end you can tell, for any recon action, whether it is silent (passive) or leaves a trace (active), and you can plan work that respects scope and authorization.

Reconnaissance means gathering information about a target before you test it. It is the first real work in an engagement and it comes in two forms:

• Passive recon collects data from third parties and public sources without sending traffic to the target. Examples: DNS records, WHOIS, Certificate Transparency (CT) logs, Shodan, Censys, job postings, and other open-source intelligence (OSINT).
• Active recon interacts with the target directly — ping sweeps, port scans, banner grabs, web crawling. It returns richer, current data, but every probe can be logged by the target.

This lesson builds directly on your prerequisite, The phases of an engagement (methodology-phases). There you saw that a professional test moves through ordered phases — scoping and authorization, reconnaissance, scanning/enumeration, exploitation, and reporting. Recon is that second phase, and the passive-then-active ordering you learn here is what makes the phase disciplined instead of noisy. The general rule is simple: do passive recon first, then active. It leads into your next lesson, DNS, WHOIS, and subdomain discovery (recon-dns-whois), which drills into the specific passive sources named above.

Why it matters

In authorized professional work, the passive/active distinction controls two things at the same time:

• How much you learn about the target's real, current state.
• How much noise you make — how detectable you are — while learning it.

Passive recon is stealthy. It reads public data held by third parties, so in most engagements it needs no special authorization to read (though you must still respect the third party's terms of service and never social-engineer real people). It lets you map a large surface for free before spending a single loud packet.

Active recon is detectable by design: your packets arrive at the target and can land in its logs, its IDS, and its SOC's alert queue. That is exactly why it must stay strictly inside your authorized scope and time window. Getting this wrong is not a style problem — unauthorized active scanning of systems you do not own can be a crime in many jurisdictions and will end an engagement (and a career) fast.

There is a second, symmetric reason this matters: defenders get paid to catch the active half. A blue-team analyst who understands what a port scan looks like in the logs can detect an intruder in the recon phase — long before exploitation. Learning both sides makes you a better tester (you know what you are triggering) and a better defender (you know what to watch for).

Core concepts

Each concept below is taught on its own: a definition, a plain explanation, how it works, when it applies and when it does not, and a common pitfall.

1. Passive reconnaissance

Definition. Information gathering in which no packet you generate reaches the target's systems. You query third parties and public sources instead.

Plain explanation. You are reading about the target from records other people already collected — like researching a building from public property records and street-view photos rather than walking up and rattling the doors.

How it works. Typical sources:

• Search engines, the company website, press releases, job postings, and social media.
• DNS records, WHOIS registration data, and Certificate Transparency (CT) logs (public logs of issued TLS certificates that often reveal subdomain names).
• Internet-wide scan databases such as Shodan or Censys — they scanned the internet already, so you read their stored results instead of scanning yourself.
• Public code repositories and document metadata.

When / when not. Use it first, always, to build the widest possible picture cheaply and quietly. It is not enough on its own: public data is often stale or incomplete, so it cannot confirm what is running on a host right now.

Pitfall. People assume passive means "consequence-free." Reading a CT log is passive; but interacting with a real employee to extract information, or hammering a third-party API against its terms of service, is neither harmless nor in-scope. Passive is about not touching the target, not about ignoring ethics or terms of service.

2. Active reconnaissance

Definition. Information gathering that sends traffic to the target and interacts with it directly.

Plain explanation. Now you are actually knocking on doors and listening for answers: ping sweeps to find live hosts, port scans to find open services, banner grabs to read version strings, and web crawling to map an application.

How it works. You send packets (ICMP echo, TCP SYN, HTTP requests) and interpret the responses. It is far richer than passive recon because it reveals the current state — which ports are open, which service versions answer. That richness is the reward for the risk.

When / when not. Use it after passive recon has mapped the surface, and only within your authorized scope and time window. Do not run active recon against any host you have not confirmed is in scope.

Pitfall. Active recon is logged. A single aggressive scan can trip an IDS and burn your stealth for the rest of the engagement — and against an out-of-scope host it can be illegal.

3. OPSEC (operational security)

Definition. Protecting information about your own activity — here, keeping your recon from being noticed.

Plain explanation. Every active probe is a footprint. OPSEC is the discipline of leaving as few footprints as the objective allows, and of understanding what each footprint looks like from the defender's side.

How it works. You minimize and pace active traffic, prefer passive sources when they answer the question, and stay aware that scans generate connection logs, IDS alerts, and rate-based anomalies.

When / when not. OPSEC matters most on stealth-oriented (red-team) engagements. On a cooperative, announced vulnerability assessment, stealth is often not the goal — speed and coverage are — but you still log and time-box your activity.

Pitfall. Treating stealth as always-on. Sometimes the client wants to see if their SOC catches you; then loud is fine — but only because it is agreed in scope.

4. Ordering: passive before active

Definition. A sequencing rule: exhaust passive sources before sending any active probe.

Plain explanation. Map for free and quietly first; then aim your loud probes precisely at what you already found, instead of blindly scanning everything.

How it works. Passive recon yields hostnames, IP ranges, and technologies. You feed those into a small, targeted active scan rather than a broad, noisy sweep — fewer packets, less noise, better data.

Pitfall. Skipping straight to a full-range port scan. It is loud, slow, and often scans hosts a five-minute CT-log read would have told you to ignore.

Threat model

                          TRUST BOUNDARY (the target's perimeter)
                                        |
  ASSETS being studied:                 |   ENTRY POINTS an active probe hits:
   - hostnames / subdomains             |    - open TCP/UDP ports
   - IP ranges                          |    - service banners (versions)
   - service versions                   |    - web app endpoints
   - employee/tech footprint            |
                                        |
  PASSIVE recon path (NO packets cross the boundary):
   tester ---> [Search / DNS / WHOIS / CT logs / Shodan / Censys]   (third parties)
                       ^ reads stored public data; target sees nothing
                                        |
  ACTIVE recon path (packets CROSS the boundary and are logged):
   tester ============> | firewall | ==> hosts/services ==> [logs, IDS, SOC alerts]
                        ^ trust boundary; every crossing can be recorded

  Insecure assumption an attacker exploits: "a scan is just noise, nobody reads the logs."
  Defensive reality: connection logs + IDS turn active recon into a detectable event.

Knowledge check.

1. Which asset does the defender protect in this lesson — the tester's data, or the target's ability to notice it is being studied?
2. On the diagram, where is the trust boundary, and which recon path crosses it?
3. What insecure assumption makes an attacker careless during active recon, and which two log sources prove that assumption wrong?
4. Why is a broad active port scan only acceptable inside an authorized lab or an agreed scope?

Syntax notes

Recon is a concept, not one command, but a few lab-safe commands make the passive/active line concrete. Everything below targets only hosts you own or are authorized to test (here, localhost / your own lab VM).

# PASSIVE-style: query a THIRD PARTY, not the target.
# whois asks a registry's database; no packet goes to the target's own servers.
whois example.com              # 'example.com' is IANA's reserved documentation domain (safe to name)

# PASSIVE-style: a DNS resolver answers from records; you are not probing the host itself.
dig +short example.com A       # ask a resolver for the A record

# ACTIVE: nmap sends packets DIRECTLY to the host and reads the responses.
# -sT = full TCP connect scan; run ONLY against your own lab host.
nmap -sT -p 1-1000 127.0.0.1   # scans YOUR loopback interface only

Annotations:

• whois / dig reach a registry or resolver — a third party — so they behave as passive-style OSINT lookups; the target's own servers are not contacted.
• nmap against 127.0.0.1 is active: real packets, real responses, and (on a monitored host) real log entries. 127.0.0.1 is your own machine, so it is always safe and in scope.
• Never point these active tools at an address you do not own or have written permission to test.

Lesson

Reconnaissance is information gathering. There are two types. They differ by one question: do you touch the target or not?

Passive recon

Collect information without sending any traffic to the target's systems. You query third parties and public sources instead:

• Search engines, the company website, job postings, and social media.
• DNS and WHOIS records, and Certificate Transparency (CT) logs.
• Shodan or Censys. These services already scanned the internet, so you simply read their data.
• Public code repositories and document metadata.

Because you never touch the target, passive recon is essentially undetectable by them.

Active recon

Here you interact with the target directly: ping sweeps, port scans, banner grabbing, and web crawling.

This is far richer. You learn what is actually running. But it is noisy and logged. Active recon must stay inside your authorized scope and time window.

The trade-off

Passive first, active second.

1. Build the fullest possible picture from public data. This is free and stealthy.
2. Then spend your "loud" active probes efficiently, aimed at what you already mapped.

On a real engagement, active recon is where you start leaving footprints in the target's logs.

Code examples

This lesson is on the concept track, so the "code" is a set of lab-safe commands plus the log evidence they create. The shape is noisy (active) vs quiet (passive) → the secure/defensive habit → verify by reading the logs.

1. WARNING: intentionally vulnerable — use only in a local, isolated, authorized lab. Do not deploy.

A careless tester runs a broad, fast, un-scoped active scan and assumes nobody is watching:

# WARNING: intentionally noisy example. Lab host you OWN only (here: your loopback).
# -T5 = fastest/loudest timing, -p- = ALL 65535 ports. This is maximally detectable.
nmap -sS -T5 -p- 127.0.0.1

Why this is a problem in real work: -T5 and -p- generate a flood of connection attempts in a very short window — the single easiest-to-detect pattern a defender looks for. Aimed at anything you are not authorized to scan, it is also likely unlawful.

2. Secure / defensive habit

Do passive recon first, then a small, paced, scoped active scan aimed only at what you found:

# Step A - PASSIVE: learn names/records from third parties (no packets to the target host).
whois example.com | grep -Ei 'registrar|name server'
dig +short example.com A

# Step B - ACTIVE but disciplined: only the handful of ports that matter, gentle timing,
# and ONLY against a host you own/are authorized to test (your lab loopback here).
nmap -sT -T2 -p 22,80,443 127.0.0.1 -oN /tmp/lab_scan.txt
#      |    |   |                       |
#      |    |   |                       +-- save evidence for your report
#      |    |   +-- just the services you expect, not all 65535
#      |    +-- slow, polite timing = far less like a flood
#      +-- plain TCP connect; no raw-socket privileges needed

3. VERIFY the defensive claim — read the logs the active scan produced

The point of the exercise is to see that active recon is detectable and passive recon is not. On a lab Linux host, watch a service log while you scan:

# In terminal 1, tail your lab web server's access log:
tail -f /var/log/nginx/access.log        # or your lab app's log path

# In terminal 2, run ONLY the passive step (whois/dig): terminal 1 shows NOTHING new.
# Then run the scoped active step against the lab host: terminal 1 now shows probe hits.

Expected result. During the passive commands the access log stays quiet — you contacted third parties, not the host. During the active nmap, connection attempts to ports 80/443 appear in the log (and, if a lab IDS is running, an alert). That contrast is the lesson: passive leaves no trace on the target; active does. It also demonstrates the defender's win — the scan was detected because someone logged and read the traffic.

Lab cleanup / reset. rm -f /tmp/lab_scan.txt, stop any lab containers/VMs you started (docker compose down or shut down the VM), and clear or rotate the test log if you want a clean slate. Never run any of the active commands outside your own lab.

Line by line

Walking through the disciplined sequence in the code section:

How the picture changes as you go: after A1–A2 you hold names and records but have touched nothing — your footprint on the target is zero. At B you convert that map into a few precise probes; because you scoped to three ports with polite -T2 timing, you create a small, explainable burst instead of a flood. At V2 vs V3 the log itself proves the distinction: silence during passive, entries during active. The value the tester gains rises at step B; the noise also rises only at step B — which is exactly why passive comes first.

Common mistakes

Real mistakes beginners make, why they are wrong, the fix, and how to prevent them.

1. "Scanning is passive because I'm just looking."

• Why wrong: a port scan sends packets to the target and is logged; "looking" still means touching. This confusion leads people to scan out-of-scope hosts thinking it is harmless.
• Corrected: the test is did my packet reach the target? If yes, it is active. A scan is always active.
• Prevent: before any tool, ask "does this send traffic to the target, or read a third party's data?"

2. Jumping straight to a full-range active scan.

• Why wrong: it is loud, slow, and wastes probes on hosts passive recon would have ruled out — trading stealth for data you did not need yet.
• Corrected: passive first, then a targeted active scan of the ports and hosts you actually found.
• Prevent: keep a written recon checklist that lists passive sources before the first active step.

3. Treating passive recon as ethics- and terms-free.

• Why wrong: not touching the target is not the same as "anything goes." Social-engineering a real employee or violating a data source's terms of service is still off-limits.
• Corrected: stick to reading public/third-party data within each source's terms; never manipulate real people during recon.
• Prevent: note the source and its terms next to every passive finding.

4. Running active recon outside the authorized scope or window.

• Why wrong: scanning systems you do not own or are not permitted to test can be unlawful and voids the engagement.
• Corrected: confirm each active target against the signed scope before probing; stay inside the agreed time window.
• Prevent: keep the scope document open; check every IP/hostname against it first.

5. Assuming "it didn't alert" means "nobody noticed."

• Why wrong: absence of an alert is not absence of a log line. Connection logs may still hold your scan for later review.
• Corrected: assume active recon is recorded even when it is quiet, and document your own activity so it can be distinguished from a real attacker.

Debugging tips

When recon does not behave as expected, work through these.

• nmap shows all ports filtered/closed on your lab host. A local firewall may be dropping probes. Check with sudo ufw status (Linux) or your VM's firewall, and confirm the service is actually running (ss -tlnp). Ask: is the host up, is the service listening, is a firewall in the way?
• whois/dig return nothing. Your resolver or network may be blocking outbound queries, or the name may not exist. Try a different resolver (dig @1.1.1.1 +short example.com) and re-check spelling. Ask: am I querying the right third party, and can I reach it?
• The access log stays empty during your active scan. You may be tailing the wrong log path, or the scan hit ports with no logging service. Confirm the service and its log location, and scan a port that host actually serves. Ask: is this the log for the service I probed?
• You are unsure whether an action was passive or active. Run it while tailing the target's logs on your lab host: new entries mean active. This is the definitive test.
• Questions to ask when recon fails: Did any packet leave for the target, or only for a third party? Is the target host reachable and in scope? Am I reading the right log? Is timing (-T) or a firewall hiding results?

Memory safety

Security & safety — detection, logging, and authorization.

Because active recon is the detectable half, both testers and defenders must handle logs well.

What a defender should log to detect recon (and what a tester should record about their own runs):

• Timestamp (with time zone) of each connection or request.
• Source — the IP/identity making the connections.
• Resource — the destination host and port, or the URL path requested.
• Result — connection accepted/refused/reset, HTTP status code.
• Security decision — whether a firewall or IDS rule fired and what it did (allow/deny/alert).
• Correlation id — an engagement or session id so a burst of probes can be grouped and, for authorized tests, matched to the tester's activity log.

What to NEVER log: passwords, session tokens or cookies, API keys or private keys, full payment card numbers (PANs), or unnecessary personal data (PII). Recon logs are about who probed what, when, and with what result — not secrets. Use placeholders like API_KEY=<development-placeholder> in any example.

Which events signal recon abuse: many connections from one source to many ports in a short window (port-scan pattern); sequential requests walking through URL paths or subdomains (enumeration); a spike of DNS or reverse-DNS lookups; requests with scanner-style user agents. Correlate by source + short time window rather than a single line.

How false positives arise: legitimate uptime monitors, vulnerability scanners run by your own team, load balancers health-checking, or search-engine crawlers can all look like recon. Reduce false alarms by allow-listing known scanners and monitors, and by tuning thresholds to the environment. For authorized tests, share the tester's source IP and time window with the SOC if the engagement is not a stealth test — otherwise the whole point is to see whether they catch it.

Authorization is the safety rail. Only run active recon against systems you own or have explicit written permission to test, inside the agreed scope and time window. Everything active in this lesson targets 127.0.0.1 or a lab VM you control.

Real-world uses

Authorized real-world use case. A consultancy is hired to assess a client's external footprint. On day one they do passive recon only: pull the client's domains from WHOIS, enumerate subdomains from Certificate Transparency logs, and check Shodan for already-known exposed services — all without sending a packet to the client. They hand the client a surface map. On day two, inside the signed scope and agreed hours, they run targeted active scans against just those in-scope hosts to confirm what is live, then move to enumeration. The passive phase made the active phase small, precise, and defensible.

Professional best-practice habits:

• Validation: confirm every active target against the signed scope before probing it.
• Least privilege: use the least intrusive method that answers the question — a CT-log read before a scan, a three-port scan before an all-ports scan.
• Secure defaults: default to passive; make active a deliberate, scoped decision.
• Logging: record your own active activity (source, time, targets) so it is distinguishable from a real attacker during and after the test.
• Error handling: if a scan strays toward an out-of-scope host, stop, document, and re-confirm scope before continuing.

Beginner vs advanced.

Remember: passing an automated scanner clean does not prove a system is secure, and nothing is ever "completely secure." Recon findings are a starting map, not a verdict.

Practice tasks

All tasks are lab-only: use localhost, a container, or an intentionally-vulnerable VM you own. Authorization checklist before any active task: (1) I own or have written permission to test this host; (2) it is in scope; (3) I am within the agreed time window; (4) I have a rollback/cleanup plan. Each task ends by remediating or verifying defensively.

Beginner 1 — Classify the activity.

• Objective: sort 10 recon actions into passive vs active.
• Requirements: list actions (WHOIS lookup, port scan, reading CT logs, banner grab, Shodan query, ping sweep, reading a job posting, web crawl, dig A record, HTTP request to the target). For each, write passive/active and the one-line reason (did a packet reach the target?).
• Output: a two-column table.
• Hints: third party = passive; target = active.
• Concepts: the passive/active test.

Beginner 2 — Passive-only footprint of a name you own.

• Objective: build a small surface map without touching any target host.
• Requirements: using only whois, dig, and one public CT-log search, gather registrar, name servers, A record, and any subdomains for a domain you own or the reserved example.com.
• Constraints: send zero packets to the target's own servers; note each source.
• Hints: dig +short, whois.
• Concepts: passive recon, OSINT sourcing.

Intermediate 1 — Scoped active scan + evidence.

• Objective: run a disciplined active scan on your lab host and capture proof.
• Requirements: nmap -sT -T2 against 3–5 expected ports on 127.0.0.1 or a lab VM; save output with -oN.
• Input/Output: input = your lab host; output = a saved scan file.
• Constraints: only ports you expect; polite timing; lab host only.
• Hints: start from the ports your Beginner-2 map suggested.
• Concepts: targeted active recon, least privilege, evidence.
• Defensive conclusion: after scanning, note which of those ports should actually be exposed and which you would recommend closing.

Intermediate 2 — Detect your own scan.

• Objective: prove active recon is detectable.
• Requirements: tail your lab service's access log; run the passive commands (expect silence) then the active scan (expect probe entries). Write the log fields that identify a scan.
• Output: a short note listing timestamp/source/resource/result seen for the active run and nothing for the passive run.
• Hints: tail -f in one terminal, scan in another.
• Concepts: detection, logging, the passive/active contrast.
• Defensive conclusion: propose one detection rule (e.g., N connections to M ports from one source within T seconds) and one tuning to avoid false positives from your own uptime monitor.

Challenge — Recon plan with an OPSEC and detection view.

• Objective: write a one-page recon plan for a lab target that sequences passive-then-active and maps each active step to its detection footprint.
• Requirements: list passive sources first; then each active step with its scope, timing, and the specific log/IDS signal it would create; include the authorization checklist and cleanup steps.
• Constraints: lab-only; no full-range scans without justification; no out-of-scope hosts.
• Hints: borrow the threat-model diagram's entry points as your active-step list.
• Concepts: ordering, OPSEC, detection, authorization.
• Defensive conclusion: for each active step, state the single detection rule a blue team would use to catch it, and verify your plan by confirming every active target appears in your scope list. (No exploitation — recon only.)

Summary

Main concepts. Reconnaissance is information gathering, split by one test: does a packet you generate reach the target? Passive recon reads third-party/public data (DNS, WHOIS, CT logs, Shodan/Censys, OSINT) and touches nothing, so it is essentially undetectable by the target. Active recon (ping sweeps, port scans, banner grabs, crawling) sends packets to the target — richer, current data, but logged. OPSEC is minimizing and understanding those footprints. The ordering rule is passive first, then a small, scoped, paced active scan.

Key commands (lab-safe). whois <domain> and dig +short <domain> A behave as passive-style third-party lookups; nmap -sT -T2 -p <ports> 127.0.0.1 -oN file is a disciplined active scan of a host you own. Verify the distinction by tailing the target's log: silent during passive, populated during active.

Common mistakes. Calling a scan "passive"; jumping to a full-range scan first; treating passive as ethics/terms-free; scanning out of scope; assuming no alert means no log.

What to remember. Passive before active; only ever run active recon on systems you own or are authorized to test; log your own activity (timestamp, source, resource, result, decision, correlation id) and never log secrets; and remember that decoding public data or passing a scanner clean never proves a system is secure — nothing is ever completely secure.