Thomas Siegbert IT-Security Consultant

Article

Recon for Beginners – A Structured Search for Vulnerabilities

Published

A practical introduction to structured reconnaissance, safe testing environments, suitable tools, and reproducible example workflows.

Logo

In this article, I explain what to consider during reconnaissance, which tools to use, and what a structured recon workflow can look like.

Summary (TL;DR)

Recon is the systematic collection of information about a target to identify potential attack surfaces. Start with the scope, collect subdomains and hosts, enumerate services through port and service scans where appropriate and permitted, gather content from sources such as Wayback and public files, search for directories and endpoints through fuzzing, and focus on low-hanging fruit such as outdated software, exposed debug endpoints, and endpoints prone to XSS, IDOR, or SQLi. Work reproducibly with notes, screenshots, and minimally invasive tests. Operate only within the permitted scope and in testing environments.

1. Mindset and Rules (Important!)

  • Legality first: Check the program’s scope, including URL lists, subdomain rules, and authorized IP addresses. Do not attack anything outside the scope without explicit permission.
  • Ethics and communication: If you find a potentially critical vulnerability, keep testing minimally invasive and document your steps. Report it responsibly through the program or platform.
  • Safe environment: Use local labs such as DVWA, WebGoat, Burp Academy, or HackTheBox Labs, or dedicated targets. Never destroy or exfiltrate live data. Tip: Use a VM for your in-scope tests and analyses.
  • Reproducibility: Conduct reconnaissance in clear stages and document commands, timestamps, and results.

2. Recon Phases — Overview

  1. Define scope and targets — What is permitted? Which subdomains and IPs?
  2. Passive recon — OSINT, certificates, DNS, and Wayback without sending active traffic to the target.
  3. Active recon — Port scans, service enumeration, and directory fuzzing.
  4. Content discovery — Endpoints, parameters, files, and JavaScript files.
  5. Light vulnerability hunting — Targeted, low-risk tests such as reflected XSS proofs of concept.
  6. Reporting — Reproducible findings with a PoC and recommendations.

3. Preparation — Read the Scope Carefully

  • Read the program scope carefully: permitted subdomains, paths, parameters, and exceptions.
  • Note excluded tests such as DoS, social engineering, and physical access.
  • If something is unclear, use the program’s contact option before testing. Reserve questions for genuine ambiguity rather than every small detail.

4. Passive Recon — What to Collect

Objective: Gather as many clues as possible without sending direct traffic to the target.

  • Subdomains and certificates: Search Certificate Transparency logs such as crt.sh and Censys for subdomains.
  • Note wildcards and subdomain patterns such as api., dev., staging., admin., and mail.

DNS

  • A/AAAA, MX, TXT (SPF, DMARC), NS, and CNAME records can reveal internal clues.
  • Reverse DNS can identify cloud or CDN providers such as CloudFront and Akamai.

WHOIS / Hosting

  • Registrar, hosting provider, and ASN information can help when researching IP blocks. Use this for information only.

Web Archive / Wayback

  • Old endpoints, URLs, parameters, and comments may reveal former admin URLs or debug pages.

JavaScript and Public Repositories

  • Review public JavaScript files, GitHub or GitLab repositories, and S3 buckets for exposed configuration data.

Leak Searches

  • Paste sites, Stack Overflow, and job advertisements can contain internal clues such as IP addresses or API URLs.

5. Tools and Typical Commands (Beginner-Friendly)

Note: You do not need every tool. Choose a set that you are comfortable with.

Useful CLI Tools and Examples

  • dig / nslookup — DNS queries Example: dig +short A api.example.com
  • Passive or automated subdomain discovery: subfinder, amass (amass passive), assetfinder Example: subfinder -d example.com -silent
  • Certificate enumeration: crt.sh manually or through its API; no command line is required.
  • httpx or curl — checks whether a host is reachable and returns its title and status Example: echo subs.txt | httpx -status-code -title -threads 50
  • Port scanning: nmap Quick scan: nmap -sS -Pn -T4 -p- --min-rate 1k 10.0.0.5 Service/version: nmap -sV -sC -p 22,80,443 10.0.0.5
  • Directory fuzzing: ffuf, gobuster, dirsearch Example: ffuf -w wordlist.txt -u https://example.com/FUZZ -mc 200,301,302 -t 40
  • Wayback/archive tooling: waybackurls or gau (getallurls) Example: echo example.com | waybackurls > wayback.txt
  • JavaScript discovery: linkfinder, gf with regex patterns, retire (dependency check)
  • Parameter and endpoint scraping: paramspider, arjun (parameter finder)
  • URL discovery and filtering: qsreplace, gf, httpx, and dalfox for XSS scanning in later stages

GUI / Web Tools (Beginners)

  • Burp Suite Community — proxy, scanner, and Intruder for reproducible interaction
  • OWASP ZAP — open-source alternative to Burp
  • Web-based labs: PortSwigger Academy, HackTheBox, and TryHackMe for practice

6. Practical Recon Workflow (Step by Step)

The following is a concrete workflow you can follow one step at a time.

Step A — Passive Subdomain Collection

  1. subfinder -d example.com -o subs_raw.txt
  2. amass enum -passive -d example.com -o amass_passive.txt
  3. cat subs_raw.txt amass_passive.txt | sort -u > subs_all.txt

Step B — Check Which Subdomains Are Live

  1. cat subs_all.txt | httpx -threads 50 -status-code -title -o subs_alive.txt
  2. Filter internal, forbidden, and similar hosts. Record 200/301/302/403 responses and TLS information.

Step C — Port / Service Scan (Only for In-Scope IPs!)

  1. nmap -sS -Pn -T4 -p- –min-rate 1000 -oA fullscan (only if the IP range is in scope)
  2. More typical for web hosts: nmap -sV -p 80,443,8080,8443 –script=http-enum

Step D — Content Discovery (Wayback + Fuzzing)

  1. echo target.com | waybackurls > wayback.txt
  2. cat wayback.txt | grep -E ‘.js$’ | sort -u > jsfiles.txt
  3. ffuf -w common_dirs.txt -u https://sub.example.com/FUZZ -o ffuf_sub_example.txt

Step E — JavaScript Analysis (APIs, Endpoints, Keys)

  1. Download JavaScript files: httpx + xargs -n1 curl -s > file.js
  2. Search for endpoint, api, token, and Bearer with grep/ripgrep.
  3. Record discovered API URIs, parameters, and possible IDs.

Step F — Parameter/Endpoint Enumeration

  1. paramspider -d https://sub.example.com -o params.txt
  2. For each endpoint, identify GET/POST parameters and optional ID parameters as candidates for IDOR/SQLi/XSS.

Step G — Prioritization

  • Prioritize endpoints by whether they are accessible without authentication.
  • Sensitive functionality such as password resets, file uploads, and admin panels
  • Input parameters such as IDs, filenames, and queries
  • Signatures of old or outdated software

7. Common Low-Hanging Fruit in Recon

  • Exposed admin/dashboard URLs, such as /admin, /manage, or /wp-admin on WordPress.
  • Unpatched software, including old version strings in HTML or headers.
  • Unvalidated file uploads, such as upload endpoints without content-type checks.
  • API endpoints found in JavaScript with missing or weak authentication.
  • IDOR: Predictable IDs such as /user/123/profile; test other IDs only safely and in scope.
  • Reflected XSS in query parameters, search fields, or returned fields.
  • Insecure CORS or misconfigured HSTS/HTTPS/Content-Security-Policy.

8. Example: A Short Recon Session

  1. Target: sub.example.com (in scope).
  2. httpx returns status 200 and Example App.
  3. curl requests https://sub.example.com/static/app.js; the JavaScript contains /api/v1/users/{id} and https://api.internal.example.com.
  4. ffuf finds /admin, which returns a 302 redirect to /admin/login.
  5. paramspider finds a ?q= parameter; test it for reflected XSS with a harmless payload (alert(1)) only if this is in scope and low risk.
  6. Result: A visible API endpoint and an exposed admin URL, which can be prioritized for careful tests of authentication and access control.

9. How to Test Safely (Safe PoCs)

  • Use harmless, non-destructive payloads, for example '' for reflected XSS.
  • Do not exfiltrate data or send large numbers of requests; avoid DoS.
  • Repeat a test only as often as necessary to demonstrate reproducibility.
  • Screenshots and request/response data from Burp or HTTPie are often sufficient for a PoC.

10. Documentation and Report Template (Brief)

  • Title: Short, meaningful heading
  • Target/scope: Affected host or subdomain, date, and time in UTC
  • Severity: Suggested Low/Medium/High/Critical rating
  • Description: What is the problem, and why does it matter?
  • Proof of concept: Reproducible steps, requests, a minimal payload, screenshots, and response snippets
  • Impact: Possible consequences such as account takeover, data leakage, or RCE
  • Mitigation: Specific recommendations such as input validation, authorization checks, rate limiting, or CSP
  • Attachments: Burp logs, curl commands, and nmap output
  • Wordlists: common, big.txt, raft-large-directories, discovery
  • JavaScript analysis: Search for api, endpoint, token, client_id, aws, and s3
  • Training targets: PortSwigger Academy, OWASP Juice Shop, WebGoat, DVWA, and HackTheBox / TryHackMe web rooms.

12. Efficiency Tips (Save Time)

  • Automate your pipeline: Subdomain → httpx → Wayback/JavaScript scraping → ffuf on discovered hosts.
  • Use jq, ripgrep, and sed/awk for quick extraction from output.
  • Use parallel threads sensibly while respecting rate limits and DoS risks.
  • Maintain a personal recon playbook with commands, preferred wordlists, and notes.

13. Why Duplicate Reports Are Not Always Bad

  • A duplicate may still be valid and counted by some platforms, especially if it has been confirmed or you add details such as a PoC or impact.
  • In some programs, early duplicates have led to invitations to private programs. A duplicate often proves that you work quickly and reliably.
  • Recommendation: Add value to a duplicate with a better PoC, additional affected endpoints, or exploit prevention guidance.

14. Common Beginner Mistakes and How to Avoid Them

  • Scanning too aggressively → the program blocks your IP or host. Read the rate limits.
  • Poor scoping or overlooking subdomains → missed opportunities.
  • No documentation → results cannot be reproduced.
  • Blind crawling of sensitive endpoints → avoid destructive actions.

15. Example Checklist (Quick Recon Checklist)

  • Scope read and documented
  • Passive subdomain list created
  • Live hosts identified with httpx
  • Ports and services scanned with nmap within the scope
  • Wayback/archive URLs saved
  • JavaScript files parsed and API endpoints recorded
  • Directory fuzzing performed with ffuf/gobuster
  • Parameter list created with paramspider/arjun
  • Prioritized test list created for unauthenticated and high-impact targets
  • Minimal PoC prepared and documented
  • Report template completed

16. Continue Learning — Practice Tasks

  • Conduct reconnaissance against a training target such as Juice Shop and document every phase.
  • Automate subdomain → httpx → JavaScript scraping → ffuf as a small shell script.
  • Write a report based on your exercise and compare it with official write-ups.

Closing Thoughts

Recon is a skill that improves greatly through a systematic approach and practice. Start small, work carefully, and document everything. Stay within the scope and the law—this makes you a trustworthy researcher to whom companies are happy to award bounties.