A subdomain is anything to the left of the main (apex) domain. example.com is the apex; www.example.com, api.example.com, mail.example.com and shop.example.com are subdomains. Each can point to a completely different server, in a different city, run by a different team, with a different security posture. From a single apex you can build an entire ecosystem of services on names that humans can remember.

Subdomains are created by adding DNS records — usually A, AAAA or CNAME — under the apex zone. There is no theoretical limit on how many you can have, and large organisations easily reach hundreds. Cloudflare publishes subdomain counts in the millions for some of its largest customers; even small Pakistani companies regularly have 20–50.

From a security perspective, every subdomain is its own door. A perfectly hardened www can sit beside a forgotten dev-2019 that still serves yesterday’s code with last year’s vulnerabilities. Subdomain enumeration is the process of finding every door so they can each be checked, secured or retired.

You cannot defend what you do not know exists. Most large breaches in the past decade started not at the front door but at a forgotten side door — a deprecated staging server, a marketing campaign microsite, a vendor portal nobody owned anymore. Subdomain enumeration is how you find those doors before someone else does.

The discipline of doing this systematically is called Attack Surface Management (ASM). Companies like Microsoft (Defender EASM), Palo Alto (Cortex Xpanse), Tenable, Bishop Fox and dozens of startups sell this as a service. The core capability — list every subdomain — is what the tool above provides for free.

For Pakistani organisations, ASM has become urgent. Banks, telcos and government departments increasingly face automated reconnaissance from threat actors. The first measurement of your security posture is whether you, or someone hostile, has the more complete subdomain list.

Five core techniques cover almost all subdomain enumeration. First, Certificate Transparency (CT) logs: every public TLS certificate is logged to a public, append-only ledger and the subject name in the cert reveals the subdomain. Tools like crt.sh, Censys and our scanner above query these logs to find names you have ever issued certificates for.

Second, DNS brute force: try a wordlist of common names (api, dev, staging, admin, vpn, …) against the apex and see which resolve. Third, search engine scraping: Google, Bing, Yandex and Shodan often index subdomains in URLs and HTML. Fourth, JavaScript and HTML scraping of the main site for hardcoded subdomain references.

Fifth, passive DNS — services like SecurityTrails, PassiveTotal, VirusTotal and DNSDB record every DNS query they observe in their networks and let you query historical resolution data. Combined, these five give a remarkably complete picture without ever sending traffic to the target organisation’s authoritative DNS.

Since 2018, all publicly-trusted TLS certificates must be submitted to at least two CT logs to be accepted by major browsers. CT logs are append-only, publicly readable, cryptographically verifiable. The intent was to detect rogue or mis-issued certificates; the side effect is that every subdomain you ever issued a certificate for is permanently public.

Tools like crt.sh and Censys index CT logs and let you query by domain. ‘crt.sh?q=%.example.com’ returns every certificate ever issued for any subdomain of example.com. Even ‘internal-billing-staging’ that you assumed nobody could find is right there if it ever got a Let’s Encrypt cert.

There is no opting out without giving up publicly-trusted TLS. The defensive lesson: never assume internal subdomains are secret because the URL is hard to guess. Instead, secure them properly — IP allowlist, mTLS, VPN gateway, basic auth — assuming everyone knows the name.

A wildcard DNS record (*.example.com → 1.2.3.4) returns the same answer for every name, including ones that do not really exist. This breaks naive brute-force enumeration: every random string ‘resolves’, and the scanner cannot tell which names are real services and which are catch-all fallbacks.

Sophisticated scanners detect wildcards by querying obviously-fake names (zzzz12345-not-real.example.com) and noting whether they resolve. If they do, the scanner records the wildcard target IP and filters out subsequent matches.

Wildcards are common in SaaS architectures (every customer gets customername.appname.com via a wildcard) and in CDN configurations. Reading a scanner’s output requires knowing whether you are looking at real services or a wildcard fan-out.

A subdomain takeover happens when blog.example.com has a CNAME pointing to a third-party SaaS (e.g., your-blog.medium.com or your-shop.shopify.com), and you cancel the SaaS account but forget to remove the CNAME. The third-party platform sees the abandoned name and lets a new user claim it — instantly, that user controls blog.example.com.

The damage is immense. The attacker can serve phishing pages indistinguishable from your brand, steal cookies set on parent domains in some configurations, run JavaScript on subdomain.example.com that touches the apex, and abuse the trust your users place in your domain.

Common vulnerable services: GitHub Pages, Heroku, AWS S3, Azure App Services, Shopify, Tumblr, Surge.sh, and dozens more. Each maintains its own claim verification policy; some require ownership proof, many do not. The defensive practice is simple: when you decommission a service, remove the DNS record before you delete the account.

Almost every bug-bounty program defines its scope by domain — ‘*.example.com is in scope’ — and the first thing every researcher does is enumerate subdomains. The list is gold: forgotten apps, half-finished features, and outdated frameworks tend to live on subdomains rather than at the apex.

Standard workflow: run amass, subfinder and assetfinder for passive collection, run massdns for active resolution, run httpx to identify which subdomains have HTTP services, then run nuclei templates for known vulnerabilities. The whole pipeline can be scripted and run nightly.

Pakistani researchers have placed in the top 10 on HackerOne and Bugcrowd in part by being meticulous with subdomain enumeration. Many high-value bounties (RCEs, auth bypasses) come from subdomains the target organisation forgot they owned.

Use this tool only on domains you own or have written permission to assess. Bug-bounty programs grant that permission within their stated scope; pen-test contracts grant it within agreed terms; everything else needs explicit consent. Pakistani law (PECA 2016 and successor amendments) treats unauthorised scanning as a cyber offence and FIA does enforce.

Even when authorised, be a good neighbour. Rate-limit your queries — this scanner intentionally throttles. Avoid running massive resolver-stressing brute forces against shared DNS infrastructure. Identify yourself in user-agent strings when scraping. Honour robots.txt where applicable.

When you find something serious — an exposed admin panel, a leaked credential, an open S3 bucket — report it through the organisation’s responsible disclosure channel. If they don’t have one, email security@ at the apex; if no response in 90 days, escalate via CERT-PK or the bug-bounty platform if applicable.

Across hundreds of Pakistani company audits, certain subdomain names recur with striking regularity. Web infrastructure: www, m, mobile, blog, news, careers. APIs and services: api, api-v1, api-v2, gateway, auth, sso. Internal-leaking-out: dev, staging, test, qa, uat, beta, preprod.

Communications: mail, smtp, mx, webmail, owa, autodiscover. Operations: vpn, remote, proxy, jump, bastion, monitoring, status, grafana, kibana. Marketing: shop, store, promo, campaign-2024, eid-special. Vendor and SaaS: hr (Workday), helpdesk (Freshdesk), support (Zendesk).

Spotting these in your own enumeration is half the value — they are also the highest-priority items to harden, because attackers are using the exact same wordlist.

Brute-force enumeration is only as good as the wordlist. SecLists (the de facto open-source wordlist collection) ships with several DNS-specific lists ranging from 1,000 to over a million entries. Common-2,000 catches most easy wins; commonspeak2 (community-curated) goes deeper; massive lists trade speed for thoroughness.

Permutation engines (altdns, dnsgen, gotator) take known subdomains and generate variations — api → api-v2, api-internal, api-eu, api-stg. They are excellent at finding the next-gen of names you missed.

For Pakistan-specific work, augmenting wordlists with local terms (pkr, cnic, pia, hbl, pak, lhr, isb, khi) and Urdu transliterations (jazz, easypaisa, jazzcash, sastaticket) catches local-only subdomains that international lists miss.

Subdomain enumeration is mostly about finding A and CNAME records, but other record types leak information too. SPF and TXT records often list every authorised mail-sending domain, including subdomains used for transactional email (sendgrid.example.com, mg.example.com).

MX records reveal mail infrastructure subdomains (mail.example.com, mx1.example.com). SRV records reveal service-specific subdomains (_sip._tcp.example.com points to SIP servers). DMARC and DKIM TXT records reveal subdomains used by partners with rua/ruf reporting.

A complete enumeration walks beyond A/CNAME and pulls SPF, MX, SRV, DMARC and DKIM to extract the embedded subdomain references. Our scanner above does this automatically for SPF and MX; deeper passes can use ‘dig +short any subdomain.example.com’ to enumerate everything published.

Many organisations run split-horizon DNS: external resolvers see the public set of subdomains, internal resolvers see those plus an internal-only set (intranet.example.com, gitlab.internal.example.com, …). Public scanners only see the external set, which is the right design for security.

If internal subdomains start appearing in CT logs (because somebody requested a Let’s Encrypt cert for them), that internal/external boundary leaks. The fix is to use a private CA for internal services or to use a different, internal-only domain (example.local) that never gets public certificates.

Pakistani organisations sometimes accidentally expose internal-DNS subdomains via VPN portals, status pages, and public service registries. Auditing CT logs against your own design intent is a quick way to find these accidental disclosures.

Modern infrastructure spawns subdomains automatically. Every S3 bucket gets bucketname.s3.amazonaws.com. Every CloudFront distribution gets a randomly-generated d12345.cloudfront.net. Every ALB gets a default name. Pakistani SaaS companies frequently CNAME these defaults to friendlier subdomains and forget about them.

Tools like S3Scanner, gcphound and azuretool enumerate cloud-default-named buckets and services for an organisation. Even without subdomain enumeration, finding ‘companyname-backups.s3.amazonaws.com’ open to the public is a depressingly common bug-bounty payday.

The defensive playbook: name cloud resources predictably so you can audit them, attach tagging policies so unowned resources are obvious, and run periodic enumeration against your own cloud accounts the same way an attacker would.

The standard subdomain enumeration toolchain in 2026: amass (most thorough, slowest), subfinder (fast, passive-only), assetfinder (lightweight, fast), findomain (Rust-fast). Pipe outputs into massdns or shuffledns for active resolution, then httpx to confirm which names actually serve HTTP, then nuclei to scan for known issues.

Each tool plays differently. Amass uses dozens of passive sources and active brute force; results are exhaustive but slow and noisy. Subfinder is the favourite for fast first passes — uses 30+ sources, no active queries against the target. Use both and union the results.

Our tool above is built for the in-browser quick scan: passive CT log query, light dictionary, immediate visualisation. For deep work, run the open-source tools locally where you can configure scope, rate limits and source API keys.

Single scans are snapshots; security is a video. Mature programs run continuous subdomain monitoring — diffing today’s enumeration against yesterday’s and alerting on new entries. New subdomains are interesting both as legitimate launches (verify they were authorised) and as potential signs of attacker activity (typosquatting).

Open-source: a cron job around amass with output diffing and Slack notification. Commercial: Microsoft Defender EASM, Palo Alto Cortex Xpanse, RiskIQ, BitSight all do this at scale with rich reporting and integration into security tooling.

For Pakistani organisations starting out, a weekly script that diffs subfinder output and emails the security team is a 30-minute setup that catches surprising amounts of shadow IT, abandoned campaign sites, and unauthorised cloud workloads.

A subdomain inventory is only valuable if someone acts on it. Internal reports should categorise findings: critical (takeover-prone, exposed admin), high (outdated software, missing TLS), medium (deprecation candidates), low (low-impact informational). Each category needs an owner and a deadline.

External reports — from a pen-test, audit, or bug-bounty submission — must include reproduction steps, evidence (screenshots, request/response captures), and a recommended fix. Vague reports get ignored; specific ones get fixed quickly.

When you find a takeover prone subdomain that is not yours, follow responsible disclosure. Many large Pakistani companies have security@ inboxes; for those that don’t, CERT-PK accepts and forwards reports.

Defensive checklist for any organisation: maintain a canonical inventory of every subdomain (a CMDB or just a spreadsheet). Every new subdomain is ticketed and approved. Every retired service triggers a DNS-record-deletion ticket BEFORE the underlying account is closed.

Rotate ownership annually — every subdomain has a named owner and they confirm yearly that it should still exist. Anything unowned for two cycles is decommissioned. Run continuous CT-log monitoring for your own brand to catch unauthorised certificate issuance.

Train every developer and marketer to ask security before pointing a CNAME at a SaaS. Most takeover incidents trace to a marketing campaign or a side project that nobody tracked.

Common findings in Pakistani audits: forgotten staging environments still exposed (staging.bank.pk leaking customer data), expired CMS subdomains (blog-old.company.pk running a vulnerable WordPress), abandoned campaign microsites (eid2022.brand.pk pointing to an unclaimed Heroku app), and surprising amounts of vendor-managed infrastructure (sso.company.pk → an unfamiliar SaaS).

Banking sector subdomains are now mostly hardened thanks to SBP guidance. Telco and government subdomains are improving but slower. Educational institutions (.edu.pk) frequently expose decade-old systems on subdomains nobody remembers.

When you find issues affecting national institutions, escalate through CERT-PK and the relevant regulator (SBP, PTA, or HEC). Direct disclosure to the institution sometimes works; coordinated escalation usually works faster.

Encrypted Client Hello (ECH) hides the target SNI from network observers, slightly reducing one passive enumeration vector. CT logs remain authoritative and unaffected. Browser-level changes are slow; the practical impact on enumeration is minimal for now.

ML-driven enumeration tools generate name candidates from organisation context (industry, location, brand assets) instead of static wordlists. Early implementations show 10–30% more discovery on large targets. They are also faster at finding typosquats — useful for brand monitoring.

Attack Surface Management as a category is consolidating. Microsoft, Palo Alto, CrowdStrike and Tenable all now ship ASM as part of broader security suites. Open-source remains strong (amass, subfinder, project discovery’s ecosystem) and is what most independent researchers will keep using.

For defenders: build the canonical inventory, run continuous CT log monitoring, set up weekly diff alerts on new subdomains, audit dangling CNAMEs after every decommission, and rotate ownership yearly. Treat subdomains as named assets, not technical detail.

For ethical researchers: get permission first, use this tool for fast situational awareness, then move to amass + subfinder + httpx + nuclei for deep work. Always responsibly disclose. Build your own continuous monitoring on the targets you’re authorised to assess.

For everyone in between: bookmark this page, run a scan against your own apex once a quarter, and act on whatever surprises you. The subdomain you forgot owning is the one tomorrow’s attacker will love finding.