plan-engagement

Files (5)

• SKILL.md
• fork-protocol.md · references/
• intelligence-protocol.md · references/
• memory-schema.md · references/
• session-schema.md · references/

SKILL.md (first lines)

# Plan Engagement — Attack Graph Engine

## Philosophy

You are not filling out a form. You are an attack planner initializing a live intelligence system.

Extract everything from the user's message. Ask at most one question — only if the target itself is completely missing. Everything else has smart defaults. Your job is to generate a dynamic attack graph, not a static checklist, and hand the user a running start.

---

## Step 0: Bootstrap from Cross-Engagement Memory

Before anything else, read `~/.akira/memory.json` to seed this engagement with prior intelligence.

```bash
MEMORY=~/.akira/memory.json

# Read global SCL counter for this session
SCL_COUNTER=$(jq -r '.scl_id_counter // 1' $MEMORY 2>/dev/null || echo 1)

# Read ATW flagged techniques (hallucination guard)
FLAGGED=$(jq -r '.hallucination_guard | to_entries[] | select(.value.flagged==true) | .key' $MEMORY 2>/dev/null)

# Read DNA registry for pattern matching
DNA_REGISTRY=$(jq -r '.dna_registry' $MEMORY 2>/dev/null)

echo "Memory loaded. SCL counter: $SCL_COUNTER | Flagged techniques: $(echo $FLAGGED | wc -w)"
```

If `~/.akira/memory.json` does not exist:
```bash
mkdir -p ~/.akira
# Write initial memory.json with defaults - see references/memory-schema.md
# Set scl_id_counter to 1
```

**Use memory to calibrate hypothesis priors in Step 2:**
- Match extracted tech hints against `tech_vuln_priors` keys
- For each match, use stored `prior_probability` as the hypothesis starting point
- Do NOT exceed 0.85 even if memory says higher (anti-overfitting cap)
- Write `flagged_techniques` from `hallucination_guard` into `session.json scalpel.doom_loop`

---

## Step 1: Infer From the Message

Extract without asking:

| Extract | Source | Default if missing |
|---|---|---|
| Target | domain, IP, URL, app name in message | ask — only this |
| Program type | "bug bounty", "pentest", "CTF", "my lab" | bug_bounty |
| Platform | "HackerOne", "Bugcrowd", "Intigriti" | unknown |
| Tech hints | AWS, OAuth, GraphQL, checkout, LDAP | none |
| Constraint hints | "no active scan", "stealth", "out of scope" | none |
| Attack surface hints | "403s", "login page", "API", "internal" | none |

If the user says "api.stripe.com, found some 403s, AWS-backed" — you have target, hints for 403-bypass and cloud-audit, no questions needed.

---

## Step 2: Generate Hypotheses

Generate 4-6 ranked hypotheses — probabilistic attack chains grounded in what you know. These are not guesses; they are structured predictions that drive the entire engagement.

```
H1 [82%]  SSRF → AWS IAM credential extraction
          Evidence required: SSRF injection point + metadata endpoint reachable
          Boosted by signals: SSRF_VECTOR, TECH_DETECTED(AWS), INTERNAL_IP

H2 [71%]  OAuth open redirect → authorization code interception
          Evidence required: /oauth/authorize + redirect_uri param present
          Boosted by signals: JWT_FOUND, TECH_DETECTED(OAuth/SSO)

H3 [54%]  Race condition on checkout flow
          Evidence required: cart/coupon/transfer endpoint + timing gap
          Boosted by signals: SURFACE_FOUND(checkout), TECH_DETECTED(payments)

H4 [38%]  JWT RS256 → HS256 algorithm confusion
          Evidence required: JWT in responses + /jwks.json accessible
          Boosted by signals: JWT_FOUND, SURFACE_FOUND(jwks)
```

**Calibration rules** — update after every incoming signal:
- Signal matches `evidence_required` → +15-25% (specificity determines how much)
- Signal matches `boosted_by` list → +8-12%
- Signal directly contradicts hypothesis → -25-35%
- Hypothesis hits 0-15% → mark DENIED, log to `tested_surfaces`, never retest
- Hypothesis hits 85%+ → immediately transition engagement to DEEP state
- Hypothesis hits CONFIRMED → write finding to `report_draft.findings[]`, continue

---

## Step 3: Auto-Activate Modules

Core chain always active: `recon → secrets → exploit → triage → report`

Auto-flag additional modules based on extracted signals and hints:

| Signal / keyword detected | Module flagged |
|---|---|
| AWS / S3 / Lambda / IAM / GCP / Azure / cloud | `cloud-audit` |
| 403 / forbidden / blocked / WAF hint | `403-bypass` |
| OAuth / SSO / OIDC / JWT / login | `oauth-attacks` |
| checkout / cart / coupon / wallet / transfer / balance | `race-conditions` |
| AD / LDAP / Kerberos / domain controller / corporate | `redteam` (canonical AD chain - ad-attacks is a redirect stub) |
| GraphQL / introspection | `zerodayhunt` (GraphQL focus) |
| red team / APT / assumed breach / lateral movement / post-exploitation / C2 / persistence / ADCS / DCSync / Kerberoast / BloodHound / Windows domain / internal network | `redteam` |

**CTF isolation:** `ctf` module ONLY activates when the user explicitly declares "CTF mode", mentions a CTF platform (HackTheBox / TryHackMe / PicoCTF / CTFtime), or uses the `/ctf` command directly. Keyword "flag" alone in a pentest context does NOT trigger ctf - it means a flag in the sense of flagged vulnerability. Never auto-activate ctf during a live pentest or bug bounty engagement.

Flagged modules activate when the main chain reaches Phase 3 or a relevant signal confirms them.

---

## Step 4: Initialize session.json

Create `~/pentest-toolkit/results/<target>/`:

From kalpmodi/akira, MIT.

More from kalpmodi/akira