Evidence Documentation & Proof-of-Concept Standards

Prerequisites

• STE-K002: Test Case Design & Evidence Standards
• STE-K009: CVSS Scoring

Why This Lesson Matters

The difference between a finding that gets fixed immediately and one that gets deprioritised is not the severity score — it is the quality of the evidence. A well-documented finding with clear screenshots, a minimal reproducible PoC, and a one-sentence fix is impossible to ignore. A vague finding with a screenshot of an error message and no reproduction steps sits in a backlog forever.

1. What a Complete STE Finding Contains

Finding ID:           F007
Title:                Vertical Privilege Escalation via Role Parameter Manipulation
Severity:             Critical
CVSS v3.1:            AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N = 9.8
Control reference:    CSS-AC01 — Role-based access control
Test case:            TC-AC01-007
Status:               FAIL

Affected component:   POST /api/users/update-role
                      https://app.corp.local/api/users/update-role

Description:
  An authenticated user with role VIEWER can elevate their own account to
  role ADMIN by including "role": "admin" in the account update request body.
  The server does not validate that only administrators can assign the admin role.

Reproduction steps:
  1. Authenticate as a VIEWER-role user (credentials: viewer01 / TestPass123!)
  2. Open Burp Suite Repeater and send:
       POST /api/users/update-role HTTP/1.1
       Authorization: Bearer VIEWER_TOKEN
       Content-Type: application/json
       {"user_id": "VIEWER-USER-ID", "role": "admin"}
  3. Observe HTTP 200 response
  4. Send GET /api/users/me — observe "role": "admin" in response
  5. Access GET /admin/dashboard — observe full admin access

Evidence:
  EX-031: HTTP request showing role: admin in body with VIEWER token
  EX-032: HTTP 200 response to the update-role request
  EX-033: GET /api/users/me response showing role: admin
  EX-034: GET /admin/dashboard returning admin content

Business impact:
  Any authenticated user can self-assign admin privileges, gaining access to
  all administrative functions including user management, data export, and
  configuration changes. This completely bypasses the role-based access
  control requirement.

Remediation:
  Immediate (24 hours): Add server-side check that only ADMIN-role users
  can assign the admin role. Example (Node.js):
    if (req.user.role !== "admin") return res.status(403).json({error:"Forbidden"});

  Long-term (30 days): Review all privilege-modifying endpoints for the same
  pattern. Implement a centralised authorisation middleware.

References:
  OWASP Top 10: A01:2021 — Broken Access Control
  ATT&CK: T1078 — Valid Accounts (privilege escalation variant)

2. Minimal Reproducible PoC

A PoC must do exactly one thing: prove the vulnerability exists. Nothing more.

Bad PoC: "Run sqlmap -u https://target --dbs --dump-all"
  → Downloads entire database. Violates minimum necessary principle.

Good PoC: "SELECT version()"
  → Proves injection. Returns the DB version. No data exfiltrated.

Bad PoC: "Install a web shell and execute id"
  → Shell installs persistence. May crash the service.

Good PoC: "curl the upload endpoint with a .php file containing <?php echo 1+1; ?>"
  → Proves RCE. Returns '2'. No system commands. No persistence.

The minimum PoC test: Ask: "Does this PoC prove the control fails?" If yes and it does nothing more, it is minimal. If it does more than prove the control fails, trim it.

3. Screenshot Standards (Detailed)

Every screenshot used as evidence must pass these four checks:

Check 1 — Target visible:
  The URL bar or hostname must be visible in the screenshot.
  "HTTPS errors on app.corp.local" not "HTTPS errors on some site"

Check 2 — Request context visible:
  For HTTP findings: Burp Repeater showing the full request AND response in one frame.
  Set Burp to "Show Response" view and screenshot both panes.

Check 3 — Timestamp visible:
  Either: the OS taskbar clock visible in the screenshot
  Or:     Burp Logger timestamp
  Or:     HTTP response Date: header

Check 4 — Evidence claim matches:
  If you claim "200 OK returned user data," the screenshot must show the
  200 status code AND the user data fields. Partial evidence proves nothing.

4. Chaining Evidence Across Multiple Steps

For multi-step findings (like the privilege escalation above), each step needs evidence:

Step 1 evidence → proves starting state (VIEWER role confirmed)
Step 2 evidence → proves the attack action (role: admin in request)
Step 3 evidence → proves success (role: admin in response)
Step 4 evidence → proves impact (admin dashboard accessible)

Each piece reinforces the chain. Without step 1, a reviewer might ask:
"How do we know VIEWER was the starting role, not admin?"

5. Common Mistakes

Mistake 1: One screenshot for a multi-step finding. A finding that says "we escalated from VIEWER to ADMIN" with only a screenshot of the admin dashboard does not prove how it happened. Document every step.

Mistake 2: Screenshots in Word documents with captions as the only evidence description. Evidence should be referenced from the finding text with a specific exhibit ID (EX-031). "See screenshot above" is not a finding citation.

Mistake 3: PoC that creates irreversible changes. A PoC that deletes a record, modifies a balance, or corrupts data to prove a vulnerability is unacceptable in an STE. Always use test data, and always clean up.

6. Practice Exercises

1. Write the full finding template for: "A VIEWER user can view all other users' profiles by modifying the user ID in GET /api/users/{id}." Include 3 evidence items, a minimal PoC, and the remediation recommendation.

2. Evaluate this PoC: "We uploaded a PHP shell to /uploads/cmd.php and ran ls /var/www/html to list server files." Is this minimal? What should it have done instead?

3. A finding screenshot shows an HTTP 200 response body with user data but the URL bar is not visible. What does an auditor argue, and how do you fix the evidence?

7. Lab

Assessment mode: flag

challenge_spec_id: 182 — Logic-based privilege escalation

Task: 1. Authenticate as a low-privilege user 2. Identify the parameter that controls role assignment 3. Manipulate it to escalate your role 4. Access the admin area to retrieve the flag

8. Framework Alignment

9. Further Reading

• Bugcrowd VRT — https://bugcrowd.com/vulnerability-rating-taxonomy — Finding documentation standards
• SWGDE Digital Evidence Documentation Best Practices — Applicable to STE evidence
• PortSwigger Burp Suite documentation — Screenshots and evidence export features

["Write a complete STE finding with all nine fields for a described access control bypass, including four numbered evidence items with specific exhibit IDs", "Evaluate a described PoC and determine whether it is minimal — if not, rewrite it to prove the same control failure with the smallest possible action", "Apply the four screenshot standards to evaluate three provided screenshots and identify which evidence items are acceptable, which need re-capture, and why"]

Prerequisites → Why this matters → Complete STE finding structure (9-field template with worked example) → Minimal reproducible PoC (bad vs good examples) → Screenshot standards (4 checks) → Chaining evidence across steps → Common mistakes → Practice exercises → Lab (flag, spec 182) → Framework alignment → Further reading