The most dangerous assets in an organization's perimeter are often the ones its security team does not know exist. Staging environments left running after a product launch. API subdomains created for a third-party integration that was decommissioned without removing the DNS record. Admin panels reachable via a non-obvious subdomain. Development servers that were promoted to production connectivity without going through the hardening process. DDactic consistently finds these assets in assessments, and they consistently have weaker defenses than the main production surface.
The subdomain discovery methodology is DDactic's Stage 1: before any vulnerability check, the scan engine builds the most complete possible picture of what an organization exposes. The methodology uses six data sources in combination, because no single source provides complete coverage.
Source 1: Certificate Transparency Logs
Certificate transparency (CT) logs are public records of every TLS certificate issued for a domain. They are searchable via APIs like crt.sh and Censys. A CT log query for %.example.com returns every subdomain for which a certificate has been issued -- including staging environments (which need HTTPS), internal tools (which may have been briefly internet-accessible), and old domains that are no longer in use but still resolve. CT logs are the most reliable single source because certificate issuance is mandatory for public HTTPS and the logs are append-only, preserving historical records. The limitation is lag: certificates issued via private CA (internal PKI) do not appear in public CT logs.
Source 2: Passive DNS
Passive DNS databases collect historical DNS resolution records from recursive resolvers. A passive DNS query for *.example.com returns subdomains that were resolving at some point in the last several years, even if their DNS records have since been removed. This catches assets that were decommissioned at the DNS level but are still accessible at the IP level (because the server was not shut down when the DNS record was removed). Passive DNS is the primary source for detecting dangling DNS entries -- subdomains pointing to decommissioned third-party services where the domain can be taken over.
Source 3: ASN-Based IP Enumeration
Organizations own IP address ranges registered to their ASN. Reverse DNS lookup on all IPs in an organization's ASN reveals subdomains that are not listed in public-facing DNS zones. This is particularly effective for finding internal services that are reachable from the internet because of overly permissive firewall rules, even though they are not intended to be public. The DDactic scan engine queries ARIN, RIPE, and APNIC to identify all IP blocks attributed to the organization's ASN, then performs reverse DNS on each.
Source 4: Brute-Force with Wordlists
Wordlist-based brute force queries common subdomain patterns against the target domain's authoritative DNS servers. Effective wordlists include common infrastructure patterns (api, staging, dev, test, admin, portal, vpn, mail) and organization-specific patterns derived from the organization's known product names and services. The DDactic wordlist is approximately 100,000 entries, with the top 5,000 accounting for the vast majority of findings in practice. This source is most effective for finding assets that have never appeared in CT logs or passive DNS because they were created recently or use private CAs.
Source 5: Permutation and Alteration
Permutation generates candidate subdomains by altering known subdomains: replacing numbers (api1.example.com suggests api2.example.com), substituting synonyms (staging suggests stage, uat, preprod), and prepending or appending common prefixes and suffixes. This source is particularly effective at finding undocumented environments related to a discovered asset.
Source 6: Third-Party Data Sources
Shodan, Censys, and VirusTotal maintain their own subdomain datasets derived from internet scanning and web crawling. These catch assets that are not covered by CT logs (internal CA) or passive DNS (low-traffic assets that appear rarely in recursive resolver logs) but are directly accessible from the internet. Cross-referencing across all six sources, with DNS resolution to confirm which candidates are live, produces the most complete subdomain inventory achievable without internal network access.
Forgotten subdomains are not low-priority findings
A development environment with no WAF, no rate limits, and default server timeouts that shares the production database is a critical finding, not a cosmetic one. The priority of a forgotten subdomain finding depends on what the subdomain exposes, not on the fact that it was forgotten.
Map Your Complete Attack Surface
DDactic's discovery stage runs all six subdomain enumeration methods and reports every live host, including the ones you did not know were there.
Run a Free Scan