Exploit

Perseus Exploit (Phase 3 - Advanced)

Overview

This skill executes the Verification Phase with controlled exploit simulation. Instead of blind payload spraying, Perseus validates each finding with environment-aware, low-risk proofs.

Goal: Reduce false positives while preserving production safety and service stability.

Safety Rule: Never run destructive actions. Never degrade availability.

Engagement Modes

Mode	Environment	Verification Depth
PRODUCTION_SAFE	Live production	Passive-first checks + minimal non-disruptive proofs
STAGING_ACTIVE	Staging/pre-prod	Targeted active verification with strict throttling
LAB_FULL	Isolated lab	Full dynamic verification and payload mutation
LAB_RED_TEAM	Dedicated security lab	Multi-step chain simulation and resilience stress tests

If mode is not explicitly provided, default to PRODUCTION_SAFE.

Verification Methodology

1. Select Findings: Pull only exploit candidates from Audit and specialists.
2. Apply Mode Gate: Choose validation technique allowed by current mode.
3. Execute Minimal Proof: Validate impact with smallest safe signal.
4. Record Evidence: Save request/response and exact indicator.
5. Classify Outcome: VERIFIED, FAILED, or POTENTIAL-PROD-BLOCKED.

Kill-Switch Policy (All Active Modes)

Immediately pause verification and mark run as ABORTED-SAFETY when any threshold is exceeded:

• sustained error-rate spike above approved baseline
• p95 latency increase above approved threshold
• service healthcheck degradation
• explicit stop signal from operator

Execution Instructions

Step 0: Confirm Scope and Limits

Create/update deliverables/verification_scope.md with:

• mode
• in-scope targets
• excluded systems
• request-rate limit
• approved test window

Step 1: Launch 5 Verifiers in Parallel

1. Injection Verifier (SQLi/CMD):
   • Validate with safe boolean/time indicators and strict request caps.
   • For PRODUCTION_SAFE, limit to replay-like checks and non-invasive timing tests.
2. XSS Verifier (DOM/Reflected):
   • Validate with harmless payload markers (e.g., alert(1) pattern detection).
   • Avoid persistent or high-volume payload testing on production.
3. Auth Verifier:
   • Test session and workflow bypass only with test accounts and approved IDs.
   • Do not lock, disable, or mutate real user accounts.
4. Authz Verifier:
   • Validate role boundary checks with synthetic or designated test records.
   • Stop on any indication of real data exposure beyond approved scope.
5. SSRF Verifier:
   • PRODUCTION_SAFE: static and configuration-based verification only.
   • STAGING_ACTIVE/LAB_FULL/LAB_RED_TEAM: controlled callback validation using approved endpoint only.

Step 1.5: Chain Simulation (LAB_RED_TEAM only)

Run controlled attack-chain validation on synthetic test data:

1. Entry vector confirmation (input validation bypass candidate)
2. Privilege boundary test (horizontal/vertical authz)
3. Sensitive action guard test (critical workflow controls)
4. Detection/response check (logging, alerting, blocking)

Record where the chain is broken and which control stopped progression.

Step 2: Adaptation Policy

• PRODUCTION_SAFE: maximum 2 attempts per finding, then mark POTENTIAL-PROD-BLOCKED.
• STAGING_ACTIVE: allow targeted payload variation with throttling.
• LAB_FULL: allow broader mutation strategies, still non-destructive.
• LAB_RED_TEAM: allow chain-based scenario replay with hard caps per scenario.
• In all modes, stop immediately on instability signs (latency spikes, error floods).

Output Requirements

For each verified exploit, log the result in deliverables/exploitation_report.md:

• Finding ID
• Mode: PRODUCTION_SAFE | STAGING_ACTIVE | LAB_FULL | LAB_RED_TEAM
• Target: URL/File + Parameter
• Technique: Brief verification method
• Evidence: Request/response or code-level proof
• Attempts: Request count used
• Result: VERIFIED | FAILED | POTENTIAL-PROD-BLOCKED | ABORTED-SAFETY
• Confidence: High | Medium | Low

Next Step: Proceed to perseus:report to document the verified findings.