<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: performing-red-team-vulnerability-validation
description: >-
  Validate vulnerability findings through controlled red team exploitation to confirm exploitability and business impact.
domain: cybersecurity
subdomain: vulnerability-management
tags:
  - vulnerability-validation
  - red-team
  - exploit-verification
  - false-positive-reduction
  - risk-prioritization
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: ["T1190", "T1068", "T1210"]
---

# Performing Red Team Vulnerability Validation

## Overview

Scanner output is not ground truth. Red team validation confirms whether a reported vulnerability is actually exploitable in the target environment, narrows business impact, and eliminates false positives before remediation resources are committed. It also surfaces chained attack paths that scanners miss entirely.

Mode: `[MODE: RED]` — Authorized exploitation for verification. Document everything.

## Validation Decision Matrix

| Finding Type | Validation Priority | Approach |
|---|---|---|
| Critical CVSS + internet-facing | Immediate | PoC exploit in isolated lab, then target |
| Critical CVSS + internal only | High | Controlled exploitation on non-prod clone |
| High CVSS + chaining opportunity | High | Manual analysis + targeted PoC |
| Scanner-reported without PoC | Medium | Manual verification of preconditions |
| Low/info with sensitive data | Medium | Manual confirmation of data exposure |
| Infrastructure misconfiguration | Low | Config verification without exploitation |

## Validation Methodology

| Phase | Actions | Outputs |
|---|---|---|
| Reconnaissance | Confirm asset ownership, version fingerprint, attack surface | Validated target scope |
| Precondition check | Verify all CVE preconditions: auth level, network path, service version | Go/no-go decision |
| Lab reproduction | Reproduce in isolated environment matching target config | Confirmed exploitable |
| Impact assessment | Determine actual impact: data accessible, lateral movement possible | Business impact statement |
| Target validation | Execute minimal PoC on actual target with screenshot evidence | Confirmed exploitability in-scope |
| Chain analysis | Test whether vulnerability enables privilege escalation or lateral movement | Attack path documentation |

## Evidence Requirements

| Evidence Type | Required For | Format |
|---|---|---|
| Screenshot of exploitation | All confirmed findings | PNG with timestamp overlay |
| Request/response capture | Web vulns | Burp Suite export (.xml) |
| Proof file content | RCE, file read | Output of `id`, `hostname`, file hash |
| Network capture | Protocol-level vulns | Wireshark pcap |
| Chain diagram | Multi-step attack paths | Markdown or draw.io export |

## Severity Adjustment Criteria

| Condition | Adjustment | Rationale |
|---|---|---|
| Auth required (not anonymous) | -1 severity level | Reduced attack surface |
| No network path from internet | -1 severity level | Reduced exposure |
| Successful chaining to admin | +1 severity level | Amplified impact |
| Data confirmed sensitive | +1 severity level | Increased business risk |
| Compensating control effective | -1 severity level | Mitigated risk |
| Scanner false positive confirmed | Downgrade to Info | Eliminate from vuln backlog |

## Workflow

1. Obtain explicit written authorization scoping exploitation activities
2. Review scanner output and select candidates per decision matrix
3. Research CVE PoC availability and exploit complexity
4. Reproduce in lab environment — confirm exploitable before touching target
5. Validate target preconditions (version, config, network path)
6. Execute minimal targeted PoC — stop at demonstrated impact
7. Capture evidence per requirements above
8. Assess chaining opportunities
9. Adjust severity per criteria table
10. File updated finding with exploitation evidence and adjusted risk rating

## Common False Positive Patterns

| Vulnerability Class | Common FP Cause | Validation Check |
|---|---|---|
| SSL/TLS issues | Old TLS version reported but disabled | Verify with `openssl s_client` negotiation |
| Default credentials | Scanner tests default creds but app blocks them | Manual login attempt |
| Directory listing | Present but requires auth | Unauthenticated access check |
| Open redirect | Present but CSP blocks exploitation | Full PoC with browser |
| SQLi | Time-based blind reported but WAF blocks | Confirm without WAF bypass |

## Related Techniques

- [Performing CVSS Risk Scoring](../implementing-vulnerability-prioritization/SKILL.md)
- [Prioritizing Vulnerability Remediation](../managing-vulnerability-remediation-slas/SKILL.md)
