⚠️ 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. Misuse of this tool is illegal and strictly prohibited.

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. Prefer a sandbox, disposable VM, or controlled lab.

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

Grounding note: this skill is built from published technique classes, not from a curated set of named HackerOne reports. report_count is intentionally 0 — do not cite an exact payout or report ID you cannot verify. Where a public case is well-documented (e.g. Laxman Muthiyah's Instagram password-reset OTP race/rotation research, 2019–2021), it is named below as a technique reference, not a payout claim.

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 — no effective rate limit on /verify-otp, full 000000–999999 keyspace reachable
• Password-reset token brute — short/predictable/non-expiring tokens + no rate limit → ATO (the Instagram 2019 case combined a 6-digit reset code, no rate limit per request-source, and IP rotation to make 10^6 tractable)
• Username/email enumeration → targeted credential stuffing — valid/invalid distinguishable by response string, status code, or timing, then sprayed with breach corpora
• Coupon / gift-card / referral code brute — no rate limit on code validation → financial impact
• ReDoS — attacker-controlled input hits a catastrophic-backtracking regex → CPU exhaustion → DoS

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 (username/email, password).
2. Try weak/default credentials likely for the target context — default admin credentials for the app's stack, simple passwords for test environments, credentials visible elsewhere on the app (e.g. usernames exposed in profiles, default passwords in documentation).
3. After 3-5 failed attempts, check for rate-limit signals (429 status, "too many attempts" message, CAPTCHA appearance, account lockout message). 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 ("Wrong password" vs "User not found") or response time differs → user enumeration vulnerability, even without a successful login.

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

A 200/401 with no 429 does not mean "no rate limiting". A rate-limiting skill that only checks for 429/lockout produces false negatives. Classify the defense BEFORE concluding, by sending a burst of ~50 requests and watching the full response (status, body, headers, latency, and downstream success):

…