What an attacker sees on day one - an external recon walk-through

In every red-team engagement, the first day looks roughly the same. No exploits, no payloads, no malware. Just a methodical mapping of what's externally visible - because you can't attack what you can't see, and most attackers can see more of you than you'd like.

This post walks through a sanitized version of what an external attacker (or an honest red team) does on day one. Run these against yourself before someone else does.

The mental model

External recon answers three questions in order:

1. What domains, IPs and services does this org expose? - the attack surface
2. Who works there, with what role, and what credentials might be lying around? - the human surface
3. What does the org's infosec posture look like from outside? - the defensive surface

A skilled attacker spends 4-8 hours on (1)+(2), then uses (3) to decide whether to attack now or wait. Most public breaches are decided in this stage, not in the exploitation that follows.

(1) Attack surface - domain and infrastructure

Subdomain enumeration

The single most useful technique. A lot of organizations harden their main domain and forget the 87 subdomains created by various teams over the years.

# Passive - from CT logs, public sources
subfinder -d example.com -all -silent
amass enum -passive -d example.com

# Active - DNS brute-force
puredns bruteforce wordlists/n0kovo_subdomains.txt example.com \
  -r resolvers.txt

# Combine + de-dupe
sort -u subs_*.txt > all_subs.txt

What we're looking for:

• staging.*, dev.*, test.*, uat.* - non-production environments often share data with prod but have weaker controls
• internal.*, admin.*, vpn.*, mail.* - admin interfaces, MX records
• Acquired-company subdomains still routing to legacy infra
• Random S3 bucket subdomains pointing at takeover-able resources

Service & banner enumeration

# Quick port survey via Shodan (no traffic from your IP)
shodan host 198.51.100.0/24

# Active enumeration
naabu -l all_subs.txt -top-ports 1000 -o ports.txt
httpx -l ports.txt -tech-detect -status-code -title -o http.txt

The httpx output is gold - for every reachable web service, you get HTTP status, page title, detected tech stack, and TLS info in one line.

TLS certificate transparency

Every cert issued for a public domain is logged. You don't need to scan an org to discover their infrastructure - just query CT.

# crt.sh has a JSON API
curl -s "https://crt.sh/?q=%25.example.com&output=json" | \
  jq -r '.[].name_value' | sort -u

The reveal: every internal hostname an org ever requested a Let's Encrypt cert for, in a clean list. Even after services are taken offline, the cert log remembers.

Cloud asset discovery

S3 buckets, GCS buckets, Azure blob storage - predictable naming makes them findable.

# S3 bucket enumeration
cloud_enum -k example -k example-corp -k example-staging
# Look for: bucket names matching the org, public ACLs, indexable contents

Most orgs have at least one mis-configured cloud asset. The hard part is finding it before someone with bad intent does.

(2) Human surface - OSINT and credential exposure

LinkedIn + GitHub patterning

A few minutes on LinkedIn gives an attacker:

• The list of engineers + their tech-stack hints (skills, posts)
• The naming convention for emails (firstname.lastname@, f.lastname@, etc.)
• Who's recently joined or left

Then GitHub:

# Find anything an org's employees have committed publicly
gh search code "config.json @example.com" --json repository,path

We're looking for:

• API keys committed and forgotten
• Old .env files in personal forks
• Internal-system documentation in public gists

This is the cheapest, highest-yield part of external recon. Many breaches start here.

Credential leak databases

# Check if any @example.com accounts appear in known breaches
holehe --only-used name.surname@example.com

# Have we got intel on which sites those emails registered with?
maigret name.surname

If an employee's email appears in a previous breach, and the org doesn't enforce 2FA - that's the cheapest path in. No exploit needed.

Pastebin / Discord / Telegram

The biggest data leaks in the last five years didn't come from sophisticated attackers. They came from somebody pasting credentials into a search engine.

Modern OSINT tools index Pastebin-like sites, public Discord servers, and known stealer-log dump sites. A 30-minute search for "@example.com" across those will tell an attacker more than a week of port-scanning.

(3) Defensive surface - what's protecting you

Before committing to an attack path, a careful attacker looks at how easy it'll be to get caught.

# SPF / DKIM / DMARC - are phishing emails likely to land?
dig +short TXT example.com | grep spf
dig +short TXT _dmarc.example.com

# Security.txt - does the org have a coordinated disclosure process?
curl -s https://example.com/.well-known/security.txt

# CSP, HSTS, security headers - front-end discipline indicator
curl -sI https://example.com | grep -E 'Strict-Transport|Content-Security|X-Frame'

What this tells an attacker:

• DMARC at p=none → email spoofing will work. Phishing is on the menu.
• No security.txt → no coordinated disclosure → org has nowhere to report findings → reduced chance of community-led discovery.
• No CSP / weak headers → frontend discipline is low → expect web bugs.

This is also the part of recon a defender can most directly influence. Tightening DMARC, publishing a security.txt, shipping CSP - these reduce the attractiveness of an org as a target.

What to do with this

Run the above against yourself this week. You will find things. The action items, in order:

1. Take down anything that shouldn't be exposed. Old staging environments, forgotten test subdomains, archived projects with public S3 buckets.
2. Rotate any secret that appeared in GitHub or a paste site. Treat it as compromised; assume it is.
3. Tighten DMARC to p=quarantine or p=reject. This single change kills most spoofing-based phishing.
4. Publish a security.txt with a real reporting contact. You'll start receiving low-cost findings from the security community in days.
5. Get a formal external pentest - once a year minimum, ideally after every major release. (Yes, we offer this. Get a scope.)

External recon is asymmetric: an attacker spends a few hundred dollars of compute and a few hours of time to map you, and you'd need to be perfectly hardened to disappoint them.

The good news: you don't need to be perfect. Just less attractive than the next target.

---

We run this exercise as part of every VAPT engagement, and as a standalone External Attack Surface Review for orgs that want a quick reality check. Talk to us if you want one scoped.