Recon Workflow with Nmap, Shodan, and Maltego for Authorized Security Assessments

The finding that ends up on the front page of the report is usually something the client did not know they owned. A staging environment from a project that shipped two years ago. A subdomain pointing at a cloud bucket somebody deleted. A management interface on a box the team who built it has since left. None of that comes out of an exploit — it comes out of recon, and specifically out of recon that reconciles what the client thinks their perimeter is against what the internet says it is.

Which is why rushing this phase costs more than it saves. Bad recon produces two failure modes and you rarely notice which one you are in: you miss exposed surface entirely, or you spend three days validating hosts that were decommissioned last quarter and write them up anyway. The second is worse, because it reaches the client, and a report containing a “critical exposure” on a server that no longer exists costs you the credibility you need for the findings that are real.

This guide sets out a phased workflow built around three tools that show up in most professional assessments: Nmap, Shodan, and Maltego. All of it assumes authorised work — a signed scope, a named contact, and a written boundary you can point at.

The Phased Reconnaissance Methodology

The phases exist to control one variable: how much you have touched the target. Passive work leaves no trace on the client’s infrastructure. Active scanning does, and that trace goes into logs, alerts, and — occasionally — a call from someone’s SOC at eleven at night. Sequencing passive before active means that by the time you start sending packets, you know which addresses are worth sending them to and which belong to somebody else entirely.

There is a secondary benefit that matters more than it sounds. If the client’s blue team catches your Nmap scan, that is a finding worth having. If they catch it before you have finished passive discovery, you have burnt the element of surprise for nothing.

The Three-Tiered Recon Model

Be precise about what “passive” means, because the word is used loosely and the distinction is legal, not stylistic. Querying crt.sh is passive: you are reading a public log. Resolving a hostname is not strictly passive — it puts a query into a resolver, and against a target running its own authoritative DNS, into their logs. Shodan sits in between: you contact Shodan, Shodan contacted the target weeks ago. Know which side of that line each of your tools sits on before you claim “passive only” to a client.

[!IMPORTANT] If your client’s rules of engagement restrict you to passive recon, stop at the end of phase two. Active validation — including Nmap scans and active DNS probes — requires explicit, written authorisation. When in doubt, ask rather than assume.

Establishing Scope Boundaries & Rules of Engagement

The mistakes that end careers here are not technical. They are scoping errors: an IP resolved from a client hostname that turns out to be shared hosting, a CDN edge node serving a thousand other customers, or a SaaS tenant the client uses but does not own. Your authorisation covers the client’s systems. It does not cover the third party whose infrastructure the client’s DNS happens to point at, and “the client told me it was theirs” is a weak position to be arguing from afterwards.

Cloud makes this sharper. An elastic IP the client held last month may belong to another tenant today, and scanning it is scanning a stranger. Verify ownership at the time you scan, not at the time the scope document was written.

Get the boundaries in writing before anything runs.

Scope Control Checklist

• Approved target domains, subdomains, and IP ranges
• Explicit exclusions (partner organisations, third-party SaaS, CDN-owned infrastructure)
• Approved active methods — service discovery, version fingerprinting, timing limits
• Authorised test windows and escalation contacts
• Data handling constraints — retention policy, redaction requirements, sharing rules
• Rules specific to cloud-hosted and multi-tenant infrastructure
• Stop conditions for instability or legal ambiguity

Two additions worth insisting on, because their absence is what turns a bad afternoon into a dispute. First, the source addresses you will scan from, given to the client in advance — so that when their SOC sees the traffic, someone can check a list instead of declaring an incident. Second, a named person with authority to say “stop” and a number that is answered out of hours. A scope document nobody can act on at 2 a.m. is a scope document you do not have.

Rules-of-Engagement (RoE) Matrix

Stage 1: Asset Intake and Source-of-Truth Setup

Start with the client’s own documentation, not with a scanner. Not because the documentation is accurate — it will not be — but because the gap between it and reality is itself the finding. A CMDB that lists forty external hosts, next to a discovery run that surfaces sixty, tells you something about the organisation’s change control that no individual vulnerability does.

Ask for the messy sources too: the old pentest reports, the DNS zone file, the list of cloud accounts including the ones marked “legacy, do not use”. The asset nobody wants to talk about is reliably the one running an unpatched application on a forgotten subdomain.

Core Intake Sources

• CMDB or service registry exports
• Known domains, brands, and business units
• Cloud account and project naming patterns
• Existing DNS zone records and delegated subzones
• Previous pentest and vulnerability reports

Building Your Working Inventory

One inventory, one place, from the first hour. The alternative — six tool outputs in six formats in a directory — feels faster for a day and then costs you the entire final afternoon when you have to reconcile them under deadline. A spreadsheet is fine. What matters is that every asset carries the fields below, and that confidence and validation status are recorded per asset rather than held in your head:

• Asset identifier (domain, hostname, IP, application name)
• Claimed owner team
• Business criticality
• Exposure type (public / internal / hybrid)
• Confidence score (starts low, increases with validation)
• Validation status (unvalidated / validated / rejected)
• Timestamp and source for every claim

That last field is the one people leave out and regret. Six weeks later, when a client disputes a finding, “Shodan said so” is not an answer. “Shodan, queried 14:22 on the 3rd, banner recorded, re-validated by scoped scan on the 5th” is.

Stage 2: Domain and Subdomain Discovery

Cast wide, then cut hard. Passive enumeration will hand you thousands of candidate names, and the overwhelming majority are noise: names that never resolved, names from a hosting provider’s shared certificate, names belonging to a company with a similar brand. The value is not in the size of the list. It is in what survives resolution and ownership checks.

The Subdomain Discovery Process

1. Enumerate root domains from scope documents.
2. Collect subdomain candidates from passive discovery tools and certificate transparency logs.
3. Normalise the results — remove duplicates, fix typos, strip stale aliases.
4. Resolve DNS and capture A, AAAA, and CNAME records.
5. Flag unresolved or parked records separately for follow-up.

Practical Tooling and Command Examples

• Subfinder (ProjectDiscovery): Fast, queries multiple passive APIs simultaneously.

  subfinder -d example.com -all -silent -o subdomains.txt
  

  -all queries every configured source; -silent strips the banner so the output pipes cleanly. Worth knowing: most of those sources need API keys in provider-config.yaml, and without them Subfinder runs anyway, quietly using a fraction of its sources. No warning, just a shorter list. If your results look thin, check the config before you conclude the target has a small footprint.

• OWASP Amass (v4): Slower than Subfinder and better at a different job — it keeps a local graph database, so results accumulate across runs and you can ask how a host relates to a netblock rather than just whether a name exists. Note the -passive flag below is doing real work: without it, Amass will resolve and probe, which is no longer passive and may exceed what you have been authorised to do.

  amass enum -passive -d example.com -o amass_subs.txt
  

• crt.sh (Certificate Transparency): Since browsers began requiring CT logging, every publicly trusted certificate is a matter of public record — which means issuing a certificate for jenkins-internal.example.com publishes that hostname to the world. This is the single richest passive source, and the one that most reliably surprises clients who assumed an internal-only name was private.

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

[!TIP] Combine the outputs, sort -u, and load the result into your inventory before doing anything else with it. Keep the per-tool files as well: knowing that a hostname came only from certificate logs and never from DNS is a meaningful signal, and it is destroyed the moment you merge everything into one anonymous list.

Stage 3: Certificate and DNS Review

Certificates and DNS records are the two places where an organisation’s history is written down whether it likes it or not. Certificates expire but the log entry is permanent; DNS records outlive the resources they point at by years. Both are read-only, both are free, and between them they account for a disproportionate share of the genuinely severe findings in external assessments.

Certificate Audits

• SAN Entries: Subject Alternative Names group related subdomains in a single certificate. An admin.example.com or dev.example.com SAN entry on a production certificate is worth investigating.
• Environment Keywords: Scan hostnames for terms like temp, old, dev, stage, corp, backup, or legacy. These often point to forgotten infrastructure running on outdated software.
• Unexpected Certificate Authorities: A production domain using Let’s Encrypt while the rest of the enterprise uses a corporate CA can indicate shadow IT — services spun up outside the normal change management process.

DNS Records Analysis

• CNAME Redirection: A CNAME pointing at a deleted S3 bucket, a decommissioned GitHub Pages site, or a dead Heroku app is a candidate for subdomain takeover — anyone can register the now-free resource name and start serving content from the client’s own hostname. That is not a defacement problem. It is a hostname inside the client’s domain, with a valid certificate they will happily issue, capable of receiving cookies scoped to the parent domain and of passing any “is this really them?” check a user might make. Prove it with a harmless marker file and nothing else; actually claiming the resource is a decision to take with the client, in writing.
• Parked IPs: Domains pointing to registrar placeholder pages or known parking IPs are likely stale but worth confirming.
• Split-Brain DNS: Compare internal and external resolution for the same hostname. A domain resolving to a private RFC 1918 address externally reveals internal naming conventions that are useful to an attacker.

DNS/Certificate Signal Reference Table

Stage 4: Shodan Enrichment and Exposure Context

Shodan scans the public IPv4 space continuously and keeps what it finds: banners, open ports, TLS certificates, protocol metadata. You get a view of the target’s exposure without a packet leaving your machine, which is exactly what you want at this stage.

Two limits to hold in mind. The data is cached, so a Shodan result describes the address as it was when Shodan last visited — possibly weeks ago. And the coverage is uneven: Shodan scans a large set of ports, not all 65,535, on a rotating schedule, so absence of a service in Shodan is not evidence the service is absent. This is a prioritisation signal and a source of leads. It is not ground truth, and reporting a Shodan banner as a confirmed finding is how you end up describing a vulnerability that was patched a month ago.

Key Enrichment Steps

• Identify likely internet-facing services tied to candidate assets
• Capture observed service banners and protocol metadata
• Prioritise which systems are most worth spending active validation time on

Practical Shodan CLI Examples

Install the CLI and initialise it with your API key first. Note that org: filters rely on WHOIS and BGP registration data, which lags reality badly — an organisation that has migrated to a cloud provider will show almost nothing under its own name, because the addresses now register to AWS or Azure. Search by certificate subject and by known IP ranges as well, or you will conclude a large target has no perimeter.

# Detailed host profile for a target IP
shodan host 198.51.100.42

# Find exposed management interfaces within a target organization
shodan search "org:'Example Corp' port:3389,22,443"

[!WARNING] Always record the timestamp of your Shodan query. When Shodan shows a port open and your scan finds it closed, resist the urge to delete the row — that divergence is itself worth reporting. It usually means the exposure was real and has since been closed, which tells the client their perimeter changes without anyone tracking it. Occasionally it means the service is filtered from your source address but not from everyone’s, which is a very different and more interesting problem.

Stage 5: Maltego Graphing for Infrastructure Relationships

A spreadsheet answers “what do we have”. It is poor at answering “what is connected to what”, and by the time you are holding two hundred hostnames across nine netblocks and four providers, that second question is the one that matters. Maltego draws the relationships — domain to host to IP to netblock to autonomous system — so that clusters become visible.

A caveat, since Maltego attracts more enthusiasm than it always earns: the graph is a thinking tool, not a deliverable. A dense hairball screenshot in a report communicates nothing. Use it to spot the structure, then write down in words what you found, and export only the small, annotated subgraph that supports the point.

Mapping Workflow

1. Seed the graph with approved root domains and known organisations.
2. Add discovered hostnames, certificate entities, and IP address relationships.
3. Group nodes by business unit, environment, and service owner.
4. Mark uncertain nodes for manual validation.
5. Export graph snapshots with date, time, and analyst annotations.

Where the graph earns its place is shadow IT. A team spins up something in a personal cloud account, points a company subdomain at it, and never tells anyone; the host has no ticket, no owner in the CMDB, and no monitoring — but it is still tied back to the organisation through DNS or a shared certificate, and on a graph that link is obvious in a way it never is in a list. These assets live precisely in the gap between what the client believes its external footprint is and what it actually is, and that gap is usually where the assessment’s best finding is waiting.

Be careful with transforms while you work. Several of them are active — they resolve, they fetch, they contact hosts — and clicking one on a node that turns out to be a third party’s infrastructure is an out-of-scope action you took by accident. Know which transforms in your set touch the target before you run them across a graph.

Stage 6: Technology Fingerprinting & Service Hypotheses

Write down what you expect to find before you scan. This sounds like process overhead and is in fact the cheapest quality control available: a hypothesis you record can be wrong in an obvious way, whereas a vague expectation adjusts itself silently to whatever the scanner returns. If you predicted a managed API gateway and the banner says IIS 8.5, that mismatch is a lead. Without the prediction, you would have noted the banner and moved on.

Fingerprinting feeds those hypotheses from material you already have — response headers, cookie names, error page markup, certificate issuers, favicon hashes — with no active probing needed. It also tells you what intensity of scan the target can tolerate, which is how you avoid running a fast, loud profile at a fragile appliance and spending the rest of the day explaining yourself.

Example Hypotheses

• Hypothesis 1: “The hostname api.example.com likely points to a cloud-managed API gateway with strict rate-limiting — standard service discovery scan, then manual API enumeration.”
• Hypothesis 2: “The IP 198.51.100.12 appears to host a legacy admin panel behind Cloudflare — passive header analysis first, then cautious targeted probing.”
• Hypothesis 3: “The subdomain dev-web.internal.example.com resolves only to RFC 1918 addresses — this is VPN-only, so schedule testing for after internal access is confirmed.”

Stage 7: Authorized Nmap Validation

This is the first point at which packets from you reach the client. Everything before it was reading public records; from here on you are generating log entries, possibly alerts, and — on a badly chosen target — load.

The load risk is not hypothetical and is not evenly distributed. Modern web infrastructure shrugs off a port scan. Printers, industrial controllers, medical devices, elderly appliances and anything with an embedded TCP/IP stack from the 2000s sometimes do not; a full-port scan with version detection is a known way to hang them. If the client’s estate includes OT or embedded devices, that belongs in the rules of engagement as an explicit exclusion, not as something you find out about afterwards.

Every scan should be deliberate, rate-limited, and recorded well enough that you could reproduce it from your notes a year later.

Scanning Best Practices

• Strict Scope Controls: Cross-check your target list against the approved CIDR ranges and exclusion files before every scan run.
• Conservative Rates: Limit scan speed to protect low-capacity networks and avoid triggering rate-limit blocks or intrusion detection rules.
• Detailed Scan Logs: The exact command, the target list, start and end times, and the source address. This exists for the day something on the client’s network falls over during your test window and someone asks whether it was you. With a log you can answer in minutes. Without one you are arguing from memory against an outage, and you will lose.

Safe Nmap Command Examples

• Fast, Non-Intrusive Discovery:

  nmap -sV -Pn --top-ports 100 --max-rate 50 -oA top_100_scan 198.51.100.0/24
  

• Targeted Service Banner Grabbing:

  nmap -sV -sC -p 22,80,443,8080 --script=banner --max-rate 50 -oA banner_grab 198.51.100.42
  

Parameter breakdown:

• -sV: Service and version detection. This is what makes the output worth having, and also what makes it intrusive — Nmap completes connections and sends probe strings to elicit a response, rather than just observing that a port is open.
• -Pn: Skips host discovery and treats every address as live. Necessary when ICMP is filtered, which is most of the internet, but understand the cost: on a large range Nmap will now scan every address in it whether or not anything is there, multiplying your scan time and your traffic.
• -sC: Runs the default NSE category. “Default” is not a synonym for “harmless” — the category includes scripts that authenticate, enumerate, and in a few cases write. Read what a script does before pointing it at production.
• --max-rate 50: Caps output at 50 packets per second. Slow by design: low enough to stay under most rate-limit and IDS thresholds, and low enough that a /24 across the top 100 ports takes real time. Budget for it rather than raising the rate on the day.
• -oA: Writes normal, XML, and grepable output together. Do this always. The XML is what feeds your parsing and your evidence table, and re-running a scan because you forgot to save it is both wasted hours and a second round of traffic at the client.

Validation Outcomes

Recon Evidence Table for Reporting

Keep this table current as you go, not as a reconstruction on the last day. The distinguishing feature of a good one is that every row carries a confidence level and a source, so the person writing the report can tell which claims are verified and which are leads — a distinction that vanishes entirely once findings are flattened into prose.

Avoiding False Positives and Stale Recon Noise

A recon report’s credibility is set by its worst row, not its best. Clients read the finding they can disprove first — the “exposed admin panel” that turns out to be a decommissioned host, the “critical service” running on a CDN address shared with four hundred other companies — and having disproved it, they discount everything else you wrote. Filtering noise is not tidying. It is the thing that makes the rest of the document worth reading.

• Verify Current Resolution: Never report a subdomain as vulnerable without confirming it currently resolves to a live IP. A hostname that pointed somewhere dangerous six months ago might resolve to nothing today.
• Cross-Reference with CMDB: Discovered assets might be legacy servers already decommissioned from the client’s perspective. Check before flagging.
• Check Data Freshness: If a Shodan finding is months old, treat it as a lead to verify, not a confirmed exposure. Always note the query timestamp in your evidence.
• Be Careful with Shared IPs: Cloudflare, Akamai and Fastly serve thousands of customers from the same addresses. Scanning one is scanning all of them, which is both out of scope and, depending on jurisdiction, unlawful. It also produces findings about the CDN’s configuration rather than the client’s, which is the technical version of the same mistake: a TLS setting you report belongs to the edge, not to the origin the client controls.

Downstream Security Value

Recon is the phase clients least want to pay for, because nothing visible happens during it. The argument for the time is that every hour here removes several later: testers who know which host is production and who owns it do not spend the second week finding out.

1. Web and API Penetration Testing

• Surfaces critical API endpoints, administrative panels, and staging environments that automated scanners miss.
• Maps authentication flows and environment boundaries before active vulnerability testing begins.
• Focuses manual testing effort on high-value targets instead of dead links and placeholder pages.

2. Vulnerability Management

• Maps vulnerabilities directly to owner teams, accelerating time-to-remediation.
• Adds context — exposure level, business criticality, environment type — that helps prioritise patching schedules meaningfully.

3. Red Teaming and Threat Simulation

• Reveals the true external attack surface and perimeter trust boundaries as seen from the outside.
• Provides realistic entry points for approved adversary simulation scenarios.
• Establishes a baseline map of external exposure that defenders can use for comparison.

Common Reconnaissance Pitfalls

• Scanning outside scope because ownership was assumed rather than verified
• Treating Shodan output as definitive without active confirmation
• Ignoring cloud resource and DNS context behind a simple hostname list
• Mixing third-party assets into first-party risk statements
• Running active validation before the rules of engagement are finalised and signed
• Failing to record evidence timestamps and analyst decision notes alongside findings

Repeatable Assessment Checklist

Recon Governance & Program Worksheet

Evidence Handoff Package Standards

Whoever picks this up next — an application tester, a red team, the client’s own remediation staff — needs to know not just what you found but how much to trust each item. A package that omits the uncertainty gets treated as either wholly authoritative or wholly unreliable, and both are wrong. Include:

• Asset inventory: Hostname or IP, environment estimate (prod/stage/dev), owner, confidence level, recency.
• Exposure summary: What is externally reachable, why it matters, and what remains unverified.
• Validation log: When and where active checks ran, the scope reference used, and the result.
• Open questions list: Ambiguous ownership, suspected third-party assets, and items requiring confirmation.

Confidence Labeling Standards

• High: Verified by two independent passive sources and confirmed via scoped active probe.
• Medium: Discovered via two independent sources, but active verification has not been performed.
• Low: Single passive source or stale/cached dataset. Must be marked “Unverified.”

Recency Requirements

• External Caches (Shodan): Mark as “Historical” unless queried within 48 hours of handoff.
• DNS Records: Record the exact lookup timestamp and the resolver IP used.
• High-Risk Claims: Any service flagged as a critical exposure must be actively validated within 24 hours of report generation.

90-Day Recon Capability Maturity Plan

Days 1–30: Foundation

• Establish standard templates for inventories and evidence tables. Boring, and the single highest-return item on this list — most recon inconsistency is format inconsistency.
• Run one baseline cycle across the primary corporate domains and keep the output. Everything afterwards is measured as a delta against it.
• Document the false-positive sources specific to your environment. Every estate has its own: a CDN that always looks unpatched, a legacy zone full of names that never resolved, a partner whose addresses sit inside your netblock.

Days 31–60: Integration

• Build automated DNS checks to flag stale CNAMEs on a weekly cadence.
• Integrate recon outputs into the standard pentest planning pipeline.
• Begin tracking asset ownership identification times as a metric.

Days 61–90: Optimization

• Schedule recurring recon against your deployment cadence. New releases create new endpoints, and the window between an endpoint appearing and anyone noticing is exactly the window an attacker uses.
• Publish the metrics to leadership. Perimeter growth is a number executives understand, and it funds the programme in a way finding counts never do.
• Tighten the handoff rules until downstream teams stop re-validating what you send them. If they still check your work, the handoff has not landed, whatever the process document says.

One caution about automating all of this: a scheduled job that discovers thirty new assets a week produces a queue nobody works. Automate discovery only as fast as you can absorb the output, or you will have swapped an unknown perimeter for a known and permanently ignored one.

Core Metrics to Track

None of this makes recon glamorous. It is list management with a legal boundary attached, and the skill being developed is mostly the discipline to record where a claim came from and how old it is. What that buys is the ability to say, of any line in your report, exactly how you know it — and that is the difference between a document a client acts on and one they file.

The compounding is real, though. The second engagement is faster than the first because the templates exist; the fifth is faster still because you have learnt which sources lie to you and in which direction.