Footprinting, Reconnaissance and Attack-Surface Discovery — DedSec Project
Footprinting, Reconnaissance and Attack-Surface Discovery Reconnaissance is the process of building an accurate picture of an authorized target before deeper testing. Good reconnaissance is…
Reconnaissance is the process of building an accurate picture of an authorized target before deeper testing. Good reconnaissance is evidence-driven: it distinguishes information that is publicly observable from information obtained through direct interaction, and it records the source and confidence of each claim.
Authorized-use boundary: Passive research can still involve privacy, contractual, or policy constraints. Active discovery must remain inside the written assessment scope. Use
example.com, localhost, or a lab domain for exercises in this module.
Learning objectives
- distinguish passive, active, authenticated, and internal discovery;
- build an asset inventory from multiple evidence sources;
- understand DNS, certificate, registration, and web metadata;
- identify cloud, SaaS, repository, and identity exposure safely;
- track provenance and confidence for reconnaissance findings;
- turn reconnaissance into a prioritized attack-surface map.
Reconnaissance is an inventory problem
The goal is not to collect the largest number of names. The goal is to answer useful questions: Which assets belong to the organization? Which are Internet-facing? Which identities administer them? Which technologies and third-party dependencies are present? Which assets appear abandoned or inconsistently managed? Which observations are confirmed and which are only hypotheses?
Passive discovery
Passive sources do not require sending probes to the target service. Examples include:
- public DNS and certificate-transparency data;
- registration and autonomous-system information;
- public code repositories and package registries;
- organization websites, documentation, job postings, and status pages;
- vendor security advisories and public asset documentation;
- public cloud/SaaS references deliberately published by the owner.
Passive does not mean unrestricted. Avoid collecting unnecessary personal data and do not attempt to access private accounts or content.
DNS fundamentals for reconnaissance
Useful record types include:
- A / AAAA: IPv4 and IPv6 addresses;
- CNAME: alias to another hostname;
- MX: mail exchangers;
- NS: authoritative name servers;
- TXT: text records used by mechanisms such as SPF, DKIM, domain verification, and other services;
- CAA: certificate-authority authorization policy.
Safe local or documentation-oriented examples:
nslookup example.com
dig example.com A
dig example.com AAAA
dig example.com MX
A DNS answer is evidence about DNS state, not proof that a specific application, owner, or security control is present. Record resolver, timestamp, TTL, and whether the answer may be split-horizon or cached.
Certificate and TLS metadata
Certificates can reveal hostnames, issuing authorities, validity periods, and organizational deployment patterns. Certificate Transparency can help find publicly issued names, but a certificate entry does not prove that the hostname is currently reachable or still owned by the same team.
Web metadata
For an authorized web property, useful read-only observations include:
- response status and redirect chain;
- TLS configuration and certificate metadata;
- security headers;
- server or framework hints that are intentionally exposed;
robots.txt,security.txt, and public sitemaps;- documented API endpoints and public OpenAPI descriptions;
- public JavaScript bundle names and source-map exposure.
Do not turn a reconnaissance exercise into uncontrolled content brute forcing. If directory enumeration is in scope, perform it against a deliberately vulnerable or locally hosted training application with an agreed request rate.
Repository and package exposure
Public repositories can reveal architecture, dependencies, historical filenames, issue discussions, CI configuration, and accidentally committed secrets. Never assume a string that looks like a credential is safe to test. Report suspected secrets through the agreed channel and allow the owner to rotate them.
For dependency research, distinguish:
- direct dependency versus transitive dependency;
- declared version versus actually deployed version;
- package name similarity versus verified package identity;
- public vulnerability match versus reachable vulnerable code path.
Cloud and SaaS attack surface
Organizations may expose cloud load balancers, object-storage endpoints, identity-provider domains, SaaS tenants, support portals, and development platforms. A hostname pattern is not sufficient evidence of ownership. Confirm through approved inventories, DNS relationships, certificate data, or customer-provided context.
Provenance and confidence
For every discovered asset, record:
| Field | Example |
|---|---|
| Asset | portal.lab.example |
| Source | DNS / certificate / owner inventory |
| First seen | timestamp |
| Confidence | confirmed / probable / unconfirmed |
| Environment | production / staging / unknown |
| Owner | team or system owner if known |
| Exposure | public / internal / unknown |
| Next validation | minimal authorized test |
This prevents a common failure: treating stale search-engine or certificate data as current truth.
Active reconnaissance in a lab
Active reconnaissance directly interacts with a system. Examples include resolving a hostname, making a normal HTTP request, checking a small approved port list, or retrieving a service banner. Keep the rate bounded and document exactly what was sent.
A safe local exercise can use Python's HTTP server:
mkdir -p ~/hgp-lab/recon && cd ~/hgp-lab/recon
printf 'lab page\n' > index.html
python -m http.server 8000 --bind 127.0.0.1
In another Termux session:
curl -I http://127.0.0.1:8000/
Stop the server when finished.
Turning findings into an attack-surface map
Group assets by trust boundary rather than only by hostname. Useful groups include Internet edge, identity, email, source control, CI/CD, cloud control plane, APIs, remote access, mobile backends, third-party integrations, and monitoring/recovery systems.
Prioritize assets that combine high authority, sensitive data, broad exposure, weak ownership, or weak observability.
Common mistakes
- Copying old command examples against public domains.
- Equating a discovered hostname with an in-scope asset.
- Treating a technology fingerprint as a confirmed vulnerable version.
- Collecting personal data that is irrelevant to the security objective.
- Ignoring IPv6, alternate domains, or third-party identity surfaces.
- Failing to timestamp findings that can change quickly.
Safe lab
Build an attack-surface worksheet for a fictional organization with five assets: website, API, identity provider, code repository, and cloud account. For each, record trust boundary, owner, evidence source, likely sensitive data, and one minimal validation step.
Knowledge check
- Why is provenance important in OSINT?
- What is the difference between passive and active reconnaissance?
- Why can certificate data become stale?
- What would make a repository finding high priority?
- How do you avoid treating search results as proof of ownership?
Guided study workflow
Use the shared Study Method. Complete the attack-surface worksheet before moving to active scanning.
Continue with
Recommended next modules: 03, 34, 35, 43.