@murk-security/runner-darwin-x64 0.0.0-stage → 0.7.1

package/runners/skills/exploit/credential-chaining/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: credential-chaining
+description: Turn a recovered secret into reach — stash a credential/token/key/id you extract (from a JS bundle, an IDOR, an error, a response body) and replay it on later requests to prove the next hop, then record the chain so a multi-step compromise is reported end to end, not as scattered single findings.
+when-to-use: you have recovered something that looks usable — an API key in a JS/source-map, a bearer token or cookie from a response, an internal id or endpoint — and you want to prove what it actually unlocks, or you have several findings that together form one escalation and need to report the chain.
+surface: web
+severity: high
+tier: safe-active
+---
+
+# Credential chaining & kill-chain reporting
+
+A non-destructive playbook for the `loot`, `http`, and `diff` ops. Single findings
+under-state risk; criticals are usually *chains* — a leak enables access, which
+yields a credential, which unlocks data. `loot` is structured memory for exactly
+that: it carries a recovered credential forward (the third credential source beside
+static identities and `login` sessions — this one for values YOU recovered) and
+records the edges between findings so the report shows the whole path.
+
+## 1. Recognize loot
+As you probe, watch for anything replayable: an API key or token in a JS bundle or
+source-map (`http` with `grep`), a bearer token or session cookie in a response, an
+internal id, a hidden endpoint, a password in a verbose error. If you could send it
+on another request, it is loot.
+
+## 2. Stash it with its source
+`loot {"action":"stash","kind":"bearer","value":"<the token>","source":"/account",
+"note":"alice api key"}`. Pick `kind`: `cookie`, `bearer` (default), or `header`
+(give `value` as `"X-API-Key: abc"`). You get back a loot id. The `source` is the
+evidence for this hop — the request that yielded the credential.
+
+## 3. Replay it to prove the next hop
+Send the stashed credential on a later request by reference:
+`http {"path":"/api/privileged","loot":"loot-1"}`. The adapter injects it (only for
+the origin host, like an identity). A response you could NOT reach anonymously, now
+reachable with the replayed credential, proves the hop. Use `diff` to show it
+crisply: the same endpoint anonymous vs. with `loot`.
+
+## 4. Record the chain edge
+`loot {"action":"link","from":"/account (authenticated)","to":"loot-1",
+"note":"account view leaked the api key"}` then
+`loot {"action":"link","from":"loot-1","to":"/api/privileged",
+"note":"key unlocked all users' SSNs"}`. Edges are free-form (ids or short labels) —
+they capture *A enabled B*. `loot {"action":"list"}` returns the loot and edges.
+
+## 5. Distinguish a real chain from a dead end
+Only a hop if the replayed credential actually reaches something it should not, or
+something new. A stashed value that still returns 401/403 is NOT a hop — it proves
+the opposite (good access control), so do not claim it. A credential replayed to the
+resource it was *issued* for is expected, not a finding.
+
+## Evidence & severity
+Report the chain as an ordered path: each hop cites the request that yielded the
+credential and the request that the credential unlocked. A chain that reaches
+another principal's data, an admin function, or a tenant boundary is high — critical
+when it ends in full account/admin takeover or a mass data dump. Replay recovered
+credentials for READ proof only; never use one to modify or delete.

package/runners/skills/exploit/known-cve-validation/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: known-cve-validation
+description: Turn a version/CVE lead into a confirmed-or-refuted finding by checking the deployed version and a non-destructive version/behaviour signature — never by firing a destructive exploit.
+when-to-use: recon surfaced a CVE or a version banner (internetdb vulns, a Server/X-Powered-By header, a JS library version, a login page naming a product+version), and you need to decide whether the target is actually affected.
+surface: web
+severity: high
+tier: safe-active
+---
+
+# Known-CVE validation (non-destructive)
+
+A playbook for the `http` and recon (`internetdb`) ops. Goal: decide whether a
+CVE lead actually applies to THIS target, with a reproducible, non-destructive
+signal — not by exploiting it. A CVE id alone (from a banner or a scanner) is a
+lead, not a finding.
+
+## 1. Pin the lead and the exact version
+From recon/banners, record the product and the CVE's affected-version range.
+`internetdb` returns `cpes`/`vulns` for the origin IP; `http` headers (`Server`,
+`X-Powered-By`, `X-AspNet-Version`), a JS library path, or a product login page
+give the deployed version. Note where you read it.
+
+## 2. Confirm the version is in range
+Compare the deployed version to the CVE's affected range. Out of range (patched,
+or a different major) → REFUTE the lead with the version evidence. A banner can
+lie or be stripped; prefer two independent version signals when you can.
+
+## 3. Non-destructive behaviour signature
+Where the CVE has a safe, read-only tell, check THAT instead of exploiting:
+- a fixed path/endpoint the vulnerable version exposes (a debug route, an admin
+  servlet, a default file) — fetch it and read the response;
+- a response header/body fingerprint unique to the affected build;
+- for a blind/SSRF-class CVE, use `oob_mint`/`oob_poll` so proof is a logged
+  callback, not damage.
+Never run a destructive or availability-affecting PoC (no RCE payloads, no DoS, no
+data-wiping request) — that belongs to a signed exploit-tier engagement, not here.
+
+## 4. Decide
+Confirm only when the version is in range AND a non-destructive signature matches;
+cite both. If the version is out of range, or no safe signature confirms it, record
+refuted or inconclusive — do not escalate a banner into a "confirmed RCE".
+
+## Evidence & severity
+Cite the version evidence and the behaviour-signature response (or the OOB hit).
+Severity from the CVE, but downgrade when only the version matches and
+exploitability is unproven (theoretical vs demonstrated).

package/runners/skills/exploit/path-traversal/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: path-traversal
+description: Prove a directory/path-traversal read — an endpoint that serves files lets a crafted path escape its intended directory to read files it should never return.
+when-to-use: an endpoint takes a filename/path parameter or serves files (e.g. /download?file=, /static?path=, ?template=, ?page=), or a response reflects a filesystem path; and you want to show it can be made to read out of bounds.
+surface: web
+severity: high
+tier: safe-active
+---
+
+# Path / directory traversal (read)
+
+A non-destructive playbook for the `http` op. Goal: show that a file-serving
+endpoint can be driven to read a file OUTSIDE the directory it is meant to serve.
+Read only — prove the escape by reading one file you should not reach; never write.
+
+## 1. Find the file sink
+Collect endpoints that name a file or path: `/download?file=`, `?path=`, `?page=`,
+`?template=`, `?doc=`, static-asset handlers. Note the intended directory from the
+normal response (e.g. a public report served from a docs folder).
+
+## 2. Establish the in-bounds baseline
+Fetch the endpoint as intended: `http {"path":"/download?file=report.txt"}`. This
+is the control — a normal, authorized read. It is NOT a finding.
+
+## 3. Attempt the escape
+Walk up out of the base directory toward a file that should be unreachable:
+`http {"path":"/download?file=../secret/service.key"}`, then
+`/download?file=../../etc/passwd`. Try URL-encoded (`%2e%2e%2f`) and doubled
+(`....//`) forms if a naive filter is in the way. A 200 returning the contents of
+an out-of-bounds file (a key, `/etc/passwd`, another tenant's document) is the
+traversal.
+
+## 4. Distinguish a real escape from correct behavior
+It is only a finding if the file is one the endpoint should NOT serve: outside the
+intended directory, and sensitive or private. An endpoint that correctly rejects
+`../` (404/403, or normalizes back into the base) is behaving — not a finding.
+Pair it with the `diff` op if you need to show in-bounds vs escaped responses side
+by side.
+
+## Evidence & severity
+Cite the in-bounds baseline and the escaped read, and name the out-of-bounds file
+and the sensitive content it returned. Severity high, or critical if it reaches
+credentials/keys or arbitrary files. Read the proof file once; do not enumerate
+the whole filesystem or exfiltrate at scale.

package/runners/skills/exploit/reflected-xss/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: reflected-xss
+description: Prove reflected cross-site scripting — show that a request parameter is reflected into the HTML response without encoding, so script-context markup survives intact.
+when-to-use: a parameter is echoed back in an HTML response (search terms, error messages, "you searched for…", query values in the page), and you want to show it is reflected without output encoding.
+surface: web
+severity: medium
+tier: safe-active
+---
+
+# Reflected XSS
+
+A non-destructive playbook for the `http` op. Goal: show a parameter is reflected
+into an HTML response WITHOUT output encoding, in a context where markup executes.
+Prove reflection with a benign, unique marker — do not weaponize against real users
+or chain to a live payload.
+
+## 1. Find a reflection
+Identify parameters echoed into the page (search terms, messages, path segments).
+Fetch normally and confirm your input appears in the response body.
+
+## 2. Probe the encoding with a unique marker
+Send a distinctive, harmless marker containing markup characters, URL-encoded:
+`http {"path":"/search?q=%3Cxss7f3%3E"}` (i.e. `<xss7f3>`). Then read how it comes
+back:
+- reflected verbatim as `<xss7f3>` in an HTML body → output encoding is MISSING;
+  injected markup would be parsed as HTML. That is the finding.
+- reflected as `&lt;xss7f3&gt;` (entity-encoded) → correctly escaped, NOT a finding.
+
+## 3. Confirm the context is executable
+Check the reflection sits where markup runs: HTML body/attribute, not inside an
+already-encoded JSON string or a `text/plain` response. A reflection in a
+`Content-Type: application/json` body is not script-executable in a browser.
+Note the response's Content-Type.
+
+## 4. Minimal execution proof (only if needed)
+If you must go past reflection, use the smallest tag that proves parsing (e.g. an
+`<svg>` with a harmless marker). Never target real users, never exfiltrate, never
+persist.
+
+## Evidence & severity
+Cite the request and the response line showing the marker reflected unescaped, plus
+the Content-Type proving an executable context. Severity medium (reflected), higher
+if it hits authenticated pages or combines with a CSRF/token leak.

package/runners/skills/exploit/service-exploitation/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: service-exploitation
+description: Exploit an exposed non-HTTP service by actually talking its protocol — send commands over a raw TCP connection and read the reply to prove an unauthenticated Redis, memcached, SMTP relay, or similar line protocol processes attacker input — the exploit-tier step beyond a read-only banner grab.
+when-to-use: a `probe` banner grab (or a port scan) found an open non-HTTP port you suspect is reachable without auth (Redis 6379, memcached 11211, SMTP 25, an admin/debug socket), and the engagement is at the exploit tier — you want to prove the service accepts your commands, not just that the port is open.
+surface: network
+severity: high
+tier: exploit
+---
+
+# Service exploitation (raw protocol send)
+
+The exploit-tier counterpart to `probe`. `probe` connects and reads the banner the
+service volunteers — it sends nothing. `send` connects and TRANSMITS protocol bytes,
+then reads the reply, so you can prove an exposed service actually processes your
+commands. It rides a raw TCP socket, two-key gated (exploit tier AND destructiveActions)
+and scope-bound to the target host, exactly like probe.
+
+Talking a live protocol can change service state. The discipline is to prove
+reachability with the most benign command first, and never run a destructive one to
+"confirm" what a read-only command already shows.
+
+## 1. Start from a probe
+You should already know the port is open (from `probe` or a scan) and have a guess at
+the protocol from the banner or the port number. Don't blind-send to arbitrary ports.
+
+## 2. Send the most benign proving command first
+Prove the service accepts commands with a read-only/no-op command before anything
+else:
+- **Redis**: `send {"port":6379,"data":"PING\n"}` → `+PONG` proves it is an open,
+  unauthenticated Redis. Then `INFO` for version/role. (`\n` is sent as CRLF.)
+- **memcached**: `send {"port":11211,"data":"stats\n"}` → a `STAT` block.
+- **SMTP**: read the `220` banner, then `EHLO probe` → the capability list; an open
+  relay shows in the `250` responses.
+Use `hex` instead of `data` for a binary protocol.
+
+## 3. The reply is the proof
+A command-specific reply (`+PONG`, a `STAT` block, a `250` capability) proves the
+service processed YOUR input — that is the finding: an unauthenticated, reachable
+service. Quote the exact bytes sent and the reply received.
+
+## 4. Distinguish processed from ignored (precision)
+Only a finding if the service ACTED on your command. A connection that returns just
+its connect banner and then nothing, an `-ERR`/`-NOAUTH`/`5xx auth-required` reply, or
+a silent socket that never answers, means the command was NOT accepted — do not claim
+interactive access. A banner alone is a `probe` result, not an exploitation.
+
+## 5. Stop at proof; do not escalate destructively
+Once a benign command proves reachability, STOP — report the capability. Do NOT run a
+command that destroys or exfiltrates real data (`FLUSHALL`, `CONFIG SET` to overwrite
+files, mail injection) just to "confirm" it; the accepted read-only command already
+proves the missing authentication. If a write is the only way to demonstrate a
+specific impact, prefer a reversible one on a throwaway key and undo it.
+
+## Scope & safety
+`send` only reaches the target host and hosts under the verified root domain; it
+refuses anything else. One service, one proving exchange per finding. Keep commands
+reversible; never pivot raw sends across hosts or fan them out.
+
+## Evidence & severity
+Cite the host:port, the exact bytes sent, and the reply that proves the service
+processed them. Severity tracks impact: an unauthenticated data store (Redis/memcached)
+reachable from the engagement surface is high-to-critical (data theft, often RCE via
+known techniques); an open relay or an info-only socket is lower. No accepted command,
+no service-exploitation finding.

package/runners/skills/exploit/service-probing/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: service-probing
+description: Find and fingerprint NON-HTTP services the web surface hides — TCP-connect to ports and read the banner a service volunteers (SSH/SMTP/FTP/database version strings), to surface exposed services, outdated versions, and listeners that should not be reachable. Often the highest-severity findings on an engagement live off the web port.
+when-to-use: the target host (or a host under the verified root domain) likely runs more than a web server, recon (internetdb) reports open ports, or you want to confirm whether a non-HTTP port is actually reachable and what is listening on it.
+surface: network
+severity: high
+tier: safe-active
+---
+
+# Non-HTTP service probing
+
+A non-destructive playbook for the `probe` op (with `internetdb`/`dns` recon as the
+lead). A web app is one service on one port; the host usually runs more. An exposed
+SSH with an old OpenSSH, a reachable database, an open Redis, a mail relay — these
+are frequently the real criticals, and the `http` op cannot see any of them.
+
+`probe` CONNECTS AND READS ONLY. It sends nothing, so it cannot change a service's
+state. Sending protocol commands (an active handshake) is exploit-tier and out of
+scope here — do not try to work around that.
+
+## 1. Decide which ports to look at
+Lead with recon: `internetdb` on the host's IP reports observed open ports and CPEs
+cheaply, without touching the host. Confirm the interesting ones with `probe`. If
+recon is unavailable, probe the common service ports (22, 25, 465/587, 3306, 5432,
+6379, 3389, …) as a bounded list.
+
+## 2. Probe and read the banner
+`probe {"ports":[22,3306,6379]}` (defaults to the origin host; pass `host` to probe
+a recon-discovered host UNDER the verified root domain). You get per-port
+open/closed and the connect-banner. SSH, SMTP, FTP and MySQL announce a version on
+connect; HTTP and Redis stay silent — `open:true` with an empty banner still proves
+the port is reachable.
+
+## 3. Reason about the banner
+A version string is the finding's core: `SSH-2.0-OpenSSH_7.4` names a specific build
+you can map to known CVEs (cross-check with the known-cve-validation playbook — but
+only claim a CVE with a real version-match signature, never a destructive PoC). An
+exposed database or cache port that should never face the internet is a finding on
+reachability alone.
+
+## 4. Distinguish real exposure from nothing
+`open:false` means closed/filtered — not a service; never report a phantom. An open
+port with a banner is a reachable service; map it. An open port with no banner is
+reachable but unidentified — report the exposure, do not guess the service. A port
+reachable only because YOU are in-network (not from the internet) is weaker — say so.
+
+## Evidence & severity
+Cite the host, port, open/closed, and the exact banner. An exposed admin/database/
+cache service, or a service whose version maps to a known RCE, is high to critical;
+a benign, expected service (a web server's own 80/443) is not a finding. Probe only
+hosts in scope (the op enforces this); read banners, never send commands.

package/runners/skills/exploit/sqli-inference/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: sqli-inference
+description: Prove SQL injection non-destructively using boolean and error oracles — show the query is attacker-controllable without reading/altering data at scale.
+when-to-use: a parameter feeds a search/filter/lookup that likely hits a database (?q=, ?id=, ?sort=, ?filter=), or an error response leaks SQL/driver text; and you want to demonstrate injection without destructive queries.
+surface: web
+severity: critical
+tier: safe-active
+---
+
+# SQL injection (safe, inference-based)
+
+A non-destructive playbook for the `http` and `diff` ops. Goal: prove the query is
+attacker-controllable via an ORACLE — the response itself tells you true/false or
+errors — WITHOUT dumping data at scale or running any write/stacked query. Read-only
+SELECT inference only; never `;DROP`, `UPDATE`, `DELETE`, time-bomb, or OR-1=1 that
+mutates.
+
+## 1. Find the sink and baseline it
+Fetch the parameter normally: `http {"path":"/api/search?q=widget"}`. Note the shape
+of a normal result set.
+
+## 2. Error oracle
+Send a single unbalanced quote: `http {"path":"/api/search?q='"}`. A 500 (or 200)
+that leaks SQL/driver text (`syntax error`, `unterminated quoted string`,
+`psycopg2`, `ORA-`, `SQLSTATE`) proves the input reaches the query unescaped.
+
+## 3. Boolean oracle (the clean proof) — use diff
+Build a false/true pair that changes ONLY the injected condition, and compare with
+the differential engine:
+`diff {"requests":[
+  {"path":"/api/search?q=zzz'and'1'='2"},
+  {"path":"/api/search?q=zzz'or'1'='1"}]}`.
+`content_varies: true` / `distinct_bodies == 2` — the false branch returns nothing,
+the true branch returns rows the term alone could not match — is the injection,
+proven by behavior, not by a stack trace.
+
+## 4. Distinguish real injection from correct behavior
+A parametrized/prepared endpoint treats the payload as a literal string: the pair
+returns the SAME result and no error (`content_varies: false`). That is NOT a
+finding. Also rule out a WAF echoing the payload rather than the DB executing it.
+
+## Evidence & severity
+Cite the error response and/or the diff evidence id showing the boolean flip, and
+name the condition you controlled. Severity critical (injection → auth bypass / data
+disclosure). Prove controllability with one boolean/error pair; do NOT enumerate
+tables or exfiltrate rows — that is beyond a non-destructive proof.

package/runners/skills/exploit/ssrf-oob/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: ssrf-oob
+description: Prove server-side request forgery (and other blind server-initiated requests) with an out-of-band callback — the target fetches a unique URL you mint, and the collaborator records the hit.
+when-to-use: a parameter takes a URL or host, or a feature makes the server fetch something (webhooks, url=, image/pdf/preview generators, link unfurling, import-from-URL, XML with external entities), and you need to prove the server can be made to call out.
+surface: web
+severity: high
+tier: safe-active
+---
+
+# SSRF / blind out-of-band interaction
+
+A non-destructive playbook for the `http`, `oob_mint`, and `oob_poll` ops. Goal:
+prove the target can be made to issue a server-side request to a destination YOU
+choose. THE RULE: no OOB callback, no SSRF critical — a reflected error or a guess
+is not proof; a logged hit on your collaborator is.
+
+## 1. Mint a collaborator callback
+`oob_mint {}` → `{token, url}`. The url is unique to this attempt; a request that
+reaches it is unambiguously caused by your payload.
+
+## 2. Find the sink and plant the URL
+Identify where the server might fetch a URL: `?url=`, `?next=`, `?image=`,
+`?webhook=`, import/preview/unfurl features, or an XML body (XXE external entity).
+Plant the minted url there, via `http`:
+`http {"path":"/fetch?url=<minted url, URL-encoded>"}`.
+
+## 3. Poll for the interaction
+`oob_poll {"token":"<token>"}`. `interaction: true` (hits ≥ 1) proves the target
+made a server-side request to your collaborator — blind SSRF (or blind XXE if the
+sink was an XML entity) CONFIRMED. `interaction: false` is NOT proof: the payload
+may not have fired, the sink may validate the host, or egress may be filtered — try
+another sink or encoding, but do not report a finding without a hit.
+
+## 4. Escalate the impact (still read-only)
+If a hit lands, note what it demonstrates: internal network reachability, the
+ability to hit cloud metadata (`169.254.169.254`), or internal-only services. You
+can show reachability without exfiltrating secrets; do not pivot into destructive
+internal actions.
+
+## 5. Distinguish real SSRF from benign behavior
+An endpoint that merely echoes or client-side-renders the URL (no server fetch)
+produces no hit — not SSRF. A server that fetches only an allowlisted host, or
+refuses your collaborator, is behaving.
+
+## Evidence & severity
+Cite the oob_mint token, the request that planted the url, and the oob_poll
+evidence id showing the hit. Severity high, critical if it reaches cloud metadata
+or internal admin surfaces.

package/runners/skills/exploit/state-change-exploitation/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: state-change-exploitation
+description: Prove real-world impact by actually changing server state with a mutating request (POST/PUT/PATCH/DELETE) and then reading it back — privilege escalation, mass-assignment, forced object creation/deletion, workflow/state-machine abuse — the exploit-tier step beyond read-only access-control findings.
+when-to-use: a read-only probe (http GET / diff) has shown a request SHOULD be refused but the endpoint also accepts a state-changing method, you suspect missing function-level authorization on a write (set role, approve, publish, transfer), mass-assignment of a protected field, or an object you can create/delete/modify that you should not — and the engagement is at the exploit tier.
+surface: web
+severity: high
+tier: exploit
+---
+
+# State-change exploitation (mutating requests)
+
+The exploit-tier counterpart to the read-only access-control checks. Read-only
+probing shows what you can *see*; this shows what you can *do* — it proves impact
+by actually mutating state and confirming the change stuck. It rides the same `http`
+op, which unlocks the mutating methods (POST/PUT/PATCH/DELETE with a `body`) only at
+the exploit tier with destructiveActions authorized.
+
+Mutation is real and can be destructive. The whole discipline here is proving
+impact while keeping the blast radius minimal, reversible, and inside scope.
+
+## 1. Decide it is worth mutating
+You already have a reason: a GET/`diff` probe showed an endpoint that responds to a
+write method, or a field/flag that looks server-trusted. Confirm the write path
+exists first (an `OPTIONS`, a 405-vs-401 on the method, the client JS that calls it)
+before sending the mutation. Don't fire blind writes to enumerate.
+
+## 2. Capture the before-state
+Read the thing you are about to change: `http GET` the resource (or `diff` it across
+identities). Record its current value. Without a before-state you cannot prove your
+request — not some background process — caused the change.
+
+## 3. Send the smallest mutation that proves the point
+Send ONE mutating request with a minimal `body`. Prefer a change that is:
+- **reversible** — set a flag you can unset, create a record you can delete;
+- **a throwaway marker** — a uniquely-named object / a nonce value you can recognize,
+  never real user data;
+- **non-destructive where a create/update proves it** — do not delete or corrupt real
+  records when creating a marker makes the same point.
+Example (self-service privilege escalation): `http {"method":"POST",
+"path":"/api/account/role","body":{"role":"admin"}}`.
+
+## 4. Confirm the change stuck (the proof)
+Read it back: `http GET` the same resource and show the value MOVED to what you set
+(role `user` → `admin`). The before/after pair is the finding. A 200 on the write
+alone is NOT proof — many apps return 200 and ignore the change.
+
+## 5. Undo it
+Reverse what you did (unset the flag, delete the marker, restore the prior value) and
+confirm the restore. Leave the target as you found it. Record what you changed and
+that you reverted it.
+
+## 6. Distinguish a real finding from a refused mutation (precision)
+Only a finding if the state ACTUALLY changed when it should have been refused. A write
+that returns 400/401/403, or returns 200 but leaves the follow-up read UNCHANGED, is
+the control WORKING — do not claim it. Compare with the properly-guarded twin if one
+exists: if the secure endpoint rejects the same mutation and its state does not move,
+that is the correct behavior, not a vulnerability.
+
+## Scope & safety
+Mutations go ONLY to the primary origin (the adapter refuses a mutating request aimed
+at any other host). Never chain a mutation into something irreversible on shared state,
+never mass-mutate, and keep to one proving change per finding. If the only way to
+"prove" impact is irreversible destruction of real data, STOP and report the capability
+(the reachable write + missing authorization) with the before-state and the refused-
+elsewhere control as evidence, rather than causing the damage.
+
+## Evidence & severity
+Cite the exact mutating request (method, path, body), the before read, the after read
+showing the changed state, and the undo. Severity tracks what the change grants:
+privilege escalation / auth-boundary writes and destructive or financial actions are
+high-to-critical; a low-impact or self-only change is lower. No before/after proof,
+no state-change finding.

package/runners/skills/exploit/stateful-authz/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: stateful-authz
+description: Establish real sessions (log in) and test access control across accounts — prove horizontal (same-role, other owner) and vertical (low→high privilege) authz breaks with authenticated sessions, not just anonymous requests.
+when-to-use: the app has a login and the assessment provides credentials/identities, and you need to test what one authenticated account can reach that it should not — another user's data, an admin-only function, a tenant boundary.
+surface: web
+severity: high
+tier: safe-active
+---
+
+# Stateful authorization testing
+
+A non-destructive playbook for the `login`, `http`, and `diff` ops. Where
+`authz-differential` compares anonymous vs. a static identity, this one drives REAL
+sessions so you can test authenticated boundaries. `login` is the only POST allowed
+(authentication is non-destructive); everything you prove after is read-only.
+
+## 1. Establish the sessions
+For each account the engagement gives you, log in and name the session:
+`login {"path":"/login","identity":"user_alice","session":"alice"}` (the identity's
+secret is used; you never see it) or with an explicit `body`. Confirm
+`authenticated: true`. Repeat for a second account and, if available, an admin.
+
+## 2. Baseline each session's legitimate access
+As each session, read what it SHOULD reach: `http {"path":"/account","identity":"alice"}`.
+Note the owner/tenant/role the response reflects. This is the control.
+
+## 3. Test horizontal access (same role, other owner)
+As `alice`, request `bob`'s object by id/handle:
+`http {"path":"/api/orders/<bob's id>","identity":"alice"}`. Or compare directly:
+`diff {"requests":[
+  {"path":"/account","identity":"alice"},
+  {"path":"/account","identity":"bob"}]}` to show each returns its own data — then
+the real test: does alice's session read bob's record? A 200 with bob's data under
+alice's session is a horizontal authz break (BOLA).
+
+## 4. Test vertical access (privilege escalation)
+As a low-privilege session, call an admin/privileged endpoint
+(`http {"path":"/admin","identity":"alice"}`). Success where a 403 is expected is a
+vertical break. Compare the low-priv and admin sessions with `diff` to show the
+boundary is (not) enforced.
+
+## 5. Distinguish real breaks from correct behavior
+Only a finding if a session reaches data/actions for another principal or a higher
+role. Each session seeing its own data, and a 401/403 on others', is correct. A
+public resource that answers everyone is not an authz break.
+
+## Evidence & severity
+Cite the login (session established), the baseline, and the crossing read (or the
+diff evidence id). Horizontal/vertical authz breaks are high, critical at scale or
+for admin takeover. Read the proof record only; never modify another account.

package/runners/skills/recon/subdomain-takeover/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: subdomain-takeover
+description: Discover subdomains of the verified root domain and identify dangling DNS records vulnerable to subdomain takeover.
+when-to-use: starting recon on a domain, or whenever you have a verified root domain and want to expand the attack surface beyond the primary origin.
+surface: recon
+severity: high
+---
+
+# Subdomain discovery & takeover
+
+A read-only playbook using the recon ops (`crt`, `dns`) and the `http` host-pivot.
+WAF-independent: these hit external data sources, not the protected origin.
+
+## 1. Enumerate subdomains
+- `crt {"domain":"<root>"}` — mine certificate-transparency logs; returns hostnames
+  of the root, including staging/admin/internal hosts leaked in certs.
+- `dns {"name":"<root>"}` — records for the root (NS/MX/TXT often reveal providers
+  and verification tokens worth noting).
+Collect the union of hostnames under the verified root.
+
+## 2. Triage each subdomain
+For interesting hosts (admin*, staging*, internal*, vpn*, dev*, test*):
+- `dns {"name":"<sub>"}` — resolve it. Watch the result flags:
+  - `"dangling": true` — a CNAME whose target no longer resolves (NXDOMAIN).
+  - `"takeover_candidate": {...}` — the CNAME points at a takeover-prone provider
+    (S3, GitHub Pages, Heroku, Azure, Netlify, Fastly, etc.).
+
+## 3. Confirm a takeover candidate (do NOT claim one)
+A dangling/takeover_candidate flag is a CANDIDATE, not a confirmed takeover. Pivot
+the http op to the host to corroborate:
+`http {"path":"/","host":"<sub>"}` (anonymous — the adapter refuses creds off the
+origin host). A provider "no such bucket / app not found / project not found" page
+on a host your target still has a live CNAME to = a confirmed, claimable takeover.
+
+## 4. Probe live subdomains
+For subdomains that DO resolve and serve, pivot `http` and apply the web playbooks
+(exposed paths, JS secrets, unauth APIs) — staging/dev hosts are frequently less
+hardened than production and are a rich anonymous surface.
+
+## Evidence & severity
+- Confirmed takeover (dangling CNAME + provider orphan page): high/critical — an
+  attacker can claim the host and serve content under the target's name.
+- Leaked internal host now reachable: scope by what it exposes.
+Cite the CNAME chain (from `dns`) and the corroborating `http` response. Stay within
+the verified root domain and its subdomains.

package/runners/skills/web/content-discovery/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: content-discovery
+description: Map a web app's reachable endpoints and paths, preferring the app's OWN disclosures (specs, robots, JS) over blind guessing, read-only and non-destructive.
+when-to-use: starting a web assessment, or whenever you need to expand the known endpoint surface of an origin or a discovered host before deep-diving.
+surface: web
+severity: info
+---
+
+# Content & endpoint discovery (evidence-driven)
+
+A read-only playbook for the `http` op (GET/HEAD + `grep`). Goal: enumerate the
+reachable endpoints/paths of a host, preferring what the app REVEALS about itself
+over blind wordlist guessing. Reasoning-first and non-destructive: thoroughness
+comes from reading the app's own disclosures, not from high-rate brute force.
+
+## 1. Harvest the app's own inventory FIRST (ground truth, not guessing)
+These enumerate endpoints the app itself publishes:
+- `http {"path":"/robots.txt"}` and `/sitemap.xml`, `/sitemap_index.xml` — often
+  list admin/internal paths the authors meant to hide from crawlers.
+- `/.well-known/security.txt`, `/.well-known/` — contact + sometimes more.
+- OpenAPI/Swagger specs: `/openapi.json`, `/swagger.json`, `/v2/api-docs`,
+  `/api-docs`, `/swagger-ui.html`, `/redoc`. A spec is the full API map — fetch it
+  and read every path/operation it declares.
+- Response headers: follow `Link:` and `Location:` values you see.
+- **JS endpoint mining** (high yield): fetch each linked script and use `grep` over
+  the full body to pull route strings, e.g.
+  `http {"path":"/static/app.js","grep":"[\"']/(api|v1|v2|graphql|admin|internal|auth)[^\"']*"}`.
+  Also mine `app.js.map` source maps the same way. This recovers the real API the
+  front end calls — usually far more than any wordlist.
+- GraphQL: if a `/graphql`-style endpoint exists, use GET introspection to list its
+  operations (see the graphql-exposure playbook).
+- Parse the HTML: `<a href>`, `<form action>`, `data-*` URLs, inline `fetch(...)`.
+
+## 2. Fingerprint-guided candidates
+From the `Server`/`X-Powered-By` headers, framework cookies, and JS libraries you
+detect, consider framework-specific surfaces (judgmentally, only those that match):
+Spring `/actuator`, WordPress `/wp-json` `/wp-admin`, Laravel/node `/.env`,
+Django `/admin`, Next.js `/_next`, `/telescope`, `/debug`, `/graphql`.
+
+## 3. Common high-signal names — a capped JUDGMENT AID, not a brute force
+ONLY after steps 1-2, and prioritized by what you learned, probe a SMALL curated set
+of commonly-exposed paths: `admin`, `login`, `api`, `backup`/`backups`, `config`,
+`.env`, `.git/config`, `.git/HEAD`, `.DS_Store`, `debug`, `status`, `health`,
+`metrics`, `swagger`, `dump.sql`, `old`, `test`, `phpinfo`.
+POSTURE: this is read-only and MUST NOT become a high-rate wordlist blast (that is
+out of scope and crosses the non-DoS line). Probe a handful, observe, and let what
+you find guide the next requests. Reason about which names fit the detected stack
+rather than trying everything.
+
+## 4. Confirm, then hand off
+For each discovered endpoint record status, content-type, whether auth is required,
+and whether it exposes data/functionality that should be protected. Feed the
+discovered endpoints into the other playbooks: unauthenticated APIs, IDOR on
+id-keyed routes, exposed paths/secrets, GraphQL exposure.
+
+## Posture
+GET/HEAD only; never modify. Evidence (step 1) over guessing (step 3). Keep request
+volume modest and purposeful — breadth via reading what the app discloses, not via
+brute force.