Introduction
By now, you are working with:
- Clean subdomain list
- DNS insights
- IP ranges
- Live hosts
But there is still one gap:
What is actually running on these hosts?
Ports and services answer that.
Because a web app is not just port 80 and 443.
There are APIs, admin panels, dashboards, debug services, and sometimes exposed internal tools.
This part helps you see what’s behind the door, not just the door.
Why port and service discovery matters
- Many services run on non-standard ports
- Admin panels are often hidden on uncommon ports
- APIs may run separately from main web app
- Misconfigured services expose sensitive information
- Banners reveal tech stack and versions
Subdomain tells you where to look. Ports tell you what to look for.
What you are trying to find
- Open ports on live hosts
- Services running on those ports
- Technology used
- Version information (if available)
- Misconfigured or exposed services
This becomes your technical attack surface.
Tools you will use
- naabu – fast port scanning
- nmap – detailed scanning and service detection
- httpx – probing web services
- netcat (nc) – manual banner grabbing
- curl – HTTP-level inspection
Keep scanning controlled and within scope.
Step-by-step port and service discovery workflow
1. Fast port scanning with naabu
Start with fast discovery.
naabu -l live_hosts.txt -top-ports 100 -o ports.txt
Why this works
- Covers most common ports
- Fast and lightweight
- Good starting point
You get output like:
example.com:80
example.com:443
example.com:8080
2. Expanding to more ports (optional)
If allowed, increase coverage:
naabu -l live_hosts.txt -p 1-1000 -rate 1000 -o ports_full.txt
Keep rate controlled.
Do not overload target.
3. Service detection with nmap
Now move from ports to services.
nmap -sV -p 80,443,8080,8443 example.com
What you get
- Service name
- Version (sometimes)
- Additional details
Example:
80/tcp open http Apache httpd 2.4.49
This is valuable for vulnerability mapping.
4. Banner grabbing (manual check)
Sometimes automated tools miss details.
Use netcat:
nc example.com 80
Or:
curl -I http://example.com
Look for:
- Server headers
- Tech stack
- Cookies
- Redirects
5. HTTP probing for discovered ports
Take all ports and check which serve web content.
httpx -l ports.txt -title -status-code -tech-detect -silent -o services.txt
What this gives
- Title
- Status code
- Technologies
- Response behaviour
Now you know which ports are actually useful.
Common ports and what they mean
80 / 443
Main web application
8080 / 8443
Alternate web servers, dashboards
8000 / 3000
Dev servers, internal apps
9000+
Admin panels, APIs, monitoring tools
22 (SSH)
Remote access (usually ignore unless in scope)
Focus on web-related ports first.
Service fingerprinting basics
You want to identify:
- Web server (Apache, Nginx)
- Framework (Node, Django, Spring)
- CDN or proxy
- API type (REST, GraphQL)
Example:
httpx -l ports.txt -tech-detect
Output may show:
- nginx
- express
- cloudflare
- react
This helps you decide next testing steps.
How banners help in recon
Banners may reveal:
- Exact software version
- Debug messages
- Internal paths
- Server misconfigurations
Example:
Server: Apache/2.4.49
This can directly lead to known CVEs.
Always verify before assuming vulnerability.
Identifying high-value services
Look for:
- Admin panels
- Login pages
- API responses
- Debug endpoints
- Monitoring dashboards
Example:
/admin/login/api/graphql
These are entry points for deeper testing.
Filtering noise
You will find:
- Closed ports
- Filtered ports
- Same service on multiple hosts
Filter by:
- Unique responses
- Interesting titles
- Different technologies
Ignore duplicates.
Safe scanning practices
This is important.
- Stay within scope
- Limit scan speed
- Avoid full port scans unless allowed
- Do not scan sensitive ports without permission
- Start small, expand slowly
Fast recon is good. Safe recon is better.
Real-world use-cases
- Finding admin panel on port 8080
- Discovering API on port 3000
- Identifying outdated Apache version
- Detecting internal dashboards exposed publicly
- Finding staging service on alternate port
These are common bounty wins.
Mini lab exercise (30–40 minutes)
- Use your live hosts list.
- Run port scan:
naabu -l live_hosts.txt -top-ports 100 -o ports.txt
- Run service detection:
nmap -sV -iL ports.txt
- Probe HTTP services:
httpx -l ports.txt -title -status-code -tech-detect -silent
- Open 2–3 interesting services in browser.
Write:
- What service it is
- Why it matters
- What you can test next
Common mistakes and fixes
Mistake: Only checking ports 80 and 443
Fix: Scan top ports
Mistake: Ignoring banners
Fix: Banners give direct clues
Mistake: Over-scanning aggressively
Fix: Stay controlled
Mistake: Not validating manually
Fix: Always check in browser
Quick command summary
Port scan:
naabu -l live_hosts.txt -top-ports 100
Service detection:
nmap -sV -p 80,443 example.com
HTTP probing:
httpx -l ports.txt -title -status-code -tech-detect
Banner check:
curl -I http://example.com
What to do after this Part
- Send web services to URL collection
- Extract endpoints and parameters
- Run JS analysis
- Check authentication and APIs
Now you understand what is running, not just where.
Next post preview
Part 11 – URL Collection and Analysis (Active + Passive Combined)
We will cover:
- Crawling techniques
- Archive data usage
- Endpoint extraction
- Filtering useful URLs
- Building parameter lists
This is where recon becomes very practical.
Closing thought
Ports reveal what is hidden.
Services explain how it works.
When you combine both,
you stop guessing and start mapping reality.
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.
