perseus: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

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.