redteam-mindset – Other skill for AI agents

> ⚠️ 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 (<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:

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 O

… (full content is in the download package)