Part 7 – Subdomain Permutation and Brute Force (Advanced)

Introduction

Subdomain brute force has a bad reputation.
Most people do it wrong.

They throw huge wordlists at targets, hit wildcards, drown in false positives, and quit.
That is not recon. That is guessing.

In this part, we do brute force the right way.
Slow where needed.
Smart always.

This is about controlled expansion of what you already know.

Why brute force still matters

Passive sources miss things.
Certificates expire.
Repos get cleaned.
Archives lie.

Brute force finds:

Fresh infrastructure
Newly deployed services
Internal naming patterns
Hosts never exposed publicly

Passive recon shows history. Brute force shows reality.

When brute force makes sense

Do not brute force blindly.
Brute force only after you have context.

You should already have:

CT log data
DNS structure understanding
Existing subdomain list
Cloud provider hints

If you skip those, brute force becomes noise.

What you are actually brute forcing

You are not guessing randomly.
You are testing naming logic.

Common real-world patterns:

dev, stage, test, qa
api, auth, admin, internal
Region-based names
Team or product names
Environment suffixes
Versioned services

Brute force works when it respects patterns.

Tools you will use

ffuf – fast, flexible, controllable
shuffledns – DNS-first brute force
dnsx – resolution and enrichment
dnsgen / altdns – smart permutations
massdns – high-speed resolution
custom wordlists – context-based
jq, sort, uniq – cleanup

No magic tools. Just good flow.

Wordlists that actually work

Avoid massive generic lists unless necessary.

Good sources:

SecLists DNS wordlists (small and medium)
Words from existing subdomains
Repo names and service names
Cloud service hints
Error pages and banners

Example starter list:

dev
stage
staging
test
qa
api
auth
admin
internal
beta
old
new
v1
v2

Build lists per target.

Step-by-step brute force workflow

1. Build a context-aware wordlist

Extract words from known subdomains.

cat subdomains.txt | sed 's/\./\n/g' | sort -u > base_words.txt

Clean obvious noise and merge with environment words.

cat base_words.txt env_words.txt | sort -u > final_words.txt

This is your custom wordlist.

2. DNS-first brute force with shuffledns

DNS-first brute force avoids HTTP noise.

shuffledns -d example.com -w final_words.txt -r resolvers.txt -o shuffledns_found.txt

Why this works:

Fast
Accurate
Minimal false positives
No HTTP request flood

3. HTTP-based brute force with ffuf (carefully)

Use ffuf when DNS brute force is limited.

ffuf -w final_words.txt -u https://FUZZ.example.com -mc 200,301,302,403 -fs 0 -t 40

Tips:

Limit threads
Filter size
Watch response patterns

ffuf is powerful but noisy if misused.

Handling wildcard DNS properly

Always test wildcard behaviour first.

dig random123456.example.com +short

If wildcard exists:

DNS brute force alone is not enough
You must filter via HTTP behaviour
Compare headers and content length

Wildcard-aware filtering saves hours.

Permutation instead of guessing

Use existing subdomains to generate smarter guesses.

Using dnsgen

dnsgen subdomains.txt > permutations.txt

Using altdns

altdns -i subdomains.txt -w final_words.txt -o altdns_out.txt

Then resolve:

shuffledns -d example.com -list permutations.txt -r resolvers.txt -o perm_resolved.txt

This finds:

Versioned services
Environment variants
Forgotten deployments

Reducing noise after brute force

Never trust raw output.

Post-filter everything:

Resolve DNS
Check HTTP response
Compare headers
Compare titles

Example HTTP check:

cat perm_resolved.txt | httpx -title -status-code -content-length -silent > http_checked.txt

Only keep hosts with unique behaviour.

Prioritising brute force results

Score each host quickly:

High priority:

Unique title
API keywords
Auth-related paths
Admin-looking responses

Low priority:

Same CDN error page
Same content length
Same headers everywhere

Focus your time.

Real-world use-cases

Finding api-staging.example.com not in CT logs
Discovering internal-admin.example.com with weak auth
Catching v2-api.example.com during rollout
Spotting forgotten old.example.com deployments

These are common and valuable.

Mini lab exercise (30–40 minutes)

Use a domain you own or lab domain.
Prepare wordlist:

echo -e "dev\nstage\napi\nauth\nadmin" > env_words.txt
cat known_subdomains.txt | sed 's/\./\n/g' | sort -u > base_words.txt
cat base_words.txt env_words.txt | sort -u > final_words.txt

Run shuffledns:

shuffledns -d yourdomain.com -w final_words.txt -r resolvers.txt -o brute_dns.txt

Resolve and check HTTP:

cat brute_dns.txt | httpx -status-code -title -silent > brute_http.txt

Review top 3 unique hosts and add notes.

Common mistakes and fixes

Mistake: Using huge wordlists blindly
Fix: Build context-based lists

Mistake: Ignoring wildcard DNS
Fix: Test wildcard early

Mistake: Treating every resolved host as valid
Fix: Always verify HTTP behaviour

Mistake: Brute forcing before passive recon
Fix: Brute force comes after understanding

Quick command summary

Build wordlist:

cat subdomains.txt | sed 's/\./\n/g' | sort -u > base_words.txt

Permutation:

dnsgen subdomains.txt > permutations.txt

DNS brute force:

shuffledns -d example.com -w final_words.txt -r resolvers.txt -o shuffledns_found.txt

HTTP check:

httpx -l shuffledns_found.txt -title -status-code -silent

What to do after this Part

Send confirmed hosts to URL collection
Run JS discovery on new hosts
Check auth and API patterns
Feed CNAMEs into takeover analysis

Brute force feeds everything downstream.

Next post preview

Part 8 – ASN, IP Harvesting and Mapping Ranges to Assets

We will cover:

ASN discovery
IP range mapping
Cloud IP identification
Safe IP-level recon
Linking IPs back to web apps

This is where recon starts going wider.

Closing thought

Brute force is not loud when done correctly.
It is precise.

Use patterns.
Respect limits.
Let structure guide discovery.

Disclaimer

This content is for educational purposes only. Use it ethically and only against targets you own or have explicit permission to test. Do not use any techniques described here in ways that break laws, platform rules, or third-party rights. If in doubt, stop and get permission.

Share the Post:

CyberXsociety