⚠️ 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:
- Ask the user to state the exact target URL, IP, account, or resource.
- Ask the user to confirm written authorization and the permitted scope.
- Show the exact command(s) and explain their expected effect.
- 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:
- Original PoC artifacts are forever — capture them BEFORE recheck. Screenshots, request/response pairs, timing samples.
- Diff the response — body size, headers, cookies, response time. The change tells you what the client deployed (WAF rule? Hotfix? Geo block?).
- The deployed mitigation is itself a finding — positive operational observation about IR responsiveness.
- Try alternative vectors — slower-paced timing, encoded keywords, different injection contexts, cookie injection, header injection.
- 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:
- Identify shared infrastructure — same IP, same load balancer, same TLS cert, same response headers, same session cookie name, same login form HTML.
- Identify shared code template — same form fields, same error messages, same view structure, same framework version.
- Verify each sibling is in scope; use a harmless adapted control and record results separately.
- Document the class of vulnerability — "vulnerability is in shared form-handler template across N apps", not just one finding.
- Recommend class-fix — fix the shared template, not just one app.
The authorized-engagement case: SQLi confirmed on one sub-app (<app-A>); four sibling sub-apps (<app-B>, <app-C>, <app-D>, <app-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.
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:
- Probe every live host for top 20 paths (admin, api, login, /.git, /.env, server-status, swagger, openapi.json, robots.txt, /actuator, /healthz, etc.)
- For every login form discovered, choose relevant harmless checks within the approved credential-attempt cap; never reuse leaked third-party credentials
- For every JS bundle, grep for hardcoded API keys, JWT, base URLs, hidden endpoints, admin paths
- For every API endpoint, check OPTIONS preflight, missing-auth response, alg=none JWT, X-Forwarded-User header injection
- For every mobile app, decompile + grep for secrets + check pinned certs + identify exported components
- 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:
- Omit field → check if required
- Empty value → check validation
- Reuse value across multiple submits → check session-bind
- Tesseract with preprocessing
- Trained-model OCR (deep-text-recognition-benchmark, calamari-OCR)
- A third-party solving service would require separate spending/privacy authorization; otherwise report the boundary.
- Audio captcha if available (much weaker)
WAF:
- Slower pace
- Encode the payload (URL, hex, base64, mixed case)
- Different injection context (cookie, header, JSON)
- Different HTTP verb
- Different content-type (multipart, application/json)
- Bypass at the host level (X-Forwarded-Host, X-Original-URL)
- 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:
{"ts":"2026-05-08T14:40:53","ip":"<src-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 chainmid-engagement-ir-detection— turning client SOC patches into findingshunt-sqli— SQL injection across techniqueshunt-rce— RCE across vectorsbug-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-triageclears 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/apihost identified →hunt-spa-api→ test each route family unauthenticated against a gated-sibling control.hunt-dispatch— Once mindset is loaded, the/huntcommand 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-bountyvs red-team vs pentest per project memory) → invoke/hunt→hunt-dispatchloads 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-detectioncaptures 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 viaredteam-report-template(Subject / Observations / Description / Impact / Recommendation / PoC) for client-facing DOCX, notreport-writingwhich 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 throughtriage-validation7-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 upevidence-hygienecapture 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 viareport-writing. Prefer a sandbox, disposable VM, or controlled lab.
Example
# Read-only first step; confirm scope before anything active.
cat scope.txt # target list from the authorized engagement brief
Adapted from 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.