White-box Pentest (Shannon)

A white-box penetration testing methodology distilled from Keygraph's Shannon AI pentester. Use it to run a security audit on your web app or API by reading source code and proving exploits against a local instance.

Sby Skills Guide Bot
SecurityAdvanced
007/26/2026
Claude CodeCursor
#penetration-testing#white-box#security-audit#web-security#exploit

Recommended for


name: whitebox-pentest description: Use whenever someone wants their own web app or API checked for security holes — a security review, security audit, penetration test, or "find the vulnerabilities" pass, often before they ship or go live. Reach for it when the user points you at their app's source plus a running or test instance and asks how secure it is, whether it's safe to launch, whether a normal user can reach admin-only functions or 越权, or to look for XSS, SQLi, SSRF, IDOR, or broken auth. Covers phrasings like 安全审计, 渗透测试, 安全测试, 查漏洞, 测试权限/越权, 从攻击者角度试试, security review, pentest, or "try to break in." It finds real, exploitable bugs by reading the code and proving each against a local instance, not just flagging risky-looking lines. White-box methodology distilled from Keygraph's Shannon AI pentester; non-production targets only. Skip it for building auth features, explaining security concepts, or dependency/config-only scans. argument-hint: [target-url and source-repo-path] allowed-tools: Bash(*), Read, Grep, Glob, Write, Edit, Agent, mcp__plugin_playwright_playwright__browser_navigate, mcp__plugin_playwright_playwright__browser_snapshot, mcp__plugin_playwright_playwright__browser_click, mcp__plugin_playwright_playwright__browser_take_screenshot

White-box Pentest (Shannon-distilled)

A white-box penetration-testing methodology distilled from Keygraph's open-source Shannon AI pentester (https://github.com/KeygraphHQ/shannon). Use it to run a Shannon-grade security audit yourself — no Docker, no separate Anthropic key, no Shannon install needed. You ARE the pentester; this skill is the playbook.

The one law

Only report what you can actively exploit with a working PoC. An unproven "vulnerability" is worse than no finding — it wastes effort and manufactures false confidence. Do NOT report static/dependency/config issues you cannot exploit (vulnerable libs, weak crypto, missing headers) — those are SAST territory, out of scope here. Code is ground truth for where the flaw is; live behavior is the final judge of whether it's real (if the running app contradicts your source reading, trust what you observed, change strategy, and record the divergence).

Scope & safety (hard constraints)

  • Non-production only. Exploitation mutates data. Stand up a LOCAL instance of the target and point at that. Never run against production.
  • External-attacker viewpoint. Assume no VPN / internal access / admin. Only report what's reachable + exploitable from outside (externally_exploitable).
  • Authorized targets only (apps the user owns / is authorized to test).

Pipeline (5 phases)

Run these phases. Delegate the bulk source-reading to subagents (keeps your context clean); do the live probing yourself.

  1. Preflight + auth — confirm the app is reachable; if it has login, do ONE real login and reuse that session for all probes.
  2. Recon (source + live) — dispatch a subagent to build a security architecture baseline from the source: tech stack, every entry point (routes/endpoints/forms/params), auth & session model, and the sink inventory (every place user data reaches a dangerous operation — DB query, shell, file path, HTML render, outbound HTTP, deserialize). Cross-reference with live browsing. Output: endpoint list + input vectors + authz candidates split into Horizontal / Vertical / Context.
  3. Per-class analysis (white-box) — for each vuln class, trace source→sink on each candidate. Decide vulnerable vs safe from the code. Do not exploit yet. Only items that are vulnerable AND externally_exploitable advance.
  4. Exploitation (live) — for each advanced item, weaponize against the local instance until you have real evidence (Level 3+, see below) or you've disproven it. This is the gate: no analysis hit → skip exploitation for that class.
  5. Report — assemble confirmed findings only. Each gets a reproducible PoC.

For a real app, dispatch one recon subagent and one per-class analysis subagent (or one combined source-audit subagent for small apps), then do live exploitation yourself. Scale agent count to app size.

Proof-of-Exploitation leveling (the anti-overclaim gate)

Rate every finding. You MUST reach Level 3 with evidence to mark EXPLOITED.

  • L1 — entry point confirmed (error/timing/reflection observed).
  • L2 — you control the structure (boolean/UNION/payload shape works).
  • L3 — you extracted real data / executed real code / accessed real unauthorized resource → EXPLOITED.
  • L4 — admin creds / RCE / full account takeover.

Three-state classification (be honest)

  • EXPLOITED → main report (L3+ proof).
  • POTENTIAL → separate note, only when an external operational constraint (a service you can't reach, creds you don't have) blocks the final step AND you've recorded multiple failed bypass attempts.
  • FALSE-POSITIVE → tracking file, not the deliverable.

The decision test: "Is the thing blocking me a security feature designed to stop this attack, or an external operational constraint?" A security mechanism that survives exhaustive bypass = FALSE-POSITIVE. Only external constraints make it POTENTIAL. An honestly-labeled false positive beats a mislabeled potential.

Bypass-exhaustion: before calling anything safe/false-positive, try several distinct bypasses (encoding, obfuscation, second-order, blind, alternate slot) and record each failure. "Blocked once" ≠ "secure".

Taint model (unifies all source→sink classes)

Data is tainted by default until it meets a sanitizer whose type matches the sink's context. If concatenation/mutation happens after the sanitizer, the defense is void. When confidence is uncertain, round down.

Per-class playbooks

Injection (SQLi / command / file-include / SSTI / deserialize / path-traversal). Find: forward-trace source→sink; tag the sink slot (SQL value/identifier, CMD arg/string, FILE path, TEMPLATE expr). Defense must match the slot — parameter binding for SQL values but whitelist for identifiers (binding can't protect identifiers); array-arg/shell=False or shlex.quote for command (blacklists fail); whitelist or resolve()+boundary-check for file paths; sandbox+autoescape for templates. Verify: Confirm ('", error) → Fingerprint → Enumerate → Exfiltrate (L3 = real rows / file contents read). Path-traversal PoC: ?param=../<sibling-file> returns content outside the intended dir.

XSS (reflected / stored / DOM). Find: reverse-trace sink→source; at each encoder check (a) context match (HTML-body→entity, attribute→attr-encode, JS-string→JS-escape, URL→URL-encode) and (b) mutation between encoder and sink. DB-read reached without a prior encoder → treat as stored XSS. Verify: real JS execution (alert/console/DOM), not mere reflection — "reflected in HTML" ≠ "JS executed". L4 = cookie/session theft. Note: react-markdown without rehype-raw, and React's default escaping, neutralize most XSS — confirm before claiming.

Broken authentication. Find (checklist): transport (HTTPS+HSTS), rate-limit/lockout, session cookie (HttpOnly/Secure/SameSite + ID rotation on login + logout invalidation + timeouts + not-in-URL), token entropy/expiry, session fixation (compare pre/post-login ID), password policy, generic login errors (anti-enumeration), recovery/logout (single-use short-TTL token), SSO/OAuth (state/nonce, exact redirect whitelist, PKCE; nOAuth = use immutable sub not email). Verify: brute-force (really send 200), credential-stuffing, alg:none JWT, reset-param tampering. Attack the door (authn), not the house (authz). "Locked out / rate-limited" is an obstacle to bypass, not an instant false-positive.

Broken authorization. Find: Horizontal (reverse-trace to side-effect, check ownership/tenant binding — IDOR/cross-tenant), Vertical (role/capability check must dominate the sink), Context/workflow (forward-walk, check each step validates prior state). A guard after the side-effect is void; UI-only hiding is not a guard; don't assume the framework gives you authz. Verify: swap IDs (IDOR), low-priv session hitting admin endpoints / role-param tampering, step-skipping. "Logged in" ≠ "ownership checked".

SSRF. Find: user-controllable HTTP client, protocol whitelist (not blacklist), internal-range blocking (127/10/172.16/192.168/169.254), cloud-metadata 169.254.169.254, URL-parser bypass, header stripping, response echo (blind?). Verify by type — Classic (payload content/banner echoed in response), Blind (OOB: your own DNS/HTTP sees the callback — strongest), Semi-blind (timing/error diff: dead-IP vs fast-host vs internal), Stored (planted webhook fires). timeout/connection-refused is ambiguous — internal-firewall block (POTENTIAL) vs no vuln (FALSE-POSITIVE); distinguish by probing multiple internal targets.

WSTG checklist skeleton (coverage map)

Map findings to OWASP WSTG so coverage is auditable: INFO (fingerprint / entry points / exec paths / architecture) · ATHN (creds-in-transit, default creds, lockout, bypass, password policy, recovery, MFA) · ATHZ (traversal/LFI, bypass, privesc, IDOR, OAuth) · SESS (cookie attrs, fixation, CSRF, logout, timeout, JWT) · INPV (reflected/stored XSS, SQLi, code/command injection, SSTI, SSRF) · CLNT (DOM XSS, JS exec, HTML injection, client redirect, browser storage) · CRYP (weak TLS, cleartext) · API (recon, BOLA, GraphQL). Out of scope (don't report — can't actively exploit): generic config, error-handling, business-logic, vulnerable-dependency, weak-algorithm.

After you find something

Found a real, exploitable bug? Fix it, add a regression test that fails on the vuln and passes after the fix, re-run the exploit to confirm it's blocked, and (if deployed) ship the fix + re-verify on the target. A pentest that ends at "here's a bug" is half-done; the value is the closed loop find→prove→fix→verify.

Reference (deep-dive)

Original Shannon methodology lives in a local Shannon clone, under apps/worker/prompts/{pre-recon-code,recon,vuln-*,exploit-*}.txt (the agent playbooks), apps/worker/src/temporal/workflows.ts (phase orchestration + the deterministic queue gate), COVERAGE.md (WSTG map), docs/safety.md (proof-by-exploitation), and sample-reports/shannon-report-juice-shop.md (report/PoC format: ### INJ-VULN-01 headers with Location / Impact / Severity / Prerequisites / reproducible Exploitation Steps / Proof of Impact).

Related skills