sickn33/agentic-awesome-skills/redteam-mindset

⚠️ 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 OCR, then paid solving service ($5/mo for engagement-grade volume), then session-bound captcha replay attack. A real attacker WILL invest the $5."

Decision-tree for blockers:

Captcha:

1. Omit field → check if required
2. Empty value → check validation
3. Reuse value across multiple submits → check session-bind
4. Tesseract with preprocessing
5. Trained-model OCR (deep-text-recognition-benchmark, calamari-OCR)
6. A third-party solving service would require separate spending/privacy authorization; otherwise report the boundary.
7. Audio captcha if available (much weaker)

WAF:

1. Slower pace
2. Encode the payload (URL, hex, base64, mixed case)
3. Different injection context (cookie, header, JSON)
4. Different HTTP verb
5. Different content-type (multipart, application/json)
6. Bypass at the host level (X-Forwarded-Host, X-Original-URL)
7. Probe origin server directly (find via certificate transparency)

Rate limit or availability warning: slow or stop as agreed, honor retry guidance, and coordinate with the owner. Do not rotate sources to evade a safety limit. A failed test is inconclusive unless supported controls establish resistance; it does not require endless alternate vectors.

Mindset correction #6 — Real-time IR observation is a finding

When the client SOC patches mid-engagement (you observe a vulnerability disappear during your test):

• Treat it as evidence, not as a failure
• Capture timestamps before and after the change
• Document as positive operational finding — "client SOC detected and mitigated within X minutes; mitigation deployed at WAF/code level"
• Verify the mitigation depth — identify the actual layer using evidence, not an assumed WAF/code distinction
• The original PoC remains the vulnerability finding — patching doesn't erase it

This is its own skill: see mid-engagement-ir-detection.

Mindset correction #7 — Multi-technique cross-validation

For every "vulnerable" finding, prove via 2+ techniques: