External recon of a domain

External recon answers one question before any testing starts: what does this organization expose to the internet, and who owns each piece of it? The asset list it produces is often the most used part of the whole report, because most clients have never seen theirs written down.

Confirm scope in writing first. A subdomain of the client's domain that points at a SaaS vendor's address is the vendor's system, and testing it needs the vendor's permission, not the client's.

What to check first

• The scope letter: apex domains, IP ranges, and whether third party hosted assets are in.
• Certificate transparency for every apex domain. It is the fastest list of names the client has ever issued.
• Which names resolve today, and which point at cloud resources that no longer exist.
• Anything listening on a management port: VPN portals, firewall admin pages, remote desktop, file transfer.
• The product and version of each edge device, because that is where most initial access in our research starts.

DNS records and zone transfer

dig +short NS example.com
dig +short MX example.com
dig +short TXT example.com
dig AXFR example.com @ns1.example.com

TXT records carry verification tokens for SaaS vendors, which tells us the client's stack before we send a single packet to it. A zone transfer rarely works now, but it costs one query, and when it does work it hands over every internal name at once.

Fix. Allow zone transfers only to your secondary servers, by address or with TSIG keys. Remove verification records for services you no longer use; each one is a note to an attacker about where your data lives.

Subdomain enumeration from certificate transparency

curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[].name_value' | tr 'A-Z' 'a-z' | sed 's/^\*\.//' | sort -u > ct-names.txt
subfinder -d example.com -all -silent > passive-names.txt
sort -u ct-names.txt passive-names.txt > names.txt

Every public certificate is logged, so staging, admin and test hostnames show up here even when nobody linked to them. Names like vpn-old, dev-api or jenkins go to the top of the list.

Fix. You cannot hide certificate logs, so watch them. Subscribe to alerts for your apex domains and treat every new certificate as a new asset that needs an owner. Internal-only systems should get certificates from an internal CA, not a public one.

Resolve names and find subdomain takeovers

dnsx -l names.txt -cname -resp -silent > cnames.txt
grep -Ei 'cloudfront\.net|azurewebsites\.net|herokuapp\.com|github\.io|s3[.-][a-z0-9.-]*amazonaws\.com' cnames.txt

Resolving names is ordinary DNS traffic and touches nothing of the client's beyond their name servers. A CNAME that points at a deleted cloud resource can sometimes be claimed by anyone with an account at that provider, which lets them serve content on the client's name. We confirm with the provider's documented error response and report it. We do not claim the resource unless the rules of engagement say we may.

Fix. Delete the DNS record before you delete the cloud resource, never after. Run a scheduled job that resolves every CNAME you own and alerts when the target answers with the provider's "not found" page.

Port scanning

nmap -sL -n -iL scope-ranges.txt | awk '/report for/{print $NF}' > in-scope-ips.txt
sudo nmap -Pn -sS --top-ports 1000 -T3 -iL in-scope-ips.txt -oA tcp-top1000
sudo nmap -Pn -sV -sC -p 22,443,3389,4443,8443,10443 -iL in-scope-ips.txt -oA edge-services
sudo nmap -Pn -sU --top-ports 50 -iL in-scope-ips.txt -oA udp-top50

The first line expands the ranges in the scope letter into single addresses, which the next step also uses as its filter. SYN and UDP scans need root. We pace scans to the rules of engagement and give the client our source addresses before we start, so their team can tell our traffic from a real attack and still practise seeing it.

Fix. Management interfaces do not belong on the internet. Put firewall admin, hypervisor consoles and remote desktop behind a VPN or an allowlist, and give every listening service a named owner in the asset register.

Fingerprint web services

dnsx -l names.txt -a -resp -silent | tr -d '[]' | awk '{print $1, $3}' > name-ip.txt
awk 'NR==FNR{scope[$1]=1; next} ($2 in scope){print $1}' in-scope-ips.txt name-ip.txt \
  | sort -u > hosts.txt
httpx -l hosts.txt -title -tech-detect -status-code -follow-redirects -o web.txt

Only names that resolve to an in-scope address go to httpx. A name on the client's domain that resolves to a SaaS vendor's address stays on the asset list but gets no requests from us. This is ProjectDiscovery's httpx; where the Python HTTP client of the same name is also installed, check which one comes first on the PATH.

We sort the output by what it is: login portals, default install pages, staging copies of production, and appliances with a product name in the title. An appliance login page with a version in the HTML is the first thing we check against current advisories.

Fix. Hiding version banners does not fix anything. What fixes it is a patch window for edge devices measured in days, and an inventory that tells you within an hour which of your devices a new advisory covers.

Our web app first hour page picks up where this one ends, with the web hosts this pass found. Our atarus-recon tool runs an external recon pass in one command and writes a report; we treat its output as the starting list and verify each entry by hand.

What the defender sees

Certificate log searches go to the log operators and leave nothing on the client's side. DNS lookups through a public resolver reach the client's authoritative name servers, which may log them, but the source they record is the resolver, not us. The zone transfer attempt is different: it goes straight from our address to the client's name server and is logged wherever that server logs transfers. Port scans show up in firewall logs and, if the client has one, in their external attack surface monitoring. If our scan produced no alert anywhere, that goes in the report as well.