Screenshot & Evidence Guide

Professional evidence documentation is critical for credible, actionable penetration testing reports. This guide covers best practices for capturing, annotating, and presenting screenshots and other evidence.

Capture Annotate Organize Tools

Why Evidence Quality Matters

Poor evidence can undermine your entire report. Clients may dispute findings without clear proof, and incomplete evidence makes remediation difficult. Professional screenshots demonstrate competence and build trust.

Capture Guidelines

DO

Capture before, during, and after exploitation
Include timestamps when possible (terminal, browser, etc.)
Show the full context - URL bar, tool output, target information
Capture error messages exactly as displayed
Use high resolution (at least 1080p)
Include source IP in terminal screenshots when relevant
Save both raw and annotated versions

DON'T

Capture personal data (SSNs, credit cards, passwords) beyond minimum needed
Use low-quality or blurry images
Crop out important context like URLs or tool versions
Include unnecessary personal information (desktop icons, bookmarks, etc.)
Capture sensitive client data in bulk
Forget to redact out-of-scope information
Use screenshots with other client information visible

What to Capture for Each Finding

Web Application Findings

HTTP request showing the vulnerability
HTTP response proving exploitation
Browser view showing impact
Burp Suite/ZAP intercept view
Cookie/session manipulation proof
Error messages or stack traces

Network/Infrastructure Findings

Nmap scan output with relevant ports
Vulnerability scanner results
Successful exploitation (Metasploit, etc.)
Shell/session access proof
Privilege escalation steps
Lateral movement evidence

Authentication Findings

Login attempt and response
Password policy bypass proof
Session token analysis
MFA bypass demonstration
Account enumeration responses
Credential stuffing results

Active Directory Findings

BloodHound attack paths
Kerberoasting/AS-REP roasting results
Domain admin proof (whoami, etc.)
DCSync/credential dump proof
GPO abuse demonstration
Trust relationship exploitation

Annotation Best Practices

Essential Annotation Elements

Highlight Boxes

Use red boxes to draw attention to the vulnerability or key evidence

Arrows & Pointers

Use arrows to guide the reader's eye to specific elements

Text Callouts

Add brief explanatory text to clarify what the screenshot shows

Recommended Color Coding

Red

Vulnerability, attack vector, malicious input

Green

Successful exploitation, obtained data

Yellow

Important context, warnings

Blue

Explanatory notes, step numbers

Annotation Examples

Good Annotation

POST /api/login HTTP/1.1
Host: target.com
Content-Type: application/json

{"username":"admin' OR '1'='1","password":"x"}

① SQL Injection Payload

HTTP/1.1 200 OK
{"status":"success","user":"admin"}

② Authentication Bypassed

Poor Annotation

POST /api/login HTTP/1.1
Host: target.com
Content-Type: application/json

{"username":"admin' OR '1'='1","password":"x"}

Problems:

No highlighting of payload

No explanation of what to look for

Response not shown

Low contrast / hard to read

Redaction Guidelines

Sensitive Data Handling

Always redact sensitive data that isn't necessary to prove the vulnerability. Over-exposure of client data can create legal and ethical issues.

Always Redact

Full Social Security Numbers
Complete credit card numbers
Full passwords (show partial if needed)
Personal health information (PHI)
Customer PII beyond minimum proof
Internal employee personal data
API keys and secrets (show partial)

Redaction Methods

Black box: Complete obscuring
Blur: Visual obfuscation
Partial mask: Show first/last chars (****1234)
[REDACTED] text: Clear indication
Pixelation: For images
Never use highlight-only - data can be recovered

File Organization

Recommended Folder Structure

folder-structure.txt

project-engagement/
├── evidence/
│   ├── raw/                    # Unedited screenshots
│   │   ├── 001_initial_scan.png
│   │   ├── 002_sqli_request.png
│   │   └── 003_sqli_response.png
│   │
│   ├── annotated/              # Edited/annotated versions
│   │   ├── 001_initial_scan_annotated.png
│   │   ├── 002_sqli_request_annotated.png
│   │   └── 003_sqli_response_annotated.png
│   │
│   ├── burp/                   # Burp Suite exports
│   │   ├── sqli_request.xml
│   │   └── xss_request.xml
│   │
│   ├── scans/                  # Tool output
│   │   ├── nmap_full.txt
│   │   ├── nessus_export.pdf
│   │   └── nikto_results.txt
│   │
│   └── logs/                   # Terminal/tool logs
│       ├── metasploit.log
│       └── crackmapexec.log
│
├── report/
│   ├── draft/
│   └── final/
│
└── notes/
    └── testing_notes.md

File Naming Convention

[SEQ]_[FINDING-ID]_[DESCRIPTION]_[VERSION].png

Examples:

001_VULN-001_sqli_login_request.png
002_VULN-001_sqli_login_response.png
003_VULN-002_xss_payload_annotated.png
004_VULN-003_privesc_before.png
005_VULN-003_privesc_after.png

Benefits:

Sequential ordering for narrative flow
Easy finding cross-reference
Clear description at a glance
Version control (raw vs annotated)
Alphabetical sorting works correctly

Recommended Tools

Screenshot Tools

Flameshot Free/Linux
Greenshot Free/Windows
ShareX Free/Windows
Snagit Paid
CleanShot X Mac

Annotation Tools

GIMP Free
Paint.NET Free/Windows
Skitch Free
Figma Free tier
Adobe Photoshop Paid

Terminal Recording

asciinema Free
script (built-in) Free/Linux
termtosvg Free
OBS Studio Free
tmux logging Free

Terminal Recording Setup

terminal-recording.sh

# Using script (built-in Linux/Mac)
script -t 2>timing.txt output.txt    # Start recording
# ... do your testing ...
exit                                  # Stop recording

# Replay
scriptreplay timing.txt output.txt

# Using asciinema
asciinema rec pentest_session.cast   # Start recording
# ... do your testing ...
# Press Ctrl+D to stop

# Convert to GIF
asciinema-agg pentest_session.cast output.gif

# Using tmux with logging
# Add to ~/.tmux.conf:
set -g history-limit 50000
bind-key H pipe-pane -o "exec cat >>$HOME/tmux_logs/`date +%Y%m%d%H%M`.log" \; display-message "Logging started"
bind-key h pipe-pane \; display-message "Logging stopped"

Burp Suite Evidence Export

Export Options

Right-click request in Proxy/Repeater
Select "Copy as curl command" for CLI reproduction
Select "Save item" for XML export
Use "Generate CSRF PoC" for CSRF findings
Export Scanner issues as HTML report

Screenshot Tips

Enable "Show non-printable characters"
Use Inspector panel for clean evidence
Highlight relevant headers/parameters
Include both Request and Response tabs
Show match/replace rules if used

When to Use Video Evidence

Good Use Cases for Video

Complex multi-step attack chains
Race conditions or timing attacks
Client-side vulnerabilities (clickjacking)
Social engineering demonstrations
Physical security bypass
Real-time privilege escalation

Video Considerations

Keep videos short (under 2 minutes)
Add text overlays explaining each step
Use screen zoom for important details
Compress files for report inclusion
Provide both video and key screenshots
Host videos securely if too large

Evidence Quality Checklist

Pro Tip

Create a screenshot "template" in your annotation tool with pre-configured arrows, boxes, and text styles. This ensures consistency across all your reports and saves significant time.

Likely False Positives

A capture can be completely accurate and still mislead the reader. These are the packs that fail review after the finding itself has been accepted.

Capture of the tool, not the target: A proxy pane or terminal window shown without the browser result proves the tool ran, not that the application did anything.
Lab replica presented as production: Reproducing on a stand-in build is worth showing, but only if the caption says so; otherwise the client reads it as their system.
Redaction that removes the evidence: Blurring the parameter that carried the payload leaves a picture of a blocked request and no finding at all.
Unpaired request and response: A response capture alone cannot show what was sent; a request capture alone cannot show that anything changed.
Cropped origin: A capture whose host or URL is not in frame cannot be tied to the asset named in the finding.
One image reused across findings: The same screenshot attached to three findings suggests the other two were never independently confirmed.
Timestamp outside the assessment window: A capture taken before the test started, or after a retest, undermines the finding it illustrates.
Annotation pointing at an inference: A circle drawn around a value that is suggestive rather than conclusive invites the client to test the claim and find it thin.

Fixing the Evidence Pack

Re-capture

• Replace any capture where the origin or the payload is not visible
• Pair every response image with its request image
• Re-shoot at a resolution that survives PDF export and printing

Redaction

• Redact values and keep the keys and parameter names
• Re-check the raw file after redaction rather than the annotated export
• Confirm no third-party client identifiers remain in tool panes or browser tabs

Organisation

• Rename files to the finding ID plus a sequence number
• Confirm the pack folder matches the structure the report references
• Reconcile the appendix against the pack so nothing is referenced and missing