Skip to main content
← ArticlesLire en français
15 March 2026·Alien6 Research

Technical OSINT: Mapping Attack Surfaces

Passive and active reconnaissance techniques for mapping your own attack surface and identifying exposure vectors.

SécuritéOSINTThreat Intelligence

Technical OSINT: Mapping Attack Surfaces

Ethical and legal framework: the techniques described in this article distinguish two categories. Passive reconnaissance (consulting public data without interacting with the target) is legal in the vast majority of jurisdictions. Active reconnaissance (port scanning, direct DNS brute-force) requires explicit authorization from the system owner. The defensive section of this article applies exclusively to self-inventory of your own exposure surface — it must never be applied to third-party systems without a written mandate.

Before sending a single packet on a target network, a competent attacker spends hours — sometimes weeks — in passive reconnaissance. This phase generates no traces in the target's logs. Yet it produces a precise map of the attack surface: domains, subdomains, exposed technologies, leaked credentials, employees and their access.

Understanding this methodology is essential for reducing your own attack surface.

Passive Reconnaissance: No Interaction with the Target

Passive reconnaissance involves collecting publicly available information without ever directly interacting with target systems. Without direct interaction with the target, this phase generally generates no logs on the target side — intermediary services (WHOIS, CT logs, search engines) do however retain query traces.

Primary sources:

  • Public and historical DNS registries
  • TLS certificate transparency logs
  • Exposed surface search engines (Shodan, Censys, FOFA)
  • WHOIS and RDAP registries
  • Public code repositories (GitHub, GitLab, Bitbucket)
  • Web archives (Wayback Machine, CommonCrawl)
  • Professional social networks (LinkedIn for mapping teams and technologies)

DNS Enumeration: Far More Than A Records

A DNS record is a public statement of intent. Aggregating a domain's records reveals the complete architecture of an organization.

# Passive enumeration via third-party sources (CT logs, passive DNS, public APIs)
# No direct interaction with target.com
amass enum -passive -d target.com -o subdomains.txt
 
# Certificate Transparency to find all certified subdomains
curl "https://crt.sh/?q=%.target.com&output=json" | \
  jq '.[].name_value' | sort -u
 
# DNS over HTTPS — bypasses local blocking
curl "https://dns.google/resolve?name=_dmarc.target.com&type=TXT"

MX records reveal the email provider (Google Workspace, O365, Proofpoint). TXT records expose DMARC, SPF policies, and sometimes validation keys for third-party services. CNAMEs point to cloud services that may be takeover-able if misconfigured.

Certificate Transparency Logs

Since 2018, every TLS certificate issued by a trusted CA is recorded in public logs. These logs are irreversible and publicly queryable.

# Via crt.sh — all certificates for a domain
https://crt.sh/?q=target.com
 
# Via Censys — advanced search with filters
https://search.censys.io/certificates?q=parsed.names%3Atarget.com

An attacker can thus find internal subdomains exposed on the internet, development/staging environments, and integrated third-party services — before scanning anything at all.

Shodan and Censys: The Continuously Scanned Internet

Shodan continuously indexes all ports and services exposed on the internet. A search takes two seconds and returns results that required weeks of active scanning in the 2000s.

# Useful Shodan queries for reconnaissance
org:"Target Company" port:22          # Exposed SSH
org:"Target Company" http.title:"GitLab"  # Internally exposed GitLab
ssl.cert.subject.cn:"*.target.com"   # All wildcard certs

Exposed information: service versions (and therefore applicable CVEs), application banners, unchanged default configurations, public administration interfaces.

GitHub Dorking: The Unlocked Safe

Developers regularly commit secrets: API keys, database credentials, OAuth tokens, SSH private keys. GitHub Search allows finding these leaks with precise queries.

# GitHub Dork searches
org:target-company "api_key" OR "secret_key" OR "password"
org:target-company filename:.env
org:target-company "AWS_ACCESS_KEY_ID"
org:target-company "-----BEGIN RSA PRIVATE KEY-----"

Even after deletion, commits remain accessible via Git history. Rotating leaked credentials is urgent but insufficient without rotating all active secrets.

Reducing Your Own Attack Surface


Attack surface reduction checklist

  • DNS: remove obsolete records (subdomains of finished projects, orphan CNAMEs)
  • Certificates: audit via crt.sh, revoke certificates issued for non-production environments
  • Exposed services: scan your own perimeter with Shodan org: regularly
  • GitHub: enable native secret scanning, configure push protection rules
  • Employee OSINT: check what LinkedIn reveals about your technical stack
  • Wayback Machine: search for archived versions exposing old endpoints
  • Emails: DMARC policy in reject mode, strict SPF, DKIM configured
  • Subdomains: complete inventory with active CNAME verification
  • Leaked credentials: monitor Have I Been Pwned Enterprise for corporate emails
  • Cloud registries: ensure private container registries are not publicly enumerable

An organization's attack surface is not defined by what it knows it exposes — it is defined by what an attacker can find. These two sets never fully overlap. Regular OSINT on your own organization is the only way to close the gap.