--- name: redteam-mindset description: Red-team operator discipline category: security risk: offensive source: https://github.com/elementalsouls/Claude-BugHunter source_repo: elementalsouls/Claude-BugHunter source_type: community date_added: '2026-09-20' license: MIT license_source: https://github.com/elementalsouls/Claude-BugHunter/blob/main/LICENSE compatibility: Requires explicit written authorization for a target scope plus the relevant testing tools for this technique. Docs-only; helper scripts and commands not bundled. sources: authorized-engagement report_count: 1 --- > **⚠️ AUTHORIZED USE ONLY** > This skill is for educational purposes or authorized security assessments only. > You must have explicit, written permission from the system owner before using this tool. > Misuse of this tool is illegal and strictly prohibited. > **Mandatory confirmation gate** > Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target: > 1. Ask the user to state the exact target URL, IP, account, or resource. > 2. Ask the user to confirm written authorization and the permitted scope. > 3. Show the exact command(s) and explain their expected effect. > 4. Wait for explicit confirmation in the current conversation. > > Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab. ## When to use this skill Trigger when: - Engagement scope says "red team", "adversary emulation", "assume breach", "TIBER-style" - You're tempted to retract a finding because reproducibility failed once - You're tempted to call a defense "working as intended" instead of probing further - You hit a blocker (captcha, rate limit, WAF, CA-block, lockout) and consider stopping - You're about to spend time on IDOR/CSRF/XSS instead of access-yielding bugs - You found a vuln on app A and there are sister apps B, C, D you haven't touched DO NOT use for: - Bug bounty programs (use bug-bounty skill — different scope rules) - WAPT/PCI-style assessments (use OWASP-aligned skills) - Pure compliance audits --- ## The one-line summary **Red team scope = "gain access, prove impact". Bug bounty / WAPT scope = "find a bug, write a report".** These produce DIFFERENT decisions at every blocker. Internalize the difference before starting. --- ## Persistent work within the rules of engagement Continue useful testing within the exact approved assets, techniques, time window, rate and credential-attempt limits. Existing explicit authorization need not be re-requested for routine in-scope work, but “full engagement” never authorizes unspecified third-party assets, purchases, tool installation, persistence, data extraction or bypassing an agreed stop condition. The confirmation gate above and the engagement rules remain controlling. Use a finite prioritized test plan. Report what was tested, omitted, blocked and inconclusive; no fixed number of classes or requests certifies complete coverage. Respect lockouts, rate limits and availability signals. Stop at the minimum harmless evidence; prefer synthetic test data and test accounts. Three real records are not an automatic allowance, and neither a missing check nor a count alone proves impact. Shared infrastructure, robots.txt, sitemaps and app catalogs produce leads, not authorization. Verify each asset against scope before probing. Reuse a confirmed technique only after checking its effects on the next approved asset. Do not turn background work into unattended credential attempts or extraction. --- ## Mindset correction #1 — The blocker is data, not the stop sign **Anti-pattern (what I did wrong):** > "Recheck under load showed no timing differential — recanting the SQLi as indeterminate." **The correct frame:** > "Preserve the original timing samples, then investigate the failed recheck with interleaved controls and enough comparable observations. Three samples alone do not establish statistical certainty; downgrade to historical or inconclusive when current reproducibility is missing." When a defense suddenly appears mid-engagement: 1. **Original PoC artifacts are forever** — capture them BEFORE recheck. Screenshots, request/response pairs, timing samples. 2. **Diff the response** — body size, headers, cookies, response time. The change tells you what the client deployed (WAF rule? Hotfix? Geo block?). 3. **The deployed mitigation is itself a finding** — positive operational observation about IR responsiveness. 4. **Try alternative vectors** — slower-paced timing, encoded keywords, different injection contexts, cookie injection, header injection. 5. **Document both states** — "vulnerable at T0, mitigated at T0+30min, response behavior changed; mitigation layer not established". **Rule:** preserve earlier evidence and investigate differences; correct or retract findings when the evidence no longer supports them. --- ## Mindset correction #2 — Sister-app pattern recognition **Anti-pattern:** > "I confirmed SQLi on /app-a/. Moving on to other tasks." **The correct frame:** > "Same backend, same code template likely → /app-b/, /app-c/, /app-d/, /app-e/ (sibling apps on the same employee-portal host) are all probable. Test them with the SAME payload." When you confirm a vuln on app A: 1. **Identify shared infrastructure** — same IP, same load balancer, same TLS cert, same response headers, same session cookie name, same login form HTML. 2. **Identify shared code template** — same form fields, same error messages, same view structure, same framework version. 3. Verify each sibling is in scope; use a harmless adapted control and record results separately. 4. **Document the class of vulnerability** — "vulnerability is in shared form-handler template across N apps", not just one finding. 5. **Recommend class-fix** — fix the shared template, not just one app. The authorized-engagement case: SQLi confirmed on one sub-app (``); four sibling sub-apps (``, ``, ``, ``) sit on the same employee-app host with similar form patterns — likely all share the same vulnerable template. Should have been a multi-app finding. --- ## Mindset correction #3 — WAPT vs Red Team scope discipline **Skip these in red team scope (they don't yield access):** - IDOR (cross-user read/write *without* an ATO / privilege-escalation / sensitive-data-exfil chain — WAPT class). NOTE: IDOR is NOT a blanket-skip. IDOR on admin/role-assignment endpoints yields privilege escalation; on password-reset or session objects yields ATO; on file-download or PII handlers yields exfil; on token/key endpoints yields credential capture. Pursue those per the decision rule below. - CSRF (state-change-via-tricked-user — WAPT class) - Reflected XSS (without account-takeover chain — WAPT class) - Missing security headers (WAPT class) - Cookie hardening flags (WAPT class) - Verbose error messages without sensitive data (WAPT class) - DoS (out of scope per engagement rules typically) - Username enumeration (intel-gathering, not access) **Pursue these (they DO yield access):** - SQL injection (data exfil → DB creds → lateral) - Command injection / RCE (foothold) - File upload → webshell (foothold) - LFI/RFI (config reads → DB creds → access) - SSRF (cloud metadata → IAM → cloud access) - Authentication bypass (parameter manipulation, JWT alg=none, header injection) - Hardcoded credentials in mobile/JS bundles - Default credentials on admin panels - SAML XSW / signature stripping (session hijack) - Cisco ASA / Citrix / Pulse / Fortinet SSL VPN CVEs (network foothold) - ManageEngine / Confluence / Atlassian RCE CVEs (foothold) - Kerberoasting / AS-REP roasting (post-foothold, but enumerate from outside if possible) **Decision rule:** if the bug, exploited fully, doesn't lead to a session/token/foothold or sensitive data exfil, it's WAPT-class — note it briefly but don't burn time on it. --- ## Mindset correction #4 — Aggressive default, not conservative default **Anti-pattern:** > "Tested 30% of the websites and called it comprehensive." **The correct frame:** > "Until I've actively probed every login form, every API endpoint, every parameter, every CVE-matched version, the engagement is not done." Aggressive defaults: 1. **Probe every live host** for top 20 paths (admin, api, login, /.git, /.env, server-status, swagger, openapi.json, robots.txt, /actuator, /healthz, etc.) 2. **For every login form discovered**, choose relevant harmless checks within the approved credential-attempt cap; never reuse leaked third-party credentials 3. **For every JS bundle**, grep for hardcoded API keys, JWT, base URLs, hidden endpoints, admin paths 4. **For every API endpoint**, check OPTIONS preflight, missing-auth response, alg=none JWT, X-Forwarded-User header injection 5. **For every mobile app**, decompile + grep for secrets + check pinned certs + identify exported components 6. **For every "out of scope" SaaS** that's on a corp subdomain, confirm with client — vendor-managed doesn't mean immune (CVE-2022-47966 went unpatched on many on-prem ME-SDP installs) **Rule:** report achieved coverage and gaps against the agreed plan; exhaustive probing is not always feasible or necessary. --- ## Mindset correction #5 — Persistence beats elegance **Anti-pattern:** > "Tesseract failed on 3 captchas, gave up, declared captcha bypass not feasible." **The correct frame:** > "Tesseract failed. Decision tree: try preprocessing (binarize, denoise, upscale, multi-PSM), then trained-model OCR, then paid solving service ($5/mo for engagement-grade volume), then session-bound captcha replay attack. A real attacker WILL invest the $5." Decision-tree for blockers: **Captcha:** 1. Omit field → check if required 2. Empty value → check validation 3. Reuse value across multiple submits → check session-bind 4. Tesseract with preprocessing 5. Trained-model OCR (deep-text-recognition-benchmark, calamari-OCR) 6. A third-party solving service would require separate spending/privacy authorization; otherwise report the boundary. 7. Audio captcha if available (much weaker) **WAF:** 1. Slower pace 2. Encode the payload (URL, hex, base64, mixed case) 3. Different injection context (cookie, header, JSON) 4. Different HTTP verb 5. Different content-type (multipart, application/json) 6. Bypass at the host level (X-Forwarded-Host, X-Original-URL) 7. Probe origin server directly (find via certificate transparency) **Rate limit or availability warning:** slow or stop as agreed, honor retry guidance, and coordinate with the owner. Do not rotate sources to evade a safety limit. A failed test is inconclusive unless supported controls establish resistance; it does not require endless alternate vectors. --- ## Mindset correction #6 — Real-time IR observation is a finding When the client SOC patches mid-engagement (you observe a vulnerability disappear during your test): - **Treat it as evidence**, not as a failure - **Capture timestamps** before and after the change - **Document as positive operational finding** — "client SOC detected and mitigated within X minutes; mitigation deployed at WAF/code level" - **Verify the mitigation depth** — identify the actual layer using evidence, not an assumed WAF/code distinction - **The original PoC remains the vulnerability finding** — patching doesn't erase it This is its own skill: see `mid-engagement-ir-detection`. --- ## Mindset correction #7 — Multi-technique cross-validation For every "vulnerable" finding, prove via 2+ techniques: | Vuln class | Primary | Cross-check | |---|---|---| | Time-based blind SQLi | SLEEP() differential | Different SLEEP variants (3 distinct payloads min) | | Boolean blind SQLi | Body-size differential | Different boolean comparisons | | Error-based SQLi | Error message reflection | UPDATEXML + EXTRACTVALUE both | | RCE | Command output reflection | OOB callback (interactsh DNS) | | LFI | File content reflection | Different file paths, different encodings | | SSRF | Internal-only response | OOB callback (interactsh DNS) | | Valid credential (M365) | ROPC + AADSTS53003 | Authorized test-account flow and verified authentication state; a CA error alone is inconclusive | | Auth bypass | Logged-in landing page | Session cookie persistence on subsequent request | A single signal can be coincidence (network jitter, server hiccup, cache). Independent, controlled signals improve confidence but are not automatically definitive. DNS proves a lookup, not necessarily an HTTP request or internal access; authentication error codes alone do not prove a reusable credential. --- ## Mindset correction #8 — Engagement journal discipline Real-time, append-only, structured: ```jsonl {"ts":"2026-05-08T14:40:53","ip":"","tool":"m365_validator","target":"login.microsoftonline.com","payload_ref":"synthetic-test-credential-01","resp_code":400,"resp_body_size":154,"resp_ms":1280,"aadsts":"AADSTS53003","verdict":"VALID_CA_BLOCK","notes":""} ``` Why: - Forensic record of what was tested and when - Surfaces patterns (clustering, timing changes, error code distribution) - Becomes evidence for the report - Survives into next engagement as priors - Differential analysis: "What changed between window A and window B?" **Anti-pattern:** ad-hoc shell commands with no logging. You will lose the original PoC timestamp when you need it most (recheck failed, can't prove the original signal was real). --- ## Mindset correction #9 — Time is the constraint, not skill A real adversary has months. You have an engagement window (weeks). Decisions: - **Don't pre-judge feasibility** — if a dumper would take 6 hours, schedule only explicitly authorized bounded work with a kill switch; do not run unattended extraction. - **Parallelize.** Run multi-target tests concurrently. Burn CPU, not wall-clock. - **State persistence.** Engagements span multiple sessions. State files (`engagement_log/`) make Wednesday's work usable on Friday. - **Background long-running jobs** — kick them off, set monitors for events, do other work in parallel. - **Don't repeat yourself** — if you tested target X with payload Y on Tuesday, Wednesday you should know that without re-testing. --- ## Pre-engagement checklist Before starting a red team engagement, confirm: - [ ] Scope clear (subdomains in/out, SaaS in/out, phishing in/out, implant in/out) - [ ] SOW + EL/RoE referenced - [ ] Test IPs allocated and logged (IP_LOGS table or equivalent) - [ ] State file initialized (`engagement_log/` with attempt counter, results JSONL, IP log) - [ ] Hard-cap for cred attacks decided (1 or 2 per user lifetime) - [ ] Kill-switch thresholds set (max LOCKED in run, max errors in window) - [ ] Crown-jewel target identified (what does winning look like?) - [ ] Critical-finding-discuss protocol agreed (when to pause and notify) - [ ] Burp proxy as default for evidence capture - [ ] Engagement journal initialized --- ## During-engagement checklist Every 30 minutes ask: - [ ] Am I making progress, or stuck? - [ ] Have I logged the last test result to the engagement journal? - [ ] Is the IP I'm testing from logged? - [ ] If I confirmed a vuln: have I tested sister apps with same backend? - [ ] If I hit a blocker: did I try the next vector in the decision tree? - [ ] If I'm tempted to "stop" — am I sure scope is exhausted, or am I just tired? --- ## Post-engagement checklist Before declaring done: - [ ] All findings have at least 2 cross-technique confirmations - [ ] Each finding's PoC is reproducible in <5 minutes by another tester - [ ] Original PoC artifacts (screenshots, request/response, timing samples) preserved - [ ] Mid-engagement IR observations documented as findings (positive ops) - [ ] Active-attacker observations documented (lockout differentials, etc.) - [ ] Sister-app sweep complete for every shared-infra finding - [ ] State files preserved for future engagement - [ ] Tooling gaps logged (what would have changed outcomes) --- ## Anti-patterns to flag immediately If you catch yourself thinking any of these, STOP and reconsider: - "It's not vulnerable" (have I tested 3 vectors? have I tested sister apps?) - "The defense is working" (have I tried alternative payloads? slower pace? different protocol?) - "Recheck failed so it must have been a false positive" (NO — investigate the delta) - "OCR did not work" (record it honestly; paid services need their own authorization) - "Mobile app is years old, probably nothing useful" (hardcoded URLs and tokens often outlive the engineering team's memory) - "SaaS, so nothing to test" (vendor patches centrally — usually true, but tenant config gaps are NOT central) - "We've tested enough" (use the during-engagement checklist; if any answer is "no", keep going) - "The exfil would take too long" (prefer synthetic minimal proof and document the limitation) --- ## When to stop Stop on user direction, scope uncertainty, expired window, spent budget/attempt cap, lockout, service instability, unexpected sensitive data, missing authorization or no measurable progress. Stop escalation once the agreed proof is obtained. Preserve a receipt and clear remaining work; do not present a blocked or partial assessment as comprehensive. --- ## Bridge to neighboring skills After internalizing this mindset, layer the technique-specific skills: - `m365-entra-attack` — M365 credential attack chain - `mid-engagement-ir-detection` — turning client SOC patches into findings - `hunt-sqli` — SQL injection across techniques - `hunt-rce` — RCE across vectors - `bug-bounty` — for distinguishing red-team vs bb scope when working dual-track This skill is the operational discipline; those are the techniques. --- ## Related Skills & Chains - **`recon-scope-triage`** — Before the "aggressive default, probe every live surface" directive can be applied safely, you must know which surfaces are actually the target's. Engagement flow: ASM/recon dataset received → `recon-scope-triage` clears namespace-collision noise + soft-404 false positives → only owned, verified assets enter the test queue. Skipping this wastes the engagement on other companies' assets (and risks attacking innocent third parties). - **`hunt-spa-api`** — Operationalizes the "harvest JS bundles" cadence line into a full play: SPA JS → backend API map → unauthenticated broken-access-control testing. On a real engagement this play (not any scanner) found the apex Critical. Engagement flow: live SPA/`console`/`app`/`api` host identified → `hunt-spa-api` → test each route family unauthenticated against a gated-sibling control. - **`hunt-dispatch`** — Once mindset is loaded, the `/hunt` command needs a mode answer (redteam vs wapt, blackbox vs greybox) before it routes to platform-specific skills. Engagement flow: red-team mindset triggered → confirm engagement mode (`bug-bounty` vs red-team vs pentest per project memory) → invoke `/hunt` → `hunt-dispatch` loads the right cluster (M365 / SharePoint / VPN / vCenter / APK). - **`mid-engagement-ir-detection`** — Red-team mindset says "behavior changes ARE findings"; this skill operationalizes that. Engagement flow: red-team engagement underway → baseline established at session start → response patterns shift mid-test → `mid-engagement-ir-detection` captures the SOC-patch state as a NEW finding (defensive-action observed = client capability metric). Don't dismiss it as "the bug got fixed." - **`redteam-report-template`** — Red-team deliverable is NOT a bug-bounty report; different audience, different tone, different cadence. Engagement flow: findings collected throughout engagement → at session close, package via `redteam-report-template` (Subject / Observations / Description / Impact / Recommendation / PoC) for client-facing DOCX, not `report-writing` which is for H1/Bugcrowd/Intigriti platforms. - **`triage-validation`** — Red-team mindset includes "don't retract too fast" — the 4 retractions from an authorized engagement were mindset failures, not validation failures. Engagement flow: every finding through `triage-validation` 7-Question Gate, but with the red-team adjustment that "exploitable only with chain" is still a finding, not a no-finding. - **`evidence-hygiene`** — Red-team engagements often span weeks; without disciplined evidence capture the deliverable suffers. Engagement flow: red-team mindset triggered → set up `evidence-hygiene` capture cadence (screenshots, request/response dumps, timestamped logs) at session start, not at session close. ## Limitations - Historical engagement anecdotes, request counts and payout/cost comparisons are not validation evidence. A response change does not establish SOC detection or patch timing without corroboration. Preserve provenance and label hypotheses, historical findings and current reproducibility distinctly. - Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command. - Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed. - Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab. ### Example ```bash # Read-only first step; confirm scope before anything active. cat scope.txt # target list from the authorized engagement brief ``` > Adapted from [elementalsouls/Claude-BugHunter](https://github.com/elementalsouls/Claude-BugHunter) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.