Reconnaissance scanning is the first step in external security testing. Before you dig into ports or vulnerabilities, you need a map of what is publicly visible, what belongs in scope, and which forgotten systems are still answering on the internet. For small teams, that map is often the highest-value part of the work. Not a dramatic exploit. Just a clear picture of what outsiders can see.
When to run it
Run recon when the answer will change what you do next. Common triggers:
- Before you start a new external testing program.
- After DNS, hosting, vendor, or infrastructure changes.
- Before port discovery, web discovery, TLS review, and vulnerability assessment.
- During vendor due diligence or when preparing a security questionnaire.
Recurring recon catches drift early. On-demand recon answers a specific question after a deployment, firewall change, certificate rotation, or remediation push. If you only run it after something breaks, you never build a baseline to compare against.
How it works
Start with authorized scope. Then collect what the public internet can already see, normalize it, and turn it into findings someone can own.
In PortWarden, recon sits at the front of a longer chain:
- Recon defines what exists.
- Port discovery shows what is reachable.
- Enumeration explains what is listening.
- Web discovery maps application paths.
- Vulnerability assessment looks for known weaknesses.
- Validation checks whether selected findings are real and whether fixes worked.
Which steps you run depends on the target and the question.
What it detects
- Public domains, subdomains, and hostnames tied to the organization.
- Internet-reachable hosts, web services, redirects, and edge systems.
- Stale test systems, old campaign microsites, vendor-hosted portals, and shadow IT.
- Technology fingerprints that help choose the next scan type.
- Scope changes after DNS, hosting, CDN, or infrastructure updates.
A bare finding is only somewhat useful. It gets better when you can say it is new, unexpected, externally reachable, and tied to a customer-facing asset with an owner.
What it misses
Recon is not architecture review, secure code review, incident response, or a human-led penetration test. Typical blind spots:
- Private internal systems that do not resolve or respond publicly.
- Assets behind strict allowlists or VPN-only access.
- Business logic flaws inside applications.
- Issues that need authentication or manual review.
Treat results as evidence, not prophecy. Review them, confirm impact, and decide whether to fix directly or dig deeper.
Example findings
- A forgotten staging hostname still resolving to a live web server.
- A vendor-managed login portal missing from the asset inventory.
- Old DNS records pointing at systems that should have been retired.
- Multiple public entry points with inconsistent naming and ownership.
Each finding should answer four questions: what was observed, where it was observed, why it matters, and what to do next. If it cannot, it may still be interesting, but it is not ready for operations yet.
False positives and noisy results
The internet is messy. Proxies, WAFs, shared hosting, cached DNS, version backports, redirects, and temporary deployments all distort what a scanner sees. For recon, common noise includes:
- Parked domains that look related but are not under your control.
- CDN, WAF, and shared hosting infrastructure that blur ownership signals.
- Historical DNS records that point at assets that no longer exist.
- Wildcard DNS that floods the list with candidate hostnames.
Do not throw the scanner away because of noise. Pair the output with change history, ownership, evidence, and validation. A noisy alert with no owner is anxiety. A finding with evidence, context, and a retest path is work you can finish.
How PortWarden uses it
PortWarden uses recon to build and refresh the public target map before deeper scans run. It helps decide which hosts go into port discovery, which web apps need crawling, and which endpoints deserve TLS or vulnerability review. It also gives operators a before-and-after view when infrastructure changes.
When automation is enough, move quickly. When judgment is needed, the evidence should make escalation cleaner.
Related scanners
- Port discovery scanning
- Web discovery scanning
- TLS configuration review
- Vulnerability assessment
These work better together than alone. One scan may identify the target, another may explain the service, and another may confirm whether the issue is real.
Remediation examples
- Remove stale DNS records, or point them at a controlled destination.
- Decommission forgotten staging systems, or put them behind authentication.
- Assign owners to public assets that currently have none.
- Update the approved monitoring scope so recurring scans cover the right systems.
Always verify. Close the port, remove the file, update the certificate, patch the service, or change the configuration, then scan again. An unverified fix is only a hope with a ticket number.