🛡️ Methodology Checklist
- Passive: query crt.sh, VirusTotal, SecurityTrails for subdomains
- Active zone transfer attempt against all NS servers
- Subdomain brute-force with wordlist:
gobuster dns -d [DOMAIN] -w [WORDLIST] - Virtual host fuzzing:
ffuf -w [WORDLIST] -H "Host: FUZZ.[DOMAIN]" -u http://[IP] - Check for wildcard DNS:
nslookup DOESNOTEXIST.[DOMAIN] - Enumerate internal DNS names from TLS certs (SANs)
- Add discovered vhosts to /etc/hosts for further testing
🎯 Operational Context
Think Dumber First: Passive first — query crt.sh, VirusTotal, and SecurityTrails before sending any requests to the target. These sources index subdomains found in historical scans and cert logs. After passive, move to active: DNS brute-force against the authoritative NS server using
gobuster dnsordnsxwith SecLists subdomains wordlist.
When you land here: Web target with a domain. Build subdomain list passively first. Resolve all discovered subdomains. Check each unique IP for vhost-based virtual hosting. Look for DNS wildcards before brute-forcing. Map subdomains to attack surface.
⚡ Tactical Cheatsheet
| Command | Tactical Outcome |
|---|---|
dig [DOMAIN] A | Retrieve IPv4 address |
dig [DOMAIN] MX | Find mail servers |
dig [DOMAIN] NS | Identify authoritative nameservers |
dig [DOMAIN] TXT | Retrieve TXT records (SPF, DMARC, verifications) |
dig [DOMAIN] CNAME | Retrieve canonical name/alias records |
dig [DOMAIN] SOA | Retrieve Start of Authority record |
dig @1.1.1.1 [DOMAIN] | Query specific nameserver |
dig +trace [DOMAIN] | Show full DNS resolution path |
dig -x [IP] | Reverse lookup — IP to hostname |
dig +short [DOMAIN] | Concise answer only |
dig +noall +answer [DOMAIN] | Strip metadata, show answer section only |
🔬 Deep Dive & Workflow
How DNS Works (Resolution Chain)
- Computer checks local cache → queries DNS Resolver (ISP)
- Resolver queries Root Name Server → points to TLD server
- TLD Name Server → points to Authoritative Name Server
- Authoritative Name Server → returns actual IP
The Hosts File (Manual Override)
Bypasses DNS entirely for specific hostnames. Critical for HTB labs.
- Linux/macOS:
/etc/hosts - Windows:
C:\Windows\System32\drivers\etc\hosts - Format:
[IP] [hostname] [alias]
[TARGET_IP] inlanefreight.htb
[TARGET_IP] dev.inlanefreight.htb
DNS Record Types
| Type | Description | Recon Value |
|---|---|---|
| A | IPv4 address | Direct host discovery |
| AAAA | IPv6 address | IPv6 attack surface |
| CNAME | Alias → can point to cloud/external services | Subdomain takeover potential |
| MX | Mail servers | Email infra, phishing paths |
| NS | Authoritative nameservers | Target for zone transfer |
| TXT | Arbitrary text (SPF, DMARC, verification) | Tech stack, third-party services |
| SOA | Zone admin info | Admin email (. = @) |
| SRV | Service hostname/port | VoIP, LDAP, Kerberos discovery |
| PTR | Reverse DNS — IP to hostname | Internal host mapping |
dig Output Sections
- Header: Status (
NOERROR= success), flags (qr=response,rd=recursion) - Question: The query made
- Answer: IP/data + TTL (cache duration)
- Footer: Query time, responding server
Reconnaissance Applications
- CNAME records: Can reveal outdated dev/staging servers
- NS records: Reveal hosting providers
- New subdomains in TXT (
vpn.,payroll.) = new entry points or internal software - Change monitoring: New subdomains = new attack surface
🛠️ Troubleshooting & Edge Cases
| Problem | Cause | Fix |
|---|---|---|
| gobuster dns returns wildcard false positives | DNS wildcard active (*.domain.com resolves) | Test: dig randomgarbage123.[DOMAIN]; if resolves, filter by unique response content size in ffuf vhost mode |
| Passive sources return different subdomains | Each source has different historical data | Take union of all sources; use cat *.txt | sort -u > all_subs.txt to merge |
| Active brute-force DNS query rate limited | Target DNS rate-limiting queries | Reduce threads: gobuster dns -t 10 -r [TARGET_NS]; use internal DNS server as resolver |
| Subdomain resolves to CDN IP (Cloudflare/Akamai) | Real origin IP hidden behind CDN | Check historical DNS records on SecurityTrails; look for direct origin IP in cert’s SAN list; check MX records |
| dnsx returns NXDOMAIN for all discovered subdomains | Subdomains were deleted or wrong nameserver | Query against authoritative NS: dnsx -r [AUTH_NS] -d [DOMAIN] -w wordlist.txt |
📝 Reporting Trigger
Finding Title: Subdomain Discovery Revealing Shadow IT / Unsecured Development Environments Impact: Discovered subdomains expose forgotten staging environments, admin panels, internal tools, or vulnerable legacy applications not included in regular security assessments. Root Cause: Subdomains created for development/testing without proper lifecycle management or security baseline. Recommendation: Maintain an authoritative DNS inventory. Implement a subdomain lifecycle policy. Ensure all subdomains are included in security scanning scope. Remove or protect orphaned subdomains.