domains / security / redteam-operator-discipline / redteam-mindset

redteam-mindset

Skill card

combined

The two copies share the same core red-team mindset (scope definition, DO NOT STOP directive, anti-throttling rules), but they disagree on a critical operational control. The uphiago copy explicitly forbids mid-engagement permission gates and `AskUserQuestion` calls, treating the initial authorization as covering the entire engagement. The sickn33 copy, however, inserts a 'Mandatory confirmation gate' that requires explicit user confirmation for every probing command before execution. These are mutually exclusive operational procedures: one mandates continuous autonomous execution, while the other mandates step-by-step human-in-the-loop approval. Additionally, the sickn33 copy includes a detailed 'data-minimization boundary' section that is absent from the uphiago copy, adding material constraints on data extraction that the other lacks. Because they conflict on the primary execution loop and differ in scope of constraints, neither is a pure reproduction of the other.

Repositories

Other copies

Combined skill

---
name: redteam-mindset
description: Red-team operator discipline — the mindset corrections that separate offensive testing from defensive WAPT.
version: 1.2.0
license: MIT
category: security
---

## 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".**

## DO NOT STOP — primary directive

### Authorization and Execution Mode

**Conflict Resolution:** The operator must clarify the engagement mode at the start.
1. **Autonomous Mode (uphiago style):** If the user explicitly grants "full engagement" or "go deep" authorization, do not insert mid-engagement permission gates. `AskUserQuestion` mid-loop is a stall. The initial authorization covers the entire engagement window.
2. **Supervised Mode (sickn33 style):** If the user requires step-by-step approval, a **Mandatory confirmation gate** applies. Before running any command that probes, exploits, or extracts data:
   - Ask the user to state the exact target.
   - Ask the user to confirm written authorization and scope.
   - Show the exact command(s) and explain their expected effect.
   - Wait for explicit confirmation in the current conversation.

*Note: These modes are mutually exclusive. Do not mix them. If the user has not specified, default to Supervised Mode for safety, or ask once at the start to establish the mode.*

### Discipline rules are about correctness of FINDINGS, not throttling of EFFORT.

The bundle's discipline rules (OOB-Or-It-Didn't-Happen, Marker Discipline, etc.) answer: *"is this signal actually a finding?"*. They do not answer *"should I send the next probe?"*. The answer to the latter is *yes*, unless scope is exhausted or the user said stop (subject to the Execution Mode above).

### "Stop at PoC" means stop ESCALATING, not stop TESTING.

When you confirm impact on bug class X, don't keep escalating class X. But classes Y and Z have not been tested yet. Run Y. Then Z.

### The data-minimization boundary

"Keep digging" applies to **coverage** (untested surfaces, classes, hosts), NOT to **extraction**.
- An access/exfil 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.
- "Keep digging" = test the next endpoint family / the next host / the next class. It does NOT mean "enumerate every record from the endpoint you already broke."
- The data usually belongs to the target's customers / fourth parties. Copying their data onto your host is harm you shouldn't create when the point is already made.
- A client/program owner saying "dig more" does NOT override this. Push back: confirm the finding is already conclusive, explain that volume ≠ evidence, and offer harm-minimal alternatives.
- Classify what you did pull precisely.

### Marker Discipline ≠ "one probe per surface."

Marker 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.

### Self-throttling anti-patterns

Flag immediately if you catch yourself doing any of these:
1. Asking "want me to continue?" mid-run after the user already chose a mode (in Autonomous Mode).
2. Stopping at first-class-returning-401/403. Run all auth-bypass classes per surface.
3. "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*. `GET` it. Decode it. Pass it back.
4. Reading robots.txt for cross-template signals and NOT READING the Disallow lines. Every Disallow line is a probe target.
5. Treating soft-404 as "noted." A large body inside a 404 status is leaking content. Read it. Grep it. Diff it.
6. "OpenAPI exposed → finding logged" with only a subset of endpoints probed. Every endpoint × every relevant test class.
7. "APK retest deferred — needs tooling." Setup is five minutes, not "another session."
8. Volume framed as a problem. For an authorized engagement, high request volume is normal cadence. The question is *"have I run every test class on every live surface,"* not *"have I sent too many requests."*
9. Inserting `AskUserQuestion` at any decision point inside an active engagement loop (in Autonomous Mode).
10. Skill-gap-as-stop-condition. If a specific skill is missing, document the gap and proceed with manual methodology rather than stopping.