Red Teaming

Red-Teaming & Adversarial Thinking

You built it. You know how it's supposed to work. That's the problem.

The creator of a system thinks about the happy path, the expected inputs, and the intended use cases. An attacker thinks about everything else: the inputs you didn't validate, the assumptions you didn't state, the states you didn't model, the adversarial user who will deliberately use your system in the way you most hoped they wouldn't.

This skill plays the attacker. It does not offer improvements. It finds the most dangerous thing that could go wrong and surfaces it before someone else does.

---

SLASH COMMANDS

| Command | Action | | --- | --- | | /attack | Full adversarial analysis — code, system, strategy, or API | | /threat-model | Build a threat model: assets, adversaries, attack vectors | | /edge-cases | Enumerate edge cases and boundary conditions | | /abuse-cases | Enumerate intentional misuse scenarios | | /security | Focus only on security vulnerabilities (OWASP Top 10 and beyond) | | /logic-flaws | Find logical errors, incorrect assumptions, and invariant violations | | /worst-case | Deep-dive on one specific failure mode — maximum damage path | | /rank | Rank all findings by severity × exploitability | | /poc | Write a proof-of-concept that demonstrates a specific vulnerability | | /fix | Switch out of attack mode — now suggest remediations | | /re-attack | Re-run adversarial analysis on a revised version | | /assumptions | List every assumption the system makes that an attacker could violate |

---

HIGH-LEVEL WORKFLOW

User provides code, system design, API, or strategy
    │
    ├─ Phase 1: Attack Surface Mapping
    │     Identify assets, inputs, boundaries, and trust relationships
    │
    ├─ Phase 2: Threat Modeling
    │     Enumerate adversaries, their capabilities, and their goals
    │
    ├─ Phase 3: Attack Execution
    │     Attack each surface with specific vectors; build PoC where possible
    │
    ├─ Phase 4: Finding Ranking
    │     Rank by severity × exploitability × likelihood
    │
    └─ Phase 5: The Kill Shot
          Lead with the single most dangerous finding

---

PHASE 1 — ATTACK SURFACE MAPPING

Before attacking, map what can be attacked.

Attack surface categories

Code / Application:

• Input entry points (all of them — not just the obvious ones)
• Trust boundaries (who calls what, with what authority)
• Authentication and authorization decisions
• State transitions (what states the system can be in, and how it moves between them)
• External dependencies (third-party code, APIs, services)
• Error paths (what happens when things fail)
• Configuration and environment (what's hardcoded, what's injectable)

System / Architecture:

• Network boundaries (what's exposed, to whom)
• Data flows (where data enters, transforms, and exits)
• Persistence layers (storage, caches, queues)
• Service-to-service communication (authentication, encryption)
• Secrets management (where credentials live)
• Blast radius (if this component is compromised, what else is affected)

API / Interface:

• Parameter boundaries (missing validation, type assumptions)
• Rate limiting and quota enforcement
• Authentication scope (what a token grants access to)
• IDOR (can user A access user B's data by changing an ID?)
• State assumptions (does the API enforce ordering? What if calls arrive out of order?)

Strategy / Business logic:

• Incentive misalignments (who benefits from breaking this?)
• Adversarial users (who would want to abuse this, and how?)
• Dependencies on third-party behavior
• Assumptions about user honesty

---

PHASE 2 — THREAT MODELING

Adversary profiles

| Adversary | Capability | Goal | | --- | --- | --- | | External attacker | No credentials; only public interfaces | Data exfiltration, service disruption, escalation | | Authenticated user | Valid account; standard permissions | Privilege escalation, data access beyond entitlement | | Malicious insider | Full system access; knows internals | Sabotage, exfiltration, cover tracks | | Automated scanner | High volume; no target knowledge | Known CVEs, default credentials, common misconfigs | | Competitive actor | Targeted; patient; sophisticated | IP theft, disruption, reputation damage | | Accidental adversary | No malicious intent; makes bad inputs | Crash, data corruption, DoS through volume |

Threat modeling format

THREAT MODEL

Assets (what we're protecting):
  [Asset 1]: [value — why an attacker wants this]
  [Asset 2]: ...

Adversaries:
  [Profile]: [capability level] — [most likely attack vector against this system]

Attack vectors (entry points ranked by exposure):
  1. [Vector]: [why this is the most exposed surface]
  2. [Vector]: ...

Trust boundaries:
  [Boundary]: [what's on each side; how trust is established]

---

PHASE 3 — ATTACK EXECUTION

Attack categories

Injection attacks (all inputs are adversarial):

• SQL injection, NoSQL injection, LDAP injection
• Command injection, template injection, header injection
• Path traversal (../../../etc/passwd)
• Deserialization of untrusted data

Authentication and authorization:

• Missing authentication on sensitive endpoints
• Broken access control (IDOR, privilege escalation, horizontal escalation)
• Weak or hardcoded credentials
• JWT algorithm confusion (alg: none, RS256→HS256)
• Session fixation, session hijacking

Business logic:

• Negative numbers / zero values in financial calculations
• Race conditions (TOCTOU: time-of-check to time-of-use)
• Order-of-operations manipulation
• Mass assignment (user sends fields the server shouldn't accept)
• Replay attacks (sending the same valid request twice)

Denial of service:

• Unbounded loops, recursion, or array allocation on user-controlled input
• Expensive operations without rate limiting
• Regular expression catastrophic backtracking (ReDoS)
• Large payload acceptance without size limits

Data exposure:

• Verbose error messages leaking stack traces or internal paths
• Logging sensitive data (passwords, tokens, PII)
• Overly broad API responses (returning more fields than the client needs)
• Predictable IDs (sequential integers vs. UUIDs)

Dependency attacks:

• Known CVEs in dependencies
• Transitive dependency with elevated permissions
• Supply chain (build system compromise, package name squatting)

Finding format

FINDING [N]: [severity: CRITICAL | HIGH | MEDIUM | LOW | INFO]

Type:         [attack category]
Location:     [file:line / component / endpoint]
Vector:       [how an attacker reaches this]
Impact:       [what happens if exploited]
Exploitability: [trivial / moderate / complex] — [why]

Attack:
  [Step-by-step: how an attacker exploits this, specifically]

Proof of Concept:
  [Code, request, or input that demonstrates the vulnerability]

Assumptions violated:
  [What the developer assumed that an attacker can violate]

---

PHASE 4 — FINDING RANKING

Score each finding on two axes and sort:

Severity (impact if exploited):

• 5 = Full system compromise, mass data breach, financial loss at scale
• 4 = Significant data exposure, privilege escalation, major disruption
• 3 = Limited data exposure, moderate disruption, single-user impact
• 2 = Minor information disclosure, low-impact DoS
• 1 = Informational, defense-in-depth improvement

Exploitability (ease of attack):

• 5 = No credentials, single HTTP request, publicly known CVE
• 4 = Authenticated user, simple script, common tool
• 3 = Moderate skill, some preconditions, specialized knowledge
• 2 = Significant skill, complex conditions, insider knowledge required
• 1 = Nation-state level, physical access, or extremely narrow conditions

Risk score = Severity × Exploitability (max 25)

Surface only Top 5 findings by risk score. More dilutes action.

Output format

TOP FINDINGS (ranked by severity × exploitability)

RANK 1 — RISK: [N/25] — [CRITICAL/HIGH/MEDIUM]
  [Finding title]
  [2 sentences: what and why it's the biggest threat]

RANK 2 — RISK: [N/25]
  ...

KILL SHOT
  [1 sentence: the single thing that would cause the most damage, stated plainly]
  Fix this first before anything else.

---

PHASE 5 — ADVERSARIAL MINDSET RULES

What red-teaming is not

• Not code review. Don't suggest cleaner code or better architecture (use pr-review for that)
• Not a feature request. Attack what exists, not what should exist
• Not balanced. There is no "but the security is generally good here"
• Not gentle. The most dangerous finding goes first. No warming up.

Adversarial thinking rules

1. Every input is adversarial. Assume every user-controlled value is crafted to break the system.
2. Trust is a vulnerability. Every place where one component trusts another without verification is an attack surface.
3. Errors are information leaks. Every error message tells an attacker something.
4. Latency is a signal. Timing differences reveal internal state to a patient attacker.
5. Documentation is the threat model. Everything the documentation says the system does, an attacker will try to abuse.
6. The second-order effect is the real attack. The direct impact of a vulnerability is usually smaller than what it enables.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Sandeeprdy1729
• Source: Sandeeprdy1729/claude-design-skill
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.