domains / families / security / redteam-mindset

redteam-mindset

combined

Red-team operator discipline Red-team operator discipline — the mindset corrections that separate offensive testing from defensive WAPT. Built from authorized red-team work where conservative defaults caused multiple findings to be missed and one to be incorrectly retracted. Use at the START of any red-team engagement and again whenever feeling stuck or considering "stopping" on a defended target. The single most important skill to load when scope is "external red team" not "bug bounty / WAPT".

When to use

• 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
• Bug bounty programs (use bug-bounty skill — different scope rules)
• WAPT/PCI-style assessments (use OWASP-aligned skills)

When not to use

• 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 via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.

Skill page

Conflict

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.