The target was a mid-sized SaaS company running a public bug bounty program. I had scope approval, a fresh Burp Suite session open, and a blank terminal window. My first instinct was to start clicking through the application and probing inputs. Instead, I forced myself to stop and spend the first two hours doing nothing but reading their JavaScript files.
It paid off faster than anything I had done before. Buried inside a minified bundle was a reference to an internal API endpoint: /api/v2/internal/admin/user-export. The endpoint was not documented, not linked from any UI, and not behind any authentication check that the JavaScript could verify. I sent a GET request with my session token. The server responded with a full CSV dump of every user in the system — names, emails, account tiers, creation dates. I had never touched the backend directly. I had never run a scanner. I had just read what the application told me in plain text.
That engagement taught me a lesson I keep coming back to: the most powerful hacking technique is not a tool. It is patience and the willingness to read what is already in front of you before you start touching anything.
Reconnaissance is the process of gathering information about a target before attempting to exploit anything. In military terminology it means scouting ahead. In security it means learning as much as possible about the infrastructure, people, technologies, and exposed surfaces of a target before sending a single attack payload.
There are two major categories. Passive reconnaissance involves gathering information without interacting with the target's systems directly — querying public records, searching the internet, reading certificate logs, and examining what the target has voluntarily exposed. The target cannot detect you because you are not touching them. Active reconnaissance involves sending packets, requests, or queries to the target's infrastructure. This includes port scanning, service fingerprinting, and content discovery. The target can potentially log or detect this activity.
Most professional security engagements begin with extensive passive recon because it is legal, stealthy, and often produces the most valuable findings. The amount of information companies accidentally leave publicly accessible is genuinely staggering. Most attacks succeed because the recon phase was done thoroughly. Most defenses fail because defenders have never mapped their own external attack surface the way an attacker would.
Passive OSINT: What You Can Find Without Touching the Target
OSINT stands for Open Source Intelligence — information gathered from publicly available sources. Before I ever open a browser to a target's application, I spend time working through several categories of public data that consistently reveal useful attack surface.
WHOIS and Reverse DNS
A WHOIS lookup on a domain reveals registrar information, registration dates, and sometimes contact details when privacy protection is not enabled. More useful than raw WHOIS is reverse DNS lookup — taking an IP address range and querying what domain names resolve to those IPs. Organizations often run dozens of services from the same IP block, and reverse DNS can surface hostnames that would never appear in a Google search. Tools like dnsx and host make this fast.
Certificate Transparency Logs
Every SSL/TLS certificate issued by a trusted certificate authority gets logged in public certificate transparency logs. The site crt.sh lets you query these logs by domain. A search for %.example.com returns every certificate ever issued for any subdomain of example.com. This is one of the most reliable ways to discover subdomains because it captures historical certificates, wildcard certificates, and certificates for internal staging environments that were accidentally issued publicly. I run a crt.sh query on every target before anything else.
LinkedIn and GitHub for Employee Intelligence
LinkedIn profiles reveal the technology stack a company uses. When engineers list "Kubernetes, Terraform, AWS, PostgreSQL" on their profile, you learn the infrastructure stack without scanning anything. GitHub is even more valuable — organizations often have public repositories containing configuration files, environment examples with real credentials accidentally committed, internal tooling, and comments that reveal internal hostnames or architecture decisions. I use GitHub's search operators like org:targetcompany filename:.env and org:targetcompany password to look for accidentally exposed secrets.
Shodan for Exposed Services
Shodan is a search engine that indexes the internet by scanning for open ports and services. You can search for an organization's IP ranges and see exactly what services are exposed — Elasticsearch clusters with no authentication, Redis instances accepting connections, old VPN endpoints, IoT devices, and more. A Shodan query for org:"Example Corp" port:9200 will show any Elasticsearch instances associated with that organization. Many critical data breaches have started with a Shodan search that took thirty seconds.
Shodan is passive in the sense that you are querying Shodan's index, not the target directly. However, Shodan itself has already scanned the target, so you should check whether active scanning is permitted in your engagement scope before using Shodan's real-time scan feature.
Subdomain Enumeration
Subdomains are where organizations hide their most interesting infrastructure. The main domain example.com is usually the most hardened, most audited surface. But staging.example.com, api-internal.example.com, or admin-legacy.example.com might be running outdated software, have debugging enabled, or lack proper authentication. Finding these subdomains is one of the highest-value activities in any engagement.
Tools: Amass, Subfinder, Assetfinder
Amass from OWASP is one of the most comprehensive subdomain enumeration tools. It combines passive techniques — querying certificate transparency logs, DNS aggregators, internet archives, and public APIs — with optional active DNS brute forcing. Subfinder is faster and focuses on passive sources, querying dozens of APIs including VirusTotal, SecurityTrails, and Censys. Assetfinder by Tom Hudson is a lightweight option that is particularly good for quick passive lookups. I typically run all three and deduplicate the results.
# Run multiple tools and deduplicate
subfinder -d example.com -silent > subs.txt
assetfinder --subs-only example.com >> subs.txt
amass enum -passive -d example.com >> subs.txt
# Sort and deduplicate
sort -u subs.txt > unique_subs.txt
# Resolve live subdomains
cat unique_subs.txt | dnsx -silent > live_subs.txt
echo "Found $(wc -l < live_subs.txt) live subdomains"DNS Brute Forcing and Virtual Host Scanning
Passive enumeration finds subdomains that have been publicly seen before. Active DNS brute forcing tries common words and patterns against the target's DNS to discover subdomains that have never appeared in any public index. Combined with virtual host scanning — sending HTTP requests with different Host headers to the same IP address — you can find applications that are served from the same infrastructure but never publicly linked.
Content Discovery
Once you have live hosts, content discovery reveals what paths, files, and directories exist on those hosts. Many applications have forgotten admin panels, backup files, debug endpoints, and configuration files sitting on public web servers because they were never removed after testing.
ffuf, Gobuster, and Dirsearch
ffuf (Fuzz Faster U Fool) is my preferred content discovery tool because of its speed and flexibility. It can fuzz URL paths, parameters, headers, and POST body fields. Gobuster is faster for pure directory bruteforcing. Dirsearch has a large built-in wordlist and is good for quick scans. All of them work by sending HTTP requests for every entry in a wordlist and recording non-404 responses.
# Basic directory discovery
ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt \
-u https://example.com/FUZZ \
-mc 200,201,204,301,302,403 \
-ac \
-o results.json
# Extension fuzzing for config/backup files
ffuf -w /usr/share/seclists/Discovery/Web-Content/raft-large-files.txt \
-u https://example.com/FUZZ \
-e .bak,.config,.env,.sql,.log \
-mc 200,201,204 \
-acThe SecLists repository by Daniel Miessler is the standard wordlist collection for this kind of work. It contains lists curated from real-world data: common directory names, backup file patterns, API endpoint names, and default credentials. Always use curated wordlists over generic ones — the signal-to-noise ratio is dramatically better.
Enable recursion carefully. Recursive content discovery will follow every discovered directory and fuzz inside it. This multiplies your requests exponentially and can look like a DoS attack. Always set a recursion depth limit and run during off-hours when testing production systems.
JavaScript File Analysis
JavaScript files are among the most overlooked recon sources. Everything that runs in the browser must be sent to the browser, which means that any endpoint, API key, internal hostname, or logic the frontend needs is embedded in JavaScript files that anyone can download and read.
I look for several categories of information in JS files. Internal API endpoints — paths like /api/v2/internal/ or /admin/ that are never surfaced in the UI but are called by the JavaScript under certain conditions. Hardcoded secrets — API keys for third-party services, internal tokens, and occasionally passwords committed by developers who didn't realize the file was public. Authentication logic — client-side role checks, JWT validation done in the browser, feature flags controlled by user properties that can be manipulated. Third-party integrations — references to external APIs that may have weaker authentication or wider scope than the main application.
Tools: LinkFinder and JSFinder
LinkFinder by GerbenJavado parses JavaScript files and extracts URLs and endpoints using regex patterns. You can point it at a URL or a local file and it will output every relative and absolute path it finds. JSFinder by Emoe works similarly. For manual analysis, I use the browser's source view combined with the Search All Files feature in Chrome DevTools, which lets me search across all loaded JavaScript files for strings like api/, secret, token, or password.
# Run LinkFinder against a JavaScript file
python3 linkfinder.py -i https://example.com/static/app.bundle.js -o cli
# Scan all JS files from a crawl
cat js_urls.txt | while read url; do
python3 linkfinder.py -i "$url" -o cli 2>/dev/null
done | sort -u | grep -v "^$"
# Quick grep for secrets in downloaded JS
grep -rE "(api_key|apikey|secret|token|password)\s*[:=]\s*['\"][^'\"]{10,}" *.jsActive Scanning
Active scanning is where you start sending packets directly to the target's infrastructure. The most fundamental tool here is nmap, which sends network packets to discover open ports and identify what services are running on them.
Nmap Basics and Service Detection
A basic nmap scan identifies which TCP ports are open. A service version scan (-sV) attempts to determine what software is running and its version. The NSE (Nmap Scripting Engine) extends this with scripts that can detect specific vulnerabilities, default credentials, and misconfigurations on discovered services. The -sC flag runs a default set of safe NSE scripts alongside the scan.
# Fast port discovery first
nmap -p- --min-rate=1000 -T4 192.168.1.1 -oN ports.txt
# Detailed scan on discovered ports only
nmap -sC -sV -p 22,80,443,8080 192.168.1.1 -oN detailed.txt
# Run specific NSE vulnerability scripts
nmap --script=http-title,http-headers,ssl-cert -p 443 example.comActive scanning has legal implications. Scanning systems without explicit written authorization is illegal in most jurisdictions under computer fraud laws. Always confirm your scope in writing before running any active scan. Bug bounty programs specify exactly which hosts and IP ranges are in scope. Do not scan anything outside those boundaries.
Automating Your Recon Workflow
Manual recon is thorough but slow. For repeated engagements or broad programs, automating the standard steps lets you focus your attention on the interesting findings rather than running the same commands repeatedly.
The approach I use is a simple bash pipeline that collects, resolves, and organizes results into a structured output directory. I keep everything in dated folders so I can compare results across time — new subdomains that appear between two scans often indicate new deployments worth investigating.
#!/usr/bin/env bash
TARGET=$1
DATE=$(date +%Y-%m-%d)
OUTDIR="recon/$TARGET/$DATE"
mkdir -p "$OUTDIR"
echo "[*] Starting passive recon for $TARGET"
# Subdomain enumeration
subfinder -d "$TARGET" -silent > "$OUTDIR/subs_subfinder.txt"
assetfinder --subs-only "$TARGET" > "$OUTDIR/subs_assetfinder.txt"
cat "$OUTDIR"/subs_*.txt | sort -u > "$OUTDIR/subs_all.txt"
# Resolve live hosts
cat "$OUTDIR/subs_all.txt" | dnsx -silent -resp > "$OUTDIR/live_hosts.txt"
# Grab HTTP titles for live web hosts
cat "$OUTDIR/live_hosts.txt" | httpx -title -status-code -silent \
> "$OUTDIR/web_hosts.txt"
echo "[*] Done. Results in $OUTDIR"
echo " $(wc -l < "$OUTDIR/subs_all.txt") subdomains found"
echo " $(wc -l < "$OUTDIR/live_hosts.txt") live hosts resolved"
echo " $(wc -l < "$OUTDIR/web_hosts.txt") web services detected"Recon-ng is a more structured framework for intelligence gathering, modeled after Metasploit's interface. It has modules for querying HaveIBeenPwned, Shodan, LinkedIn, and dozens of other sources. For engagements requiring comprehensive intelligence profiles, recon-ng helps keep findings organized in a database that can be queried and exported.
What Defenders Can Learn From This
Everything described in this article is a technique attackers use against organizations. But the same techniques are equally valuable to defenders who want to understand their own attack surface. Running a subdomain enumeration against your own domain reveals forgotten staging environments and forgotten services running outdated software. Searching GitHub for your organization's name and common credential patterns reveals accidentally committed secrets. Running Shodan against your IP ranges reveals exposed services your team may not know exist.
I call this attacker-perspective asset mapping. It is the exercise of periodically scanning your own external presence the way a motivated attacker would, before they do. Organizations that do this regularly find and fix exposures proactively. Those that do not often discover them through breach notifications.
The defensive value of recon is so high that dedicated tooling exists for it: SpiderFoot automates OSINT collection for asset monitoring, Amass has a tracking mode that alerts on new subdomains, and Shodan Monitor sends alerts when new services appear on your IP ranges. These are not offensive tools — they are the same information sources attackers use, repurposed for continuous defensive awareness.
Recon Checklist Before Any Engagement
This is the sequence I run through at the start of every authorized security engagement. The order matters — passive before active, broad before deep.
- Confirm written authorization and understand the exact scope boundaries before touching anything
- Run WHOIS lookups on all in-scope domains and map IP ownership ranges
- Query crt.sh certificate transparency logs for all subdomains under each domain
- Run subfinder, assetfinder, and amass in passive mode; deduplicate and resolve live hosts
- Search Shodan and Censys for all in-scope IP ranges; note any exposed services
- Search GitHub for the organization name, domain, and common credential patterns
- Download and analyze publicly accessible JavaScript bundles with LinkFinder
- Run content discovery against live web hosts using SecLists wordlists
- Run nmap service detection against in-scope hosts (confirm active scanning is authorized first)
- Document and organize all findings before moving to exploitation; version-control your output directory
