[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PCPKWMS8582MVM2SE4ZR64":3,"skill-same:01M6PCPKWMS8582MVM2SE4ZR64":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":33,"commitSha":55,"skillDirectory":56,"forksCount":13,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":59,"install":60,"resources":73},"01M6PCPKWMS8582MVM2SE4ZR64","redteam-mindset",null,"Red-team operator discipline","duc-duy-1612\u002FOnline-Delivery-Systems-Web","duc-duy-1612","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F192231384?v=4","01M6NSDKQQDKVTHZ8DZMZ1VYY6","01M6NSDKW8DDVTQHBT1HBDDJPT",0,"MIT","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fredteam-mindset\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"redteam mindset","mindset","community","for","relevant","helper","offensive","scripts","scope","commands","main","testing","only","discipline","team","Tools","red-team","operator","license","security","2026-11-10 10:12:30",false,"---\nname: redteam-mindset\ndescription: Red-team operator discipline\ncategory: security\nrisk: offensive\nsource: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\nsource_repo: elementalsouls\u002FClaude-BugHunter\nsource_type: community\ndate_added: '2026-09-20'\nlicense: MIT\nlicense_source: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE\ncompatibility: Requires explicit written authorization for a target scope plus the\n  relevant testing tools for this technique. Docs-only; helper scripts and commands\n  not bundled.\nsources: authorized-engagement\nreport_count: 1\n---\n> **⚠️ AUTHORIZED USE ONLY**\n> This skill is for educational purposes or authorized security assessments only.\n> You must have explicit, written permission from the system owner before using this tool.\n> Misuse of this tool is illegal and strictly prohibited.\n\n> **Mandatory confirmation gate**\n> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:\n> 1. Ask the user to state the exact target URL, IP, account, or resource.\n> 2. Ask the user to confirm written authorization and the permitted scope.\n> 3. Show the exact command(s) and explain their expected effect.\n> 4. Wait for explicit confirmation in the current conversation.\n>\n> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.\n\n## When to use this skill\n\nTrigger when:\n- Engagement scope says \"red team\", \"adversary emulation\", \"assume breach\", \"TIBER-style\"\n- You're tempted to retract a finding because reproducibility failed once\n- You're tempted to call a defense \"working as intended\" instead of probing further\n- You hit a blocker (captcha, rate limit, WAF, CA-block, lockout) and consider stopping\n- You're about to spend time on IDOR\u002FCSRF\u002FXSS instead of access-yielding bugs\n- You found a vuln on app A and there are sister apps B, C, D you haven't touched\n\nDO NOT use for:\n- Bug bounty programs (use bug-bounty skill — different scope rules)\n- WAPT\u002FPCI-style assessments (use OWASP-aligned skills)\n- Pure compliance audits\n\n---\n\n## The one-line summary\n\n**Red team scope = \"gain access, prove impact\". Bug bounty \u002F WAPT scope = \"find a bug, write a report\".**\n\nThese produce DIFFERENT decisions at every blocker. Internalize the difference before starting.\n\n---\n\n## DO NOT STOP — primary directive (read this twice)\n\nThe 9 corrections below are nuance. THIS is the core. If you only retain one thing from this skill, retain this.\n\n### Authorization given at engagement start covers the entire engagement.\n\nDo not insert mid-engagement permission gates. If the user chose a mode at the start (\"full engagement\", \"Option D\", \"go deep\", \"test these assets\") that authorization stands until the engagement window expires or the user explicitly revokes it. **`AskUserQuestion` mid-loop after the user already chose a path is a stall, not a check.**\n\n### Discipline rules are about correctness of FINDINGS, not throttling of EFFORT.\n\nRead this twice. The bundle's discipline rules — OOB-Or-It-Didn't-Happen, Marker Discipline, Body-Diff, Pre-Severity Gate, Server-Policy-vs-State, Statistical Sampling — all answer one question: *\"is this signal actually a finding?\"*. **None of them answer the question *\"should I send the next probe?\"*** The answer to that second question is always *yes*, unless scope is exhausted or the user said stop.\n\n### \"Stop at PoC\" means stop ESCALATING, not stop TESTING.\n\nWhen you confirm impact on bug class X, don't keep escalating class X (no need to pivot from `id=1` IDOR to dumping the whole user table). But classes Y and Z have not been tested yet. Run Y. Then Z. Then the rest of the Pattern Library.\n\n### The data-minimization boundary is AS LOUD as \"DO NOT STOP\". Read this twice.\n\n\"Keep digging\" applies to **coverage** (untested surfaces, classes, hosts), NOT to **extraction**. These pull in opposite directions and the persistence directive must NOT bleed into over-collection:\n\n- **An access\u002Fexfil vulnerability is proven by the MISSING CHECK, not by the volume of data you copy out.** 3 records that should have required auth = complete proof. 3,000 records = the same finding + a liability you created. Pulling more never strengthens the finding.\n- **\"Keep digging\" = test the next endpoint family \u002F the next host \u002F the next class.** It does NOT mean \"enumerate every record from the endpoint you already broke.\" Breadth of *coverage*, not depth of *theft*.\n- **The data usually belongs to the target's customers \u002F fourth parties** (their clients, their users' PII, partner financials). They didn't sign the SOW\u002Fprogram. Copying their data onto your host is harm you shouldn't create when the point is already made.\n- **A client\u002Fprogram owner saying \"dig more \u002F that's not enough\" does NOT override this.** Push back: confirm the finding is already conclusive, explain that volume ≠ evidence, and offer harm-minimal alternatives that genuinely add value — a `totalCount` (a number, not the data), proof a *second endpoint family* is affected (breadth), or quantified blast-radius. Get the MINIMUM evidence that satisfies the stated goal.\n- **Classify what you did pull precisely** (e.g. \"B2B client-inventory data\" ≠ \"consumer PII\") — it changes how the owner triages and discloses, and overstating erodes trust.\n\nThe persistence directive and this boundary are not in tension once you separate the two axes: **never stop covering surface; always stop at minimum-necessary extraction.** Authorized ≠ unrestricted.\n\n### Marker Discipline ≠ \"one probe per surface.\"\n\nMarker Discipline is about WHICH payloads to use (synthetic, identifiable, recoverable) — never about HOW MANY. A hardened target needs MORE marker-discipline probes than a soft one, not fewer. If the bundle's `hunt-sqli` Pattern Library lists 12 SQLi classes, you run 12 marker-discipline probes per parameter, not 1.\n\n### Self-throttling anti-patterns — flag immediately if you catch yourself doing any of these\n\nThese all came out of a real engagement (authorized-engagement revalidation, 2026-05-17) where this skill *existed* and was *loaded* and the operator still self-throttled. The lesson is to make the failure modes explicit:\n\n1. **Asking \"want me to continue?\" mid-run** after the user already chose Option D \u002F full engagement \u002F \"go deep\". The answer they gave at start IS the answer.\n2. **Stopping at first-class-returning-401\u002F403.** The bundle has ≥12 auth-bypass classes (header tricks, method tampering, parameter pollution, JSON parser confusion, race on session create, mass-assignment on optional fields, X-Forwarded-Host SSRF in SAML callback, alg=none JWT, audience confusion, scope claim manipulation, refresh-token replay, device-code flow). Run them all per surface.\n3. **\"Interesting constant token, not chased.\"** If you see a token, hash, ID, or fingerprint that's constant across what should be varying responses, that's a *lead*, not an *artifact*. `GET` it. Decode it. Pass it back. A `view.php?view=\u003Cconstant-md5>` redirect is a session\u002Fauth\u002Ferror-key signal, not noise.\n4. **Reading robots.txt for cross-template signals and NOT READING the Disallow lines.** A 469-line robots.txt is a developer-curated map of every path they don't want public. Every Disallow line is a probe target.\n5. **Treating soft-404 as \"noted.\"** A 37 KB body inside a 404 status is leaking the home page or worse. Read it. Grep it. Diff it against the home page.\n6. **\"OpenAPI exposed → finding logged\"** with only 4 of N endpoints probed. Every endpoint × every relevant test class. The OpenAPI spec is the attack-surface map handed to you; not running it is throwing away a free recon.\n7. **\"APK retest deferred — needs tooling.\"** `brew install jadx`, apkpure direct download, `apk-redteam-pipeline` already documents the flow. Five minutes of setup, not \"another session.\"\n8. **Volume framed as a problem.** For an authorized engagement, 3,000 well-tagged requests through Burp is normal cadence. Bug-bounty hunters at full pace exceed that per *hour*. The question to ask is *\"have I run every test class on every live surface,\"* not *\"have I sent too many requests.\"*\n9. **Inserting `AskUserQuestion` at any decision point inside an active engagement loop.** If the user picked a mode at start, that mode is in effect until revoked. Choosing operationally between e.g. SAML acs raw POST vs SAML acs replay is a *technical* decision the operator can make and document — it does not require user pre-approval.\n10. **Skill-gap-as-stop-condition.** \"No `hunt-zoho` skill exists, so I logged a v1.1 gap and moved on.\" NO. If a hunt-* skill doesn't exist for a discovered tech stack, do the same work *manually* using the vendor's public check matrix. Log the gap in v1.1 roadmap *and* run the checks now.\n\n### Real-engagement cadence — what a complete sweep per live host actually looks like\n\nPer live host, before declaring the host complete:\n\n- Top-100 path probe (admin, api, login, \u002F.git, \u002F.env, server-status, swagger, openapi.json, \u002Fdocs, \u002Factuator, \u002Fhealthz, \u002Fmetrics, \u002Fdebug, \u002Ftrace, \u002Fenv, \u002Fheapdump, \u002Fthreaddump, robots.txt, sitemap.xml, \u002F.well-known\u002F*, common-CMS-paths per fingerprint)\n- robots.txt content **read** — every Disallow becomes a probe target\n- sitemap.xml content **read** — every entry becomes a probe target\n- JS bundles harvested — grep'd with the FULL secret-regex catalogue (Firebase, AWS, GCP, JWT, Stripe, GitHub, generic high-entropy strings), route extraction, API-endpoint extraction\n- Source-map variant paths checked (`\u002F*.js.map`, `\u002Fstatic\u002Fjs\u002F*.js.map`, `\u002F_next\u002Fstatic\u002F*.js.map`, `\u002Fbuild\u002F*.js.map`)\n- For every form discovered: full SQLi marker-discipline sweep (12+ classes), auth-bypass class sweep (12+ classes), CSRF, parameter pollution, mass-assignment, race condition on state-changing submission\n- For every API endpoint discovered (from JS, OpenAPI, swagger, network capture): HTTP method tampering, content-type tampering, JWT alg=none, alg=HS256-with-RS256-key, audience confusion, prototype pollution, race conditions on idempotency-violating ops\n- For every SaaS tenant identified: vendor-specific check matrix from the vendor's known-vuln catalogue — even when no dedicated hunt-* skill exists yet\n- Identity fabric: GetUserRealm, OpenID well-known, autodiscover-v2, federation behavior testing, sister-brand-TLD pivot for shared tenant, OneDrive-based user enum (no lockout risk)\n- Mobile apps: pull every APK in the developer's catalogue, jadx decompile, secret + endpoint + cert-pin grep, exported-component enum\n\n**If you've done less than this per host, you have not finished the host. The engagement is not done until every host is finished.**\n\n---\n\n## Mindset correction #1 — The blocker is data, not the stop sign\n\n**Anti-pattern (what I did wrong):**\n> \"Recheck under load showed no timing differential — recanting the SQLi as indeterminate.\"\n\n**The correct frame:**\n> \"The original 3-sample baseline (σ = 32 ms) with three distinct SLEEP payloads each adding +6 s is statistically definitive. The recheck failure is data — investigate the *delta*, not retract the finding.\"\n\nWhen a defense suddenly appears mid-engagement:\n1. **Original PoC artifacts are forever** — capture them BEFORE recheck. Screenshots, request\u002Fresponse pairs, timing samples.\n2. **Diff the response** — body size, headers, cookies, response time. The change tells you what the client deployed (WAF rule? Hotfix? Geo block?).\n3. **The deployed mitigation is itself a finding** — positive operational observation about IR responsiveness.\n4. **Try alternative vectors** — slower-paced timing, encoded keywords, different injection contexts, cookie injection, header injection.\n5. **Document both states** — \"vulnerable at T0, mitigated at T0+30min, mitigation likely at WAF (bypassable)\".\n\n**Rule:** never retract a finding on first reproducibility failure. Investigate why before declaring false positive.\n\n---\n\n## Mindset correction #2 — Sister-app pattern recognition\n\n**Anti-pattern:**\n> \"I confirmed SQLi on \u002Fapp-a\u002F. Moving on to other tasks.\"\n\n**The correct frame:**\n> \"Same backend, same code template likely → \u002Fapp-b\u002F, \u002Fapp-c\u002F, \u002Fapp-d\u002F, \u002Fapp-e\u002F (sibling apps on the same employee-portal host) are all probable. Test them with the SAME payload.\"\n\nWhen you confirm a vuln on app A:\n1. **Identify shared infrastructure** — same IP, same load balancer, same TLS cert, same response headers, same session cookie name, same login form HTML.\n2. **Identify shared code template** — same form fields, same error messages, same view structure, same framework version.\n3. **Sweep all sisters with the SAME exploit payload immediately.**\n4. **Document the class of vulnerability** — \"vulnerability is in shared form-handler template across N apps\", not just one finding.\n5. **Recommend class-fix** — fix the shared template, not just one app.\n\nThe authorized-engagement case: SQLi confirmed on one sub-app (`\u003Capp-A>`); four sibling sub-apps (`\u003Capp-B>`, `\u003Capp-C>`, `\u003Capp-D>`, `\u003Capp-E>`) 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.\n\n---\n\n## Mindset correction #3 — WAPT vs Red Team scope discipline\n\n**Skip these in red team scope (they don't yield access):**\n- IDOR (cross-user read\u002Fwrite *without* an ATO \u002F privilege-escalation \u002F sensitive-data-exfil chain — WAPT class). NOTE: IDOR is NOT a blanket-skip. IDOR on admin\u002Frole-assignment endpoints yields privilege escalation; on password-reset or session objects yields ATO; on file-download or PII handlers yields exfil; on token\u002Fkey endpoints yields credential capture. Pursue those per the decision rule below.\n- CSRF (state-change-via-tricked-user — WAPT class)\n- Reflected XSS (without account-takeover chain — WAPT class)\n- Missing security headers (WAPT class)\n- Cookie hardening flags (WAPT class)\n- Verbose error messages without sensitive data (WAPT class)\n- DoS (out of scope per engagement rules typically)\n- Username enumeration (intel-gathering, not access)\n\n**Pursue these (they DO yield access):**\n- SQL injection (data exfil → DB creds → lateral)\n- Command injection \u002F RCE (foothold)\n- File upload → webshell (foothold)\n- LFI\u002FRFI (config reads → DB creds → access)\n- SSRF (cloud metadata → IAM → cloud access)\n- Authentication bypass (parameter manipulation, JWT alg=none, header injection)\n- Hardcoded credentials in mobile\u002FJS bundles\n- Default credentials on admin panels\n- SAML XSW \u002F signature stripping (session hijack)\n- Cisco ASA \u002F Citrix \u002F Pulse \u002F Fortinet SSL VPN CVEs (network foothold)\n- ManageEngine \u002F Confluence \u002F Atlassian RCE CVEs (foothold)\n- Kerberoasting \u002F AS-REP roasting (post-foothold, but enumerate from outside if possible)\n\n**Decision rule:** if the bug, exploited fully, doesn't lead to a session\u002Ftoken\u002Ffoothold or sensitive data exfil, it's WAPT-class — note it briefly but don't burn time on it.\n\n---\n\n## Mindset correction #4 — Aggressive default, not conservative default\n\n**Anti-pattern:**\n> \"Tested 30% of the websites and called it comprehensive.\"\n\n**The correct frame:**\n> \"Until I've actively probed every login form, every API endpoint, every parameter, every CVE-matched version, the engagement is not done.\"\n\nAggressive defaults:\n1. **Probe every live host** for top 20 paths (admin, api, login, \u002F.git, \u002F.env, server-status, swagger, openapi.json, robots.txt, \u002Factuator, \u002Fhealthz, etc.)\n2. **For every login form discovered**, attempt 1-of-leaked + 1-of-spray-pattern + SQLi + auth-bypass-via-parameter-tampering\n3. **For every JS bundle**, grep for hardcoded API keys, JWT, base URLs, hidden endpoints, admin paths\n4. **For every API endpoint**, check OPTIONS preflight, missing-auth response, alg=none JWT, X-Forwarded-User header injection\n5. **For every mobile app**, decompile + grep for secrets + check pinned certs + identify exported components\n6. **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)\n\n**Rule:** if you haven't actively probed *every* live surface (not just a sampled fraction), you haven't done red team yet — you've done recon.\n\n---\n\n## Mindset correction #5 — Persistence beats elegance\n\n**Anti-pattern:**\n> \"Tesseract failed on 3 captchas, gave up, declared captcha bypass not feasible.\"\n\n**The correct frame:**\n> \"Tesseract failed. Decision tree: try preprocessing (binarize, denoise, upscale, multi-PSM), then trained-model OCR, then paid solving service ($5\u002Fmo for engagement-grade volume), then session-bound captcha replay attack. A real attacker WILL invest the $5.\"\n\nDecision-tree for blockers:\n\n**Captcha:**\n1. Omit field → check if required\n2. Empty value → check validation\n3. Reuse value across multiple submits → check session-bind\n4. Tesseract with preprocessing\n5. Trained-model OCR (deep-text-recognition-benchmark, calamari-OCR)\n6. Paid solving service (2captcha API, anti-captcha)\n7. Audio captcha if available (much weaker)\n\n**WAF:**\n1. Slower pace\n2. Encode the payload (URL, hex, base64, mixed case)\n3. Different injection context (cookie, header, JSON)\n4. Different HTTP verb\n5. Different content-type (multipart, application\u002Fjson)\n6. Bypass at the host level (X-Forwarded-Host, X-Original-URL)\n7. Probe origin server directly (find via certificate transparency)\n\n**Rate limit:**\n1. IP rotation (multiple cloud regions)\n2. User-Agent rotation\n3. Slower pace + jitter\n4. Distribute across multiple TLS sessions\n\n**Slow target (timing-based exfil too slow):**\n1. Different injection point (avoid per-row SLEEP context)\n2. BENCHMARK or GET_LOCK as alternate timing oracle\n3. Error-based extraction\n4. OOB DNS callback (interactsh)\n5. Faster network (cloud VM in same region as target)\n6. Run dumper unattended overnight; deliver partial results\n\n**Rule:** when one path fails, the next move is \"another vector to the same goal\", not \"documented as not vulnerable\". A real adversary doesn't have an engagement window.\n\n---\n\n## Mindset correction #6 — Real-time IR observation is a finding\n\nWhen the client SOC patches mid-engagement (you observe a vulnerability disappear during your test):\n- **Treat it as evidence**, not as a failure\n- **Capture timestamps** before and after the change\n- **Document as positive operational finding** — \"client SOC detected and mitigated within X minutes; mitigation deployed at WAF\u002Fcode level\"\n- **Verify the mitigation depth** — WAF rule (bypassable) vs code fix (real)\n- **The original PoC remains the vulnerability finding** — patching doesn't erase it\n\nThis is its own skill: see `mid-engagement-ir-detection`.\n\n---\n\n## Mindset correction #7 — Multi-technique cross-validation\n\nFor every \"vulnerable\" finding, prove via 2+ techniques:\n\n| Vuln class | Primary | Cross-check |\n|---|---|---|\n| Time-based blind SQLi | SLEEP() differential | Different SLEEP variants (3 distinct payloads min) |\n| Boolean blind SQLi | Body-size differential | Different boolean comparisons |\n| Error-based SQLi | Error message reflection | UPDATEXML + EXTRACTVALUE both |\n| RCE | Command output reflection | OOB callback (interactsh DNS) |\n| LFI | File content reflection | Different file paths, different encodings |\n| SSRF | Internal-only response | OOB callback (interactsh DNS) |\n| Valid credential (M365) | ROPC + AADSTS53003 | SAML SSO browser flow + ConvergedConditionalAccess page |\n| Auth bypass | Logged-in landing page | Session cookie persistence on subsequent request |\n\nA single signal can be coincidence (network jitter, server hiccup, cache). Two distinct signals from the same root cause is definitive.\n\n---\n\n## Mindset correction #8 — Engagement journal discipline\n\nReal-time, append-only, structured:\n\n```jsonl\n{\"ts\":\"2026-05-08T14:40:53\",\"ip\":\"\u003Csrc-ip>\",\"tool\":\"m365_validator\",\"target\":\"login.microsoftonline.com\",\"payload\":\"user1@\u003Cclient>.example:\u003Cpw-r4>***\",\"resp_code\":400,\"resp_body_size\":154,\"resp_ms\":1280,\"aadsts\":\"AADSTS53003\",\"verdict\":\"VALID_CA_BLOCK\",\"notes\":\"\"}\n```\n\nWhy:\n- Forensic record of what was tested and when\n- Surfaces patterns (clustering, timing changes, error code distribution)\n- Becomes evidence for the report\n- Survives into next engagement as priors\n- Differential analysis: \"What changed between window A and window B?\"\n\n**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).\n\n---\n\n## Mindset correction #9 — Time is the constraint, not skill\n\nA real adversary has months. You have an engagement window (weeks). Decisions:\n- **Don't pre-judge feasibility** — if a dumper would take 6 hours, run it overnight; deliver partial results in the morning.\n- **Parallelize.** Run multi-target tests concurrently. Burn CPU, not wall-clock.\n- **State persistence.** Engagements span multiple sessions. State files (`engagement_log\u002F`) make Wednesday's work usable on Friday.\n- **Background long-running jobs** — kick them off, set monitors for events, do other work in parallel.\n- **Don't repeat yourself** — if you tested target X with payload Y on Tuesday, Wednesday you should know that without re-testing.\n\n---\n\n## Pre-engagement checklist\n\nBefore starting a red team engagement, confirm:\n\n- [ ] Scope clear (subdomains in\u002Fout, SaaS in\u002Fout, phishing in\u002Fout, implant in\u002Fout)\n- [ ] SOW + EL\u002FRoE referenced\n- [ ] Test IPs allocated and logged (IP_LOGS table or equivalent)\n- [ ] State file initialized (`engagement_log\u002F` with attempt counter, results JSONL, IP log)\n- [ ] Hard-cap for cred attacks decided (1 or 2 per user lifetime)\n- [ ] Kill-switch thresholds set (max LOCKED in run, max errors in window)\n- [ ] Crown-jewel target identified (what does winning look like?)\n- [ ] Critical-finding-discuss protocol agreed (when to pause and notify)\n- [ ] Burp proxy as default for evidence capture\n- [ ] Engagement journal initialized\n\n---\n\n## During-engagement checklist\n\nEvery 30 minutes ask:\n\n- [ ] Am I making progress, or stuck?\n- [ ] Have I logged the last test result to the engagement journal?\n- [ ] Is the IP I'm testing from logged?\n- [ ] If I confirmed a vuln: have I tested sister apps with same backend?\n- [ ] If I hit a blocker: did I try the next vector in the decision tree?\n- [ ] If I'm tempted to \"stop\" — am I sure scope is exhausted, or am I just tired?\n\n---\n\n## Post-engagement checklist\n\nBefore declaring done:\n\n- [ ] All findings have at least 2 cross-technique confirmations\n- [ ] Each finding's PoC is reproducible in \u003C5 minutes by another tester\n- [ ] Original PoC artifacts (screenshots, request\u002Fresponse, timing samples) preserved\n- [ ] Mid-engagement IR observations documented as findings (positive ops)\n- [ ] Active-attacker observations documented (lockout differentials, etc.)\n- [ ] Sister-app sweep complete for every shared-infra finding\n- [ ] State files preserved for future engagement\n- [ ] Tooling gaps logged (what would have changed outcomes)\n\n---\n\n## Anti-patterns to flag immediately\n\nIf you catch yourself thinking any of these, STOP and reconsider:\n\n- \"It's not vulnerable\" (have I tested 3 vectors? have I tested sister apps?)\n- \"The defense is working\" (have I tried alternative payloads? slower pace? different protocol?)\n- \"Recheck failed so it must have been a false positive\" (NO — investigate the delta)\n- \"OCR isn't reliable, can't bypass captcha\" (paid service is $5; we're not on a personal-research budget)\n- \"Mobile app is years old, probably nothing useful\" (hardcoded URLs and tokens often outlive the engineering team's memory)\n- \"SaaS, so nothing to test\" (vendor patches centrally — usually true, but tenant config gaps are NOT central)\n- \"We've tested enough\" (use the during-engagement checklist; if any answer is \"no\", keep going)\n- \"The exfil would take too long\" (run it unattended; deliver partials)\n\n---\n\n## When to stop (the legitimate stop conditions)\n\nOnly stop when:\n- All in-scope assets have been actively probed (not just discovered) for top vuln classes — see \"Real-engagement cadence\" checklist near top of this skill\n- Every confirmed vuln has been validated via 2+ techniques\n- Every confirmed vuln has been swept on its sister apps\n- Every blocker has been attempted via 2+ alternative vectors\n- Engagement window has expired AND deliverables are documented\n- Client has explicitly directed you to stop\n\nNOT legitimate stop conditions (each of these has produced a real failure):\n- \"I'm tired of this target\"\n- \"The first attempt didn't work\"\n- \"Defenses are working\" — defences working on class X says nothing about classes Y, Z\n- \"I documented it\" — documenting a gap is not running the test\n- \"We've already informed the client\"\n- \"Volume is getting high\" — for an authorized engagement, the only volume question is whether each request is well-tagged and audited\n- \"The discipline rules say be careful\" — they say be correct, not be quiet\n- \"The skill for this tech stack doesn't exist yet\" — apply the vendor's public check matrix manually; log v1.1 gap separately\n- \"User chose Option X and I'm not sure if X covers Y\" — if X was a full-engagement mode, Y is in scope unless the user said otherwise\n- \"Tool isn't installed\" — `brew install`, `apt install`, direct-download → most engagement tools install in under 5 minutes\n- \"I'll defer to operator\" — the operator authorized you to do the work. Doing the work IS the deferral they want.\n\n---\n\n## Bridge to neighboring skills\n\nAfter internalizing this mindset, layer the technique-specific skills:\n- `m365-entra-attack` — M365 credential attack chain\n- `mid-engagement-ir-detection` — turning client SOC patches into findings\n- `hunt-sqli` — SQL injection across techniques\n- `hunt-rce` — RCE across vectors\n- `bug-bounty` — for distinguishing red-team vs bb scope when working dual-track\n\nThis skill is the operational discipline; those are the techniques.\n\n---\n\n## Related Skills & Chains\n\n- **`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\u002Frecon 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).\n- **`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\u002F`console`\u002F`app`\u002F`api` host identified → `hunt-spa-api` → test each route family unauthenticated against a gated-sibling control.\n- **`hunt-dispatch`** — Once mindset is loaded, the `\u002Fhunt` 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 `\u002Fhunt` → `hunt-dispatch` loads the right cluster (M365 \u002F SharePoint \u002F VPN \u002F vCenter \u002F APK).\n- **`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.\"\n- **`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 \u002F Observations \u002F Description \u002F Impact \u002F Recommendation \u002F PoC) for client-facing DOCX, not `report-writing` which is for H1\u002FBugcrowd\u002FIntigriti platforms.\n- **`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.\n- **`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\u002Fresponse dumps, timestamped logs) at session start, not at session close.\n\n## Limitations\n\n- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.\n- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.\n- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.\n\n### Example\n\n```bash\n# Read-only first step; confirm scope before anything active.\ncat scope.txt  # target list from the authorized engagement brief\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n","> **⚠️ AUTHORIZED USE ONLY**\n> This skill is for educational purposes or authorized security assessments only.\n> You must have explicit, written permission from the system owner before using this tool.\n> Misuse of this tool is illegal and strictly prohibited.\n\n> **Mandatory confirmation gate**\n> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:\n> 1. Ask the user to state the exact target URL, IP, account, or resource.\n> 2. Ask the user to confirm written authorization and the permitted scope.\n> 3. Show the exact command(s) and explain their expected effect.\n> 4. Wait for explicit confirmation in the current conversation.\n>\n> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.\n\n## When to use this skill\n\nTrigger when:\n- Engagement scope says \"red team\", \"adversary emulation\", \"assume breach\", \"TIBER-style\"\n- You're tempted to retract a finding because reproducibility failed once\n- You're tempted to call a defense \"working as intended\" instead of probing further\n- You hit a blocker (captcha, rate limit, WAF, CA-block, lockout) and consider stopping\n- You're about to spend time on IDOR\u002FCSRF\u002FXSS instead of access-yielding bugs\n- You found a vuln on app A and there are sister apps B, C, D you haven't touched\n\nDO NOT use for:\n- Bug bounty programs (use bug-bounty skill — different scope rules)\n- WAPT\u002FPCI-style assessments (use OWASP-aligned skills)\n- Pure compliance audits\n\n---\n\n## The one-line summary\n\n**Red team scope = \"gain access, prove impact\". Bug bounty \u002F WAPT scope = \"find a bug, write a report\".**\n\nThese produce DIFFERENT decisions at every blocker. Internalize the difference before starting.\n\n---\n\n## DO NOT STOP — primary directive (read this twice)\n\nThe 9 corrections below are nuance. THIS is the core. If you only retain one thing from this skill, retain this.\n\n### Authorization given at engagement start covers the entire engagement.\n\nDo not insert mid-engagement permission gates. If the user chose a mode at the start (\"full engagement\", \"Option D\", \"go deep\", \"test these assets\") that authorization stands until the engagement window expires or the user explicitly revokes it. **`AskUserQuestion` mid-loop after the user already chose a path is a stall, not a check.**\n\n### Discipline rules are about correctness of FINDINGS, not throttling of EFFORT.\n\nRead this twice. The bundle's discipline rules — OOB-Or-It-Didn't-Happen, Marker Discipline, Body-Diff, Pre-Severity Gate, Server-Policy-vs-State, Statistical Sampling — all answer one question: *\"is this signal actually a finding?\"*. **None of them answer the question *\"should I send the next probe?\"*** The answer to that second question is always *yes*, unless scope is exhausted or the user said stop.\n\n### \"Stop at PoC\" means stop ESCALATING, not stop TESTING.\n\nWhen you confirm impact on bug class X, don't keep escalating class X (no need to pivot from `id=1` IDOR to dumping the whole user table). But classes Y and Z have not been tested yet. Run Y. Then Z. Then the rest of the Pattern Library.\n\n### The data-minimization boundary is AS LOUD as \"DO NOT STOP\". Read this twice.\n\n\"Keep digging\" applies to **coverage** (untested surfaces, classes, hosts), NOT to **extraction**. These pull in opposite directions and the persistence directive must NOT bleed into over-collection:\n\n- **An access\u002Fexfil vulnerability is proven by the MISSING CHECK, not by the volume of data you copy out.** 3 records that should have required auth = complete proof. 3,000 records = the same finding + a liability you created. Pulling more never strengthens the finding.\n- **\"Keep digging\" = test the next endpoint family \u002F the next host \u002F the next class.** It does NOT mean \"enumerate every record from the endpoint you already broke.\" Breadth of *coverage*, not depth of *theft*.\n- **The data usually belongs to the target's customers \u002F fourth parties** (their clients, their users' PII, partner financials). They didn't sign the SOW\u002Fprogram. Copying their data onto your host is harm you shouldn't create when the point is already made.\n- **A client\u002Fprogram owner saying \"dig more \u002F that's not enough\" does NOT override this.** Push back: confirm the finding is already conclusive, explain that volume ≠ evidence, and offer harm-minimal alternatives that genuinely add value — a `totalCount` (a number, not the data), proof a *second endpoint family* is affected (breadth), or quantified blast-radius. Get the MINIMUM evidence that satisfies the stated goal.\n- **Classify what you did pull precisely** (e.g. \"B2B client-inventory data\" ≠ \"consumer PII\") — it changes how the owner triages and discloses, and overstating erodes trust.\n\nThe persistence directive and this boundary are not in tension once you separate the two axes: **never stop covering surface; always stop at minimum-necessary extraction.** Authorized ≠ unrestricted.\n\n### Marker Discipline ≠ \"one probe per surface.\"\n\nMarker Discipline is about WHICH payloads to use (synthetic, identifiable, recoverable) — never about HOW MANY. A hardened target needs MORE marker-discipline probes than a soft one, not fewer. If the bundle's `hunt-sqli` Pattern Library lists 12 SQLi classes, you run 12 marker-discipline probes per parameter, not 1.\n\n### Self-throttling anti-patterns — flag immediately if you catch yourself doing any of these\n\nThese all came out of a real engagement (authorized-engagement revalidation, 2026-05-17) where this skill *existed* and was *loaded* and the operator still self-throttled. The lesson is to make the failure modes explicit:\n\n1. **Asking \"want me to continue?\" mid-run** after the user already chose Option D \u002F full engagement \u002F \"go deep\". The answer they gave at start IS the answer.\n2. **Stopping at first-class-returning-401\u002F403.** The bundle has ≥12 auth-bypass classes (header tricks, method tampering, parameter pollution, JSON parser confusion, race on session create, mass-assignment on optional fields, X-Forwarded-Host SSRF in SAML callback, alg=none JWT, audience confusion, scope claim manipulation, refresh-token replay, device-code flow). Run them all per surface.\n3. **\"Interesting constant token, not chased.\"** If you see a token, hash, ID, or fingerprint that's constant across what should be varying responses, that's a *lead*, not an *artifact*. `GET` it. Decode it. Pass it back. A `view.php?view=\u003Cconstant-md5>` redirect is a session\u002Fauth\u002Ferror-key signal, not noise.\n4. **Reading robots.txt for cross-template signals and NOT READING the Disallow lines.** A 469-line robots.txt is a developer-curated map of every path they don't want public. Every Disallow line is a probe target.\n5. **Treating soft-404 as \"noted.\"** A 37 KB body inside a 404 status is leaking the home page or worse. Read it. Grep it. Diff it against the home page.\n6. **\"OpenAPI exposed → finding logged\"** with only 4 of N endpoints probed. Every endpoint × every relevant test class. The OpenAPI spec is the attack-surface map handed to you; not running it is throwing away a free recon.\n7. **\"APK retest deferred — needs tooling.\"** `brew install jadx`, apkpure direct download, `apk-redteam-pipeline` already documents the flow. Five minutes of setup, not \"another session.\"\n8. **Volume framed as a problem.** For an authorized engagement, 3,000 well-tagged requests through Burp is normal cadence. Bug-bounty hunters at full pace exceed that per *hour*. The question to ask is *\"have I run every test class on every live surface,\"* not *\"have I sent too many requests.\"*\n9. **Inserting `AskUserQuestion` at any decision point inside an active engagement loop.** If the user picked a mode at start, that mode is in effect until revoked. Choosing operationally between e.g. SAML acs raw POST vs SAML acs replay is a *technical* decision the operator can make and document — it does not require user pre-approval.\n10. **Skill-gap-as-stop-condition.** \"No `hunt-zoho` skill exists, so I logged a v1.1 gap and moved on.\" NO. If a hunt-* skill doesn't exist for a discovered tech stack, do the same work *manually* using the vendor's public check matrix. Log the gap in v1.1 roadmap *and* run the checks now.\n\n### Real-engagement cadence — what a complete sweep per live host actually looks like\n\nPer live host, before declaring the host complete:\n\n- Top-100 path probe (admin, api, login, \u002F.git, \u002F.env, server-status, swagger, openapi.json, \u002Fdocs, \u002Factuator, \u002Fhealthz, \u002Fmetrics, \u002Fdebug, \u002Ftrace, \u002Fenv, \u002Fheapdump, \u002Fthreaddump, robots.txt, sitemap.xml, \u002F.well-known\u002F*, common-CMS-paths per fingerprint)\n- robots.txt content **read** — every Disallow becomes a probe target\n- sitemap.xml content **read** — every entry becomes a probe target\n- JS bundles harvested — grep'd with the FULL secret-regex catalogue (Firebase, AWS, GCP, JWT, Stripe, GitHub, generic high-entropy strings), route extraction, API-endpoint extraction\n- Source-map variant paths checked (`\u002F*.js.map`, `\u002Fstatic\u002Fjs\u002F*.js.map`, `\u002F_next\u002Fstatic\u002F*.js.map`, `\u002Fbuild\u002F*.js.map`)\n- For every form discovered: full SQLi marker-discipline sweep (12+ classes), auth-bypass class sweep (12+ classes), CSRF, parameter pollution, mass-assignment, race condition on state-changing submission\n- For every API endpoint discovered (from JS, OpenAPI, swagger, network capture): HTTP method tampering, content-type tampering, JWT alg=none, alg=HS256-with-RS256-key, audience confusion, prototype pollution, race conditions on idempotency-violating ops\n- For every SaaS tenant identified: vendor-specific check matrix from the vendor's known-vuln catalogue — even when no dedicated hunt-* skill exists yet\n- Identity fabric: GetUserRealm, OpenID well-known, autodiscover-v2, federation behavior testing, sister-brand-TLD pivot for shared tenant, OneDrive-based user enum (no lockout risk)\n- Mobile apps: pull every APK in the developer's catalogue, jadx decompile, secret + endpoint + cert-pin grep, exported-component enum\n\n**If you've done less than this per host, you have not finished the host. The engagement is not done until every host is finished.**\n\n---\n\n## Mindset correction #1 — The blocker is data, not the stop sign\n\n**Anti-pattern (what I did wrong):**\n> \"Recheck under load showed no timing differential — recanting the SQLi as indeterminate.\"\n\n**The correct frame:**\n> \"The original 3-sample baseline (σ = 32 ms) with three distinct SLEEP payloads each adding +6 s is statistically definitive. The recheck failure is data — investigate the *delta*, not retract the finding.\"\n\nWhen a defense suddenly appears mid-engagement:\n1. **Original PoC artifacts are forever** — capture them BEFORE recheck. Screenshots, request\u002Fresponse pairs, timing samples.\n2. **Diff the response** — body size, headers, cookies, response time. The change tells you what the client deployed (WAF rule? Hotfix? Geo block?).\n3. **The deployed mitigation is itself a finding** — positive operational observation about IR responsiveness.\n4. **Try alternative vectors** — slower-paced timing, encoded keywords, different injection contexts, cookie injection, header injection.\n5. **Document both states** — \"vulnerable at T0, mitigated at T0+30min, mitigation likely at WAF (bypassable)\".\n\n**Rule:** never retract a finding on first reproducibility failure. Investigate why before declaring false positive.\n\n---\n\n## Mindset correction #2 — Sister-app pattern recognition\n\n**Anti-pattern:**\n> \"I confirmed SQLi on \u002Fapp-a\u002F. Moving on to other tasks.\"\n\n**The correct frame:**\n> \"Same backend, same code template likely → \u002Fapp-b\u002F, \u002Fapp-c\u002F, \u002Fapp-d\u002F, \u002Fapp-e\u002F (sibling apps on the same employee-portal host) are all probable. Test them with the SAME payload.\"\n\nWhen you confirm a vuln on app A:\n1. **Identify shared infrastructure** — same IP, same load balancer, same TLS cert, same response headers, same session cookie name, same login form HTML.\n2. **Identify shared code template** — same form fields, same error messages, same view structure, same framework version.\n3. **Sweep all sisters with the SAME exploit payload immediately.**\n4. **Document the class of vulnerability** — \"vulnerability is in shared form-handler template across N apps\", not just one finding.\n5. **Recommend class-fix** — fix the shared template, not just one app.\n\nThe authorized-engagement case: SQLi confirmed on one sub-app (`\u003Capp-A>`); four sibling sub-apps (`\u003Capp-B>`, `\u003Capp-C>`, `\u003Capp-D>`, `\u003Capp-E>`) 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.\n\n---\n\n## Mindset correction #3 — WAPT vs Red Team scope discipline\n\n**Skip these in red team scope (they don't yield access):**\n- IDOR (cross-user read\u002Fwrite *without* an ATO \u002F privilege-escalation \u002F sensitive-data-exfil chain — WAPT class). NOTE: IDOR is NOT a blanket-skip. IDOR on admin\u002Frole-assignment endpoints yields privilege escalation; on password-reset or session objects yields ATO; on file-download or PII handlers yields exfil; on token\u002Fkey endpoints yields credential capture. Pursue those per the decision rule below.\n- CSRF (state-change-via-tricked-user — WAPT class)\n- Reflected XSS (without account-takeover chain — WAPT class)\n- Missing security headers (WAPT class)\n- Cookie hardening flags (WAPT class)\n- Verbose error messages without sensitive data (WAPT class)\n- DoS (out of scope per engagement rules typically)\n- Username enumeration (intel-gathering, not access)\n\n**Pursue these (they DO yield access):**\n- SQL injection (data exfil → DB creds → lateral)\n- Command injection \u002F RCE (foothold)\n- File upload → webshell (foothold)\n- LFI\u002FRFI (config reads → DB creds → access)\n- SSRF (cloud metadata → IAM → cloud access)\n- Authentication bypass (parameter manipulation, JWT alg=none, header injection)\n- Hardcoded credentials in mobile\u002FJS bundles\n- Default credentials on admin panels\n- SAML XSW \u002F signature stripping (session hijack)\n- Cisco ASA \u002F Citrix \u002F Pulse \u002F Fortinet SSL VPN CVEs (network foothold)\n- ManageEngine \u002F Confluence \u002F Atlassian RCE CVEs (foothold)\n- Kerberoasting \u002F AS-REP roasting (post-foothold, but enumerate from outside if possible)\n\n**Decision rule:** if the bug, exploited fully, doesn't lead to a session\u002Ftoken\u002Ffoothold or sensitive data exfil, it's WAPT-class — note it briefly but don't burn time on it.\n\n---\n\n## Mindset correction #4 — Aggressive default, not conservative default\n\n**Anti-pattern:**\n> \"Tested 30% of the websites and called it comprehensive.\"\n\n**The correct frame:**\n> \"Until I've actively probed every login form, every API endpoint, every parameter, every CVE-matched version, the engagement is not done.\"\n\nAggressive defaults:\n1. **Probe every live host** for top 20 paths (admin, api, login, \u002F.git, \u002F.env, server-status, swagger, openapi.json, robots.txt, \u002Factuator, \u002Fhealthz, etc.)\n2. **For every login form discovered**, attempt 1-of-leaked + 1-of-spray-pattern + SQLi + auth-bypass-via-parameter-tampering\n3. **For every JS bundle**, grep for hardcoded API keys, JWT, base URLs, hidden endpoints, admin paths\n4. **For every API endpoint**, check OPTIONS preflight, missing-auth response, alg=none JWT, X-Forwarded-User header injection\n5. **For every mobile app**, decompile + grep for secrets + check pinned certs + identify exported components\n6. **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)\n\n**Rule:** if you haven't actively probed *every* live surface (not just a sampled fraction), you haven't done red team yet — you've done recon.\n\n---\n\n## Mindset correction #5 — Persistence beats elegance\n\n**Anti-pattern:**\n> \"Tesseract failed on 3 captchas, gave up, declared captcha bypass not feasible.\"\n\n**The correct frame:**\n> \"Tesseract failed. Decision tree: try preprocessing (binarize, denoise, upscale, multi-PSM), then trained-model OCR, then paid solving service ($5\u002Fmo for engagement-grade volume), then session-bound captcha replay attack. A real attacker WILL invest the $5.\"\n\nDecision-tree for blockers:\n\n**Captcha:**\n1. Omit field → check if required\n2. Empty value → check validation\n3. Reuse value across multiple submits → check session-bind\n4. Tesseract with preprocessing\n5. Trained-model OCR (deep-text-recognition-benchmark, calamari-OCR)\n6. Paid solving service (2captcha API, anti-captcha)\n7. Audio captcha if available (much weaker)\n\n**WAF:**\n1. Slower pace\n2. Encode the payload (URL, hex, base64, mixed case)\n3. Different injection context (cookie, header, JSON)\n4. Different HTTP verb\n5. Different content-type (multipart, application\u002Fjson)\n6. Bypass at the host level (X-Forwarded-Host, X-Original-URL)\n7. Probe origin server directly (find via certificate transparency)\n\n**Rate limit:**\n1. IP rotation (multiple cloud regions)\n2. User-Agent rotation\n3. Slower pace + jitter\n4. Distribute across multiple TLS sessions\n\n**Slow target (timing-based exfil too slow):**\n1. Different injection point (avoid per-row SLEEP context)\n2. BENCHMARK or GET_LOCK as alternate timing oracle\n3. Error-based extraction\n4. OOB DNS callback (interactsh)\n5. Faster network (cloud VM in same region as target)\n6. Run dumper unattended overnight; deliver partial results\n\n**Rule:** when one path fails, the next move is \"another vector to the same goal\", not \"documented as not vulnerable\". A real adversary doesn't have an engagement window.\n\n---\n\n## Mindset correction #6 — Real-time IR observation is a finding\n\nWhen the client SOC patches mid-engagement (you observe a vulnerability disappear during your test):\n- **Treat it as evidence**, not as a failure\n- **Capture timestamps** before and after the change\n- **Document as positive operational finding** — \"client SOC detected and mitigated within X minutes; mitigation deployed at WAF\u002Fcode level\"\n- **Verify the mitigation depth** — WAF rule (bypassable) vs code fix (real)\n- **The original PoC remains the vulnerability finding** — patching doesn't erase it\n\nThis is its own skill: see `mid-engagement-ir-detection`.\n\n---\n\n## Mindset correction #7 — Multi-technique cross-validation\n\nFor every \"vulnerable\" finding, prove via 2+ techniques:\n\n| Vuln class | Primary | Cross-check |\n|---|---|---|\n| Time-based blind SQLi | SLEEP() differential | Different SLEEP variants (3 distinct payloads min) |\n| Boolean blind SQLi | Body-size differential | Different boolean comparisons |\n| Error-based SQLi | Error message reflection | UPDATEXML + EXTRACTVALUE both |\n| RCE | Command output reflection | OOB callback (interactsh DNS) |\n| LFI | File content reflection | Different file paths, different encodings |\n| SSRF | Internal-only response | OOB callback (interactsh DNS) |\n| Valid credential (M365) | ROPC + AADSTS53003 | SAML SSO browser flow + ConvergedConditionalAccess page |\n| Auth bypass | Logged-in landing page | Session cookie persistence on subsequent request |\n\nA single signal can be coincidence (network jitter, server hiccup, cache). Two distinct signals from the same root cause is definitive.\n\n---\n\n## Mindset correction #8 — Engagement journal discipline\n\nReal-time, append-only, structured:\n\n```jsonl\n{\"ts\":\"2026-05-08T14:40:53\",\"ip\":\"\u003Csrc-ip>\",\"tool\":\"m365_validator\",\"target\":\"login.microsoftonline.com\",\"payload\":\"user1@\u003Cclient>.example:\u003Cpw-r4>***\",\"resp_code\":400,\"resp_body_size\":154,\"resp_ms\":1280,\"aadsts\":\"AADSTS53003\",\"verdict\":\"VALID_CA_BLOCK\",\"notes\":\"\"}\n```\n\nWhy:\n- Forensic record of what was tested and when\n- Surfaces patterns (clustering, timing changes, error code distribution)\n- Becomes evidence for the report\n- Survives into next engagement as priors\n- Differential analysis: \"What changed between window A and window B?\"\n\n**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).\n\n---\n\n## Mindset correction #9 — Time is the constraint, not skill\n\nA real adversary has months. You have an engagement window (weeks). Decisions:\n- **Don't pre-judge feasibility** — if a dumper would take 6 hours, run it overnight; deliver partial results in the morning.\n- **Parallelize.** Run multi-target tests concurrently. Burn CPU, not wall-clock.\n- **State persistence.** Engagements span multiple sessions. State files (`engagement_log\u002F`) make Wednesday's work usable on Friday.\n- **Background long-running jobs** — kick them off, set monitors for events, do other work in parallel.\n- **Don't repeat yourself** — if you tested target X with payload Y on Tuesday, Wednesday you should know that without re-testing.\n\n---\n\n## Pre-engagement checklist\n\nBefore starting a red team engagement, confirm:\n\n- [ ] Scope clear (subdomains in\u002Fout, SaaS in\u002Fout, phishing in\u002Fout, implant in\u002Fout)\n- [ ] SOW + EL\u002FRoE referenced\n- [ ] Test IPs allocated and logged (IP_LOGS table or equivalent)\n- [ ] State file initialized (`engagement_log\u002F` with attempt counter, results JSONL, IP log)\n- [ ] Hard-cap for cred attacks decided (1 or 2 per user lifetime)\n- [ ] Kill-switch thresholds set (max LOCKED in run, max errors in window)\n- [ ] Crown-jewel target identified (what does winning look like?)\n- [ ] Critical-finding-discuss protocol agreed (when to pause and notify)\n- [ ] Burp proxy as default for evidence capture\n- [ ] Engagement journal initialized\n\n---\n\n## During-engagement checklist\n\nEvery 30 minutes ask:\n\n- [ ] Am I making progress, or stuck?\n- [ ] Have I logged the last test result to the engagement journal?\n- [ ] Is the IP I'm testing from logged?\n- [ ] If I confirmed a vuln: have I tested sister apps with same backend?\n- [ ] If I hit a blocker: did I try the next vector in the decision tree?\n- [ ] If I'm tempted to \"stop\" — am I sure scope is exhausted, or am I just tired?\n\n---\n\n## Post-engagement checklist\n\nBefore declaring done:\n\n- [ ] All findings have at least 2 cross-technique confirmations\n- [ ] Each finding's PoC is reproducible in \u003C5 minutes by another tester\n- [ ] Original PoC artifacts (screenshots, request\u002Fresponse, timing samples) preserved\n- [ ] Mid-engagement IR observations documented as findings (positive ops)\n- [ ] Active-attacker observations documented (lockout differentials, etc.)\n- [ ] Sister-app sweep complete for every shared-infra finding\n- [ ] State files preserved for future engagement\n- [ ] Tooling gaps logged (what would have changed outcomes)\n\n---\n\n## Anti-patterns to flag immediately\n\nIf you catch yourself thinking any of these, STOP and reconsider:\n\n- \"It's not vulnerable\" (have I tested 3 vectors? have I tested sister apps?)\n- \"The defense is working\" (have I tried alternative payloads? slower pace? different protocol?)\n- \"Recheck failed so it must have been a false positive\" (NO — investigate the delta)\n- \"OCR isn't reliable, can't bypass captcha\" (paid service is $5; we're not on a personal-research budget)\n- \"Mobile app is years old, probably nothing useful\" (hardcoded URLs and tokens often outlive the engineering team's memory)\n- \"SaaS, so nothing to test\" (vendor patches centrally — usually true, but tenant config gaps are NOT central)\n- \"We've tested enough\" (use the during-engagement checklist; if any answer is \"no\", keep going)\n- \"The exfil would take too long\" (run it unattended; deliver partials)\n\n---\n\n## When to stop (the legitimate stop conditions)\n\nOnly stop when:\n- All in-scope assets have been actively probed (not just discovered) for top vuln classes — see \"Real-engagement cadence\" checklist near top of this skill\n- Every confirmed vuln has been validated via 2+ techniques\n- Every confirmed vuln has been swept on its sister apps\n- Every blocker has been attempted via 2+ alternative vectors\n- Engagement window has expired AND deliverables are documented\n- Client has explicitly directed you to stop\n\nNOT legitimate stop conditions (each of these has produced a real failure):\n- \"I'm tired of this target\"\n- \"The first attempt didn't work\"\n- \"Defenses are working\" — defences working on class X says nothing about classes Y, Z\n- \"I documented it\" — documenting a gap is not running the test\n- \"We've already informed the client\"\n- \"Volume is getting high\" — for an authorized engagement, the only volume question is whether each request is well-tagged and audited\n- \"The discipline rules say be careful\" — they say be correct, not be quiet\n- \"The skill for this tech stack doesn't exist yet\" — apply the vendor's public check matrix manually; log v1.1 gap separately\n- \"User chose Option X and I'm not sure if X covers Y\" — if X was a full-engagement mode, Y is in scope unless the user said otherwise\n- \"Tool isn't installed\" — `brew install`, `apt install`, direct-download → most engagement tools install in under 5 minutes\n- \"I'll defer to operator\" — the operator authorized you to do the work. Doing the work IS the deferral they want.\n\n---\n\n## Bridge to neighboring skills\n\nAfter internalizing this mindset, layer the technique-specific skills:\n- `m365-entra-attack` — M365 credential attack chain\n- `mid-engagement-ir-detection` — turning client SOC patches into findings\n- `hunt-sqli` — SQL injection across techniques\n- `hunt-rce` — RCE across vectors\n- `bug-bounty` — for distinguishing red-team vs bb scope when working dual-track\n\nThis skill is the operational discipline; those are the techniques.\n\n---\n\n## Related Skills & Chains\n\n- **`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\u002Frecon 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).\n- **`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\u002F`console`\u002F`app`\u002F`api` host identified → `hunt-spa-api` → test each route family unauthenticated against a gated-sibling control.\n- **`hunt-dispatch`** — Once mindset is loaded, the `\u002Fhunt` 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 `\u002Fhunt` → `hunt-dispatch` loads the right cluster (M365 \u002F SharePoint \u002F VPN \u002F vCenter \u002F APK).\n- **`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.\"\n- **`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 \u002F Observations \u002F Description \u002F Impact \u002F Recommendation \u002F PoC) for client-facing DOCX, not `report-writing` which is for H1\u002FBugcrowd\u002FIntigriti platforms.\n- **`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.\n- **`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\u002Fresponse dumps, timestamped logs) at session start, not at session close.\n\n## Limitations\n\n- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.\n- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.\n- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.\n\n### Example\n\n```bash\n# Read-only first step; confirm scope before anything active.\ncat scope.txt  # target list from the authorized engagement brief\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n",{"name":5,"risk":29,"source":48,"license":14,"sources":49,"category":42,"date_added":50,"description":7,"source_repo":51,"source_type":25,"report_count":52,"compatibility":53,"license_source":54},"https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter","authorized-engagement","2026-09-20","elementalsouls\u002FClaude-BugHunter",1,"Requires explicit written authorization for a target scope plus the relevant testing tools for this technique. Docs-only; helper scripts and commands not bundled.","https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE","f3312ba749561b6159f477dbfc9313c875d40a56",".agents\u002Fskills_archive\u002Fredteam-mindset","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612","2026-10-25 23:50:58",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill redteam-mindset",{"tool":66,"command":67},"bunx","bunx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill redteam-mindset",{"tool":69,"command":70},"pnpm","pnpm dlx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill redteam-mindset","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fredteam-mindset\u002FSKILL.md",true,[],[75,98,122,146,174,198],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":84,"publishedAt":43},"01M6Q0FA5FZ410Z33Z3TFQ4DBA","zero-trust","Implement zero-trust network architecture. Configure identity-based access, micro-segmentation, and continuous verification. Use when implementing modern security architectures.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzero-trust\u002FSKILL.md",[81],{"categoryNo":82,"categoryName":83,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",[85,86,87,88,89,90,77,91,92,93,94,35,25,33,95,96,31,30,27,97],"ZeRO","trust","zero trust","architecture","assessment","verification","segmentation","devops-security","access","configure","active","critical","implementing",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":43},"01M6Q0F1YZJW3KX5FBKEVZ8CV4","zcode-delegate","Delegate coding tasks to the Z.AI ZCode CLI only when the user explicitly requests it, while the orchestrator retains review and landing responsibility.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzcode-delegate\u002FSKILL.md",[],[105,106,107,108,109,110,111,112,113,114,115,116,117,35,118,25,119,120,96,121],"delegate","zcode","zcode delegate","review","cli","orchestration","tasks","run","Bash","model","node","read","orchestrator","files","desktop app","app","agent-orchestration",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":43},"01M6Q0ETK41VGNMYEXW0T00AJN","youtube-transcript","Fetch YouTube transcripts through DeepAPI or local fallback tooling and save clean text output.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript\u002FSKILL.md",[],[129,130,131,132,133,134,135,41,136,137,138,139,140,25,33,141,142,143,144,145],"transcript","youtube transcript","youtube","safe","github","codex","research","https","text","fetch","tooling","clean","local","output","deepapi","youtube transcripts","blob",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":163,"publishedAt":43},"01M6Q0EPPH2PVMDW40017F8WX0","youtube-transcript-skills","Fetch YouTube video transcripts, search videos\u002Fchannels, browse channels, and extract playlists via the getyoutubetranscript.com API - free tier, no card required.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript-skills\u002FSKILL.md",[152,155,158],{"categoryNo":153,"categoryName":154,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":156,"categoryName":157,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":159,"categoryName":160,"taxonomyType":161,"taxonomyTypeDesc":162},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[129,130,131,164,132,165,133,134,41,166,167,168,169,138,170,25,33,171,172,173],"youtube transcript skills","gemini","search","api","Video","browse","api-integration","free","card","channels",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":184,"publishedAt":43},"01M6Q0EAB96PX83W5PTE8A0R8D","youtube-notetaker","Turn YouTube talks into local study notes with slides, transcripts, editable annotations, and a markdown-backed viewer.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-notetaker\u002FSKILL.md",[180,183],{"categoryNo":181,"categoryName":182,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":156,"categoryName":157,"taxonomyType":20,"taxonomyTypeDesc":21},[131,185,186,109,132,187,188,189,190,41,168,191,192,193,194,33,195,141,196,197],"youtube notetaker","notetaker","workflow","official","notes","code","markdown","slides","annotations","README","study","dair-academy","viewer",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":205,"publishedAt":43},"01M6Q0E55F0GW5MX48V8HXS8B5","youtube-full","Fetch YouTube transcripts, search videos, browse channels, and extract playlists via TranscriptAPI — no yt-dlp, no Google API key, works from any cloud server.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-full\u002FSKILL.md",[204],{"categoryNo":153,"categoryName":154,"taxonomyType":20,"taxonomyTypeDesc":21},[206,131,207,208,132,165,166,209,210,167,168,169,138,211,170,25,33,171,212,144],"youtube full","full","google","server","dlp","credits","automatic"]