Introduction
By now, you have:
- Subdomains
- DNS data
- IP ranges
- ASN mapping
But one question still matters:
Which of these are actually alive?
Because only live systems can be tested.
This part is about filtering reality from noise.
You will learn how to identify live hosts safely, without breaking rules or creating unnecessary traffic.
Why live host discovery matters
- Not every subdomain is active
- Not every IP serves an application
- Many assets are dead, parked, or internal
If you skip this step:
- You waste time
- You scan noise
- You miss real targets
Recon is not about collecting more. It is about filtering better.
What you are trying to find
- Which subdomains are live
- Which IPs respond
- Which hosts serve web content
- Which services are actually reachable
This step creates your real working target list.
Tools you will use
- httpx – HTTP probing and enrichment
- dnsx – DNS resolution check
- naabu – port discovery (fast)
- nmap – detailed scanning (controlled)
- masscan – high-speed (only if allowed)
- curl – manual validation
Keep it controlled. Accuracy over speed.
Step-by-step live host discovery workflow
1. Start with resolved subdomains
From previous parts, you already have:
subdomains.txt
First, confirm resolution:
dnsx -l subdomains.txt -silent -o resolved_hosts.txt
Now you have only valid DNS entries.
2. HTTP probing with httpx (core step)
This is your most important command.
httpx -l resolved_hosts.txt -title -status-code -content-length -silent -o live_hosts.txt
What this gives you
- Status codes
- Page titles
- Content length
- Confirmation of live web service
This is your primary filtering layer.
3. Detecting web services on non-standard ports
Many apps run on:
- 8080
- 8000
- 8443
- 3000
Scan for common ports:
naabu -l resolved_hosts.txt -top-ports 100 -o ports.txt
Then probe:
httpx -l ports.txt -title -status-code -silent -o port_services.txt
4. IP-based host discovery
From Part 8, you have IPs.
Check which are alive:
nmap -sn ip_ranges.txt
Extract live IPs and probe:
httpx -l live_ips.txt -title -status-code -silent -o ip_live_hosts.txt
5. Filtering noise (very important)
Not every “live” host is useful.
Common noise:
- CDN default pages
- Same content everywhere
- Wildcard responses
Filter using:
- Content length
- Titles
- Server headers
Example:
httpx -l resolved_hosts.txt -title -status-code -content-length -silent | sort -u
Focus on unique responses.
Identifying high-value hosts
Look for patterns in output:
Interesting signs
- Admin panels
- Login pages
- API responses
- Error messages
- Debug info
- Unique titles
Example titles:
- “Admin Dashboard”
- “Internal Tool”
- “Staging Environment”
These are priority targets.
Handling wildcard DNS at this stage
If wildcard exists:
- Many subdomains will appear live
- Most will return same content
Solution:
- Compare content length
- Compare titles
- Ignore duplicates
Example:
httpx -l hosts.txt -content-length -title -silent
Group similar outputs and remove duplicates.
Safe network-level recon practices
This is where many people go wrong.
Follow these rules:
- Do not scan full ranges aggressively
- Respect program scope
- Use low thread counts
- Avoid intrusive scans without permission
- Start small, then expand
Being safe is not slow. It is smart.
Basic port validation (controlled)
For confirmed hosts:
nmap -p 80,443,8080,8443 target.com
Do not scan all ports blindly.
Focus on:
- Web services
- Known application ports
Manual validation (do not skip this)
Always open important hosts in browser.
Also test with curl:
curl -I https://target.com
Check:
- Headers
- Redirects
- Cookies
- Server info
Automation finds. Manual confirms.
Prioritisation strategy
Tag hosts like this:
High priority:
- Unique responses
- Login/admin panels
- API endpoints
Medium priority:
- Static sites
- Marketing pages
Low priority:
- Duplicate wildcard responses
- CDN placeholders
This keeps your workflow clean.
Real-world use-cases
- Finding hidden admin panel on
admin.dev.example.com - Discovering API running on port 8080
- Identifying staging environment with weak auth
- Finding internal tools exposed accidentally
These are real and repeatable.
Mini lab exercise (30–40 minutes)
- Use your existing subdomain list.
- Resolve:
dnsx -l subdomains.txt -silent -o resolved.txt
- Run httpx:
httpx -l resolved.txt -title -status-code -silent -o live.txt
- Scan ports:
naabu -l resolved.txt -top-ports 50 -o ports.txt
- Probe:
httpx -l ports.txt -title -status-code -silent
- Pick 3 interesting hosts and open in browser.
Write:
- Why they are interesting
- What you can test next
Common mistakes and fixes
Mistake: Treating all resolved hosts as live
Fix: Always run httpx
Mistake: Ignoring non-standard ports
Fix: Scan top ports
Mistake: Not filtering duplicates
Fix: Use content-length and title
Mistake: Over-scanning
Fix: Stay controlled and scoped
Quick command summary
Resolve:
dnsx -l subdomains.txt -silent
HTTP probe:
httpx -l resolved_hosts.txt -title -status-code -silent
Port scan:
naabu -l resolved_hosts.txt -top-ports 100
IP discovery:
nmap -sn ip_range
What to do after this Part
- Send live hosts to URL collection
- Extract endpoints and parameters
- Run JS analysis
- Begin vulnerability testing
Now you are working only with real targets.
Next post preview
Part 10 – Port and Service Discovery and Banner Analysis
We will cover:
- Service fingerprinting
- Banner grabbing
- Identifying technologies
- Mapping attack surface deeper
This is where recon starts turning into testing.
Closing thought
Finding hosts is easy.
Finding the right hosts is skill.
Filter hard.
Focus sharp.
That is how recon becomes powerful.
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.
