| name | perseus:exploit |
| description | Use when verifying vulnerabilities with Dynamic Exploit Generation (Phase 3) |
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
- Select Findings: Pull only exploit candidates from Audit and specialists.
- Apply Mode Gate: Choose validation technique allowed by current mode.
- Execute Minimal Proof: Validate impact with smallest safe signal.
- Record Evidence: Save request/response and exact indicator.
- 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
- 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.
- XSS Verifier (DOM/Reflected):
- Validate with harmless payload markers (e.g.,
alert(1) pattern detection).
- Avoid persistent or high-volume payload testing on production.
- Auth Verifier:
- Test session and workflow bypass only with test accounts and approved IDs.
- Do not lock, disable, or mutate real user accounts.
- Authz Verifier:
- Validate role boundary checks with synthetic or designated test records.
- Stop on any indication of real data exposure beyond approved scope.
- 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:
- Entry vector confirmation (input validation bypass candidate)
- Privilege boundary test (horizontal/vertical authz)
- Sensitive action guard test (critical workflow controls)
- 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.