AI agent skill · by @kaivyy

Perseus:Exploit

Use when verifying vulnerabilities with Dynamic Exploit Generation (Phase 3)

Archived 2026-10-23 · Source updated 2026-02-23 · License: MIT. Check the original repository for the latest version.

SKILL.md instructions

# 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.