Subfinder returns 1,247 subdomains in 19 minutes. Amass adds 340 more from passive sources. The pentest report covers 12 of them.
That gap is where most critical bugs survive. Not because the team missed the assets, but because there was no layer to decide which ones to test first.
Recon produces lists. Practitioners who find critical vulnerabilities first treat those lists as input to a risk scoring layer, not as a final deliverable. The difference between an attack surface report and an actual attack map lives in that intermediate step: internet exposure, known CVE surface, and business criticality.
Recon Data Is Not Intelligence: The Volume Problem
Modern subdomain enumeration tools deliver impressive scale in minutes. Subfinder queries 103 passive sources simultaneously; Amass adds active brute-force enumeration over wordlists of one million entries. The problem that volume creates is a filtering problem.
The OWASP Attack Surface Management Top 10 places "unknown and unmanaged external assets" at the top of the risk list. Organizations frequently don't know the full extent of their own exposed surface. An annual pentest scoped to the main domain leaves the rest untouched.
The distinction that matters is between attack surface and exploitable surface. A list of 1,247 subdomains is an attack surface. Exploitable surface is the subset with active DNS, a stack with a public CVE and CVSS above 7.0, and a path that touches authentication or sensitive data. The gap between those two numbers is where tools stop and judgment begins.
Technical reports without business context are not actionable. A subdomain running Apache 2.4.49 with public exposure is priority zero: CVE-2021-41773 carries CVSS 9.8 and widely documented public exploits. A subdomain running Apache 2.4.53 on staging with no active DNS is a candidate for deprioritization. Risk scoring makes that distinction; the raw list does not.
Passive Discovery: Mapping Without Touching
Certificate Transparency logs are the most underrated resource for passive discovery. Every TLS certificate issued by a trusted CA appears in a public, immutable log within minutes of issuance. Before a new subdomain even has full DNS propagation, it is already visible in the CT history.
crt.sh exposes that history through a direct SQL API. A query for %.empresa.com returns every subdomain that has ever received a certificate, including admin panels provisioned once and never formally decommissioned. A certificate issued in 2019 for dev-api.empresa.com stays in the log even if the subdomain was later disabled.
Google and Bing surface accidentally indexed content through search operators. site:empresa.com filetype:env finds published .env files. inurl:empresa.com admin login finds panels exposed to crawlers. The OWASP WSTG operator collection covers 40 distinct search patterns for sensitive data indexed without intent.
Passive DNS databases like SecurityTrails and VirusTotal store resolution history for years. SecurityTrails /v1/domain/{domain}/subdomains returns up to 10,000 historical subdomains via API; VirusTotal /domains/{domain}/subdomains supplements that with resolution data from threat intelligence feeds. A corporate acquisition that brought in domains from a purchased company shows up in that history before any public announcement. WHOIS and RDAP expose ownership records that link seemingly independent domains to the same registrant.
Public repositories on GitHub and GitLab routinely expose internal hostnames, API tokens, and environment keys in commit history — the dork site:github.com 'company.com' 'password' is standard practice in passive reconnaissance.
The operational advantage of all these methods is zero interaction with the target infrastructure. No packets sent means no IDS alerts, no access logs, no anomalous monitoring window. The passive phase is where information asymmetry exists before any contact is made.
All of that data arrives as raw lists — the resulting volume is precisely what makes the scoring layer non-optional.
Stack Fingerprinting: Disclosed Versions as a CVE Shortlist
Every version string a server leaks is a direct lookup against CVE databases. Fingerprinting does not find vulnerabilities; it narrows the search space to confirmed candidates with documented exploits.
HTTP headers are the first signal layer. Server: Apache/2.4.49 identifies the exact version. X-Powered-By: PHP/8.0.1 does the same for the runtime. X-AspNet-Version: 4.0.30319 and X-AspNetMvc-Version: 5.2 reveal the full stack in two response lines. These headers are enabled by default in standard configurations and rarely disabled in production.
Session cookie names identify frameworks without any response body analysis. PHPSESSID indicates PHP; JSESSIONID indicates Java EE or Spring; ASP.NET_SessionId indicates .NET. Combined with the Set-Cookie header value, these names build a partial stack map without any vulnerability scanner.
Error pages are immediate visual signatures. Apache Tomcat's default 404 has specific HTML with the Jakarta logo. Spring Boot's 500 exposes "Whitelabel Error Page" by default through version 2.x. IIS 7.5 has an error page with a proprietary HTML structure. Any of these patterns connects the asset to a specific CVE history.
Default framework files frequently remain accessible. changelog.txt in WordPress exposes the exact version without authentication. composer.json in PHP applications lists dependencies with versions. package.json in Node.js applications does the same. These files are found through direct path guessing, no scanner required.
The intel.mago.team tech_detector automates the collection of these signals from a URL, without a browser extension, making the process scalable for mass enumeration pipelines. The output maps each detected signal to a stack profile that feeds the NVD query by version.
The operational chain is straightforward: disclosed version, NVD lookup by exact CPE, filter by CVSS greater than or equal to 7.0, filter by available public exploit. The asset that passes that filter is a priority test candidate before any manual analysis.
Subdomain Enumeration: The Perimeter Extends Beyond the Main Domain
Staging and development subdomains represent the most common class of forgotten assets. OWASP ASM Top 10 #7 catalogs "exposed debug and test environments" as a distinct risk because these instances exist on subdomains that never go through security review. dev-api.empresa.com, staging-admin.empresa.com, test.empresa.com: each tends to have weaker authentication, real data for environment validation, and no WAF in front.
CT logs cover historical subdomains that passive DNS databases may not have. The combination of crt.sh, SecurityTrails, and Subfinder maximizes coverage before any active contact with the target. OWASP Amass adds integration with threat intelligence APIs and pastebins to capture accidental references to internal subdomains.
Subdomain takeover is the direct risk from dangling CNAME records. A subdomain cdn.empresa.com with a CNAME pointing to a decommissioned cloud service can be claimed by an attacker who provisions the same URL on the target platform. The result is a legitimate company subdomain serving attacker-controlled content, with valid cookie scope on the parent domain. OWASP ASM Top 10 #8 documents this scenario as insecure DNS configuration.
Active brute-force enumeration over wordlists captures subdomains that never received a TLS certificate and do not appear in passive databases. Wordlists like those from SecLists cover common patterns: api, admin, dev, staging, beta, internal. The critical distinction is authorization: active enumeration sends DNS packets to the target's authoritative server and is only legal with an explicit pentest scope.
Each subdomain added to the list through this process strengthens the case for scoring before testing.
The Synthesis Layer: Scoring Findings Before Testing Them
Raw recon without scoring is output, not intelligence. The risk matrix operates on three factors: internet exposure, known CVE surface, and business criticality. Applying that matrix converts a subdomain list into an attack map with a defined test sequence.
Factor 1: Internet exposure. An asset counts as exposed when three conditions hold: it appears in CT logs or passive DNS, it resolves DNS at the time of assessment, and it has port 443 or 80 open. A historical subdomain in crt.sh with no active DNS resolution has low exposure; monitoring is worthwhile, but immediate test priority is not.
Factor 2: CVE surface. Stack fingerprinting produces a version tuple. That tuple goes to the NVD as a CPE query. The relevant filter is CVSS greater than or equal to 7.0 with a documented public exploit. EPSS (Exploit Prediction Scoring System) complements CVSS by estimating the actual probability of active exploitation within 30 days. A CVE with CVSS 9.8 and EPSS 0.02 is less urgent than one with CVSS 7.5 and EPSS 0.87.
Factor 3: Business criticality. Path analysis and form inspection identify what the asset processes. A login form indicates authentication. Credit card fields indicate a payment flow. user_id or account_id parameters in responses indicate personal data. An admin panel with HTTP Basic Auth on public exposure is maximum priority regardless of how uninteresting it appears.
Concrete example. Assess status.empresa.com discovered in CT logs. The subdomain resolves DNS; port 443 responds. The Server: nginx/1.14.0 header appears in the response. The NVD lists CVE-2019-9511 (HTTP/2 DoS, CVSS 7.5) and CVE-2019-9516 (CVSS 7.5) for that version. The /admin path returns HTTP 200 without authentication, with a visible login form. EPSS for CVE-2019-9511 is 0.94 in 30 days. Composite score: high exposure, CVE with elevated EPSS, exposed admin path. Result: immediate testing, ahead of any host in the main scope.
What gets deprioritized: historical subdomains in CT with no active DNS resolution; updated stacks with no public CVE with relevant EPSS; services with no confirmed internet exposure. The OWASP Relative Attack Surface Quotient weights attack points by access level, damage potential, and reproducibility — the result is a numerical metric comparable across assets (OWASP ASM).
Operationalizing: The Attack Surface Changes Every Day
A recon audit done today is a snapshot of yesterday's risk. TLS certificates are issued continuously. A new subdomain provisioned at 2:00 PM has its certificate in the CT log by 2:05 PM, before any human security review. Annual or monthly audit cadences cannot keep pace with that speed.
CT log streaming is the operational solution. Tools like certstream subscribe to logs from multiple CAs and deliver real-time events for monitored domains. A new certificate for *.empresa.com triggers an event; the pipeline runs fingerprinting, DNS check, and port scan automatically; the alert arrives with context before the subdomain is in full production.
Delta checking formalizes the process: for each newly discovered asset, the pipeline compares against the existing inventory, runs the full fingerprinting and CVE lookup chain, and ranks by risk score. Alerts with a configurable threshold ensure the team receives actionable context, not another raw log to interpret manually.
intel.mago.team provides continuous stack and subdomain monitoring, closing the gap between audit cycles. New assets enter the pipeline with automated fingerprinting and scoring, without requiring manual re-execution of every tool each week.
The attack surface is not a list to generate and file away. It is a living map that requires a scoring layer between raw discovery and actual testing. Built once, that layer makes any tool output immediately actionable.
Top comments (0)