---
{
  "title": "Reconnaissance",
  "summary": "Build a target model before choosing active assessment steps.",
  "topic": "offensive",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    5
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Technical Guide to Information Security Testing and Assessment",
      "url": "https://csrc.nist.gov/pubs/sp/800/115/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Reconnaissance gathers information relevant to a defined assessment or intelligence requirement. Passive methods use existing information; active methods interact with a target and need appropriate authorization. Record sources, timing, uncertainty, and the relationship to scope. Public names, certificates, and service information can suggest an attack surface, but they may be stale or represent third-party infrastructure. Validate important relationships before acting on them.

## In practice

An authorized tester reviews the organization’s official domain information and certificate records, then distinguishes owned resources from hosted or unrelated systems.

## A common misunderstanding

An address associated with a company name is not automatically in scope or controlled by that company.

## Check your understanding

Why separate passive and active activity?

**Think it through:** They have different effects and authorization requirements, and the distinction helps plan safe collection.

## Build a map with confidence levels

Reconnaissance is useful when observations become a defensible map of assets and relationships. A hostname, certificate entry, employee profile, and internet address are different kinds of evidence. None alone establishes current ownership or permission to test. Keep the original source and observation date so another analyst can evaluate the inference rather than inheriting an unexplained list of targets.

Suppose a fictional retailer has a certificate containing a staging hostname. That record suggests the name existed when the certificate was issued. It does not establish that the service is active today, that it contains production data, or that the retailer owns the underlying hosting platform. Those are separate hypotheses requiring suitable verification.

## Separate collection from interaction

Reviewing existing public records often avoids direct contact with the target service, but the distinction depends on the actual method. Visiting a website creates requests. Resolving names contacts infrastructure. A tool advertised as passive may combine public datasets with live checks. Understand what it sends before choosing it for an engagement with strict interaction limits.

Data quality matters as much as quantity. Shared hosting, acquisitions, outsourced support, and old branding can create misleading associations. Deduplicate observations without discarding provenance, and classify relationships as confirmed, probable, historical, or unresolved. A short verified inventory is more actionable than thousands of poorly attributed names.

## Connect findings to a purpose

Different questions require different collection. An exposure review might prioritize publicly reachable authentication interfaces. A phishing-resilience discussion may examine impersonation opportunities, while a defensive inventory project focuses on assets missing from ownership records. Avoid collecting personal information simply because it is available.

Try a documentation-only exercise using a fictional organization with three domains, one cloud provider, and an old acquisition. Draw the relationships, attach evidence to each edge, and identify which conclusions remain uncertain. Then mark the assets an engagement agreement actually authorizes. This makes the difference between information, attribution, and scope visible without interacting with anyone else's systems.

## Keep exploring

- [[osint]]
- [[attack-surface]]
- [[certificate-transparency]]
- [[rules-of-engagement]]