hunt-brute-force

Classify rate limit defense states and test brute force feasibility on authentication endpoints.

1.1k|191|Updated Jun 24, 2026
One-click install
npx skills add https://github.com/uphiago/recon-skills --skill hunt-brute-force-uphiago
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hunt-brute-force
Source: https://github.com/uphiago/recon-skills/tree/main/redteam/hunt-brute-force
Command: npx skills add https://github.com/uphiago/recon-skills --skill hunt-brute-force-uphiago

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill solves the critical gap of undetected brute force, missing or weak rate limiting, and authentication enumeration vulnerabilities that lead to account takeover, credential stuffing, denial of service, and financial loss in web applications. It eliminates false negative conclusions from naive rate limit checks that only look for 429 responses by teaching testers to classify four distinct rate limit defense states.

Core Features & Use Cases

  • 4-State Rate Limit Classification: Distinguishes hard account lockout, soft IP throttling, CAPTCHA injection, and silent shadow throttling to avoid false "no rate limit" findings.
  • Brute Force Feasibility Testing: Validates OTP/2FA brute force reachability (including 6-digit 10^6 keyspace math), password reset token brute force, and login credential stuffing risks.
  • Enumeration Detection: Identifies username/email enumeration via response string, status code, and timing oracle differences.
  • Bypass Testing: Checks for IP-based rate limit bypass via client-controlled headers like X-Forwarded-For.
  • Token Entropy Analysis: Measures the predictability of reset, session, and OTP tokens to assess brute force viability.
  • ReDoS Detection: Confirms catastrophic backtracking regex vulnerabilities with super-linear latency testing.
  • Use Case: A red teamer can use this Skill to test a corporate login portal, identify a shadow-throttled OTP endpoint with no effective rate limit, calculate that a 6-digit OTP can be brute forced in under 3 hours at observed throughput, and report a critical MFA bypass finding.

Quick Start

Use the hunt-brute-force skill to test a target's OTP verification endpoint for missing rate limiting and assess brute force feasibility leading to account takeover.

Frequently Asked Questions about hunt-brute-force

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test for brute force vulnerabilities in web authentication flows?

Testing for brute force vulnerabilities involves hunting for missing, weak, or bypassable rate limiting and authentication enumeration flaws across login endpoints, OTP verification, and password reset validation. It validates brute force keyspace reachability and token entropy to prevent account takeover.

Why does checking for a 429 response cause false negatives during rate limit testing?

Checking for a 429 response causes false negatives because rate limit defenses operate in four distinct states: hard account lockout, soft IP throttling, CAPTCHA injection, and silent shadow throttling. Classifying these specific defense states prevents inaccurate conclusions that no rate limiting exists.

Can I calculate the feasibility of brute forcing a 6-digit OTP endpoint?

Yes, you can calculate OTP brute force feasibility by validating keyspace reachability and measuring security token entropy. By applying 6-digit 10^6 keyspace math against observed endpoint throughput, you can determine if an MFA bypass is achievable within a specific timeframe.

How do I detect username enumeration via timing or response differences?

Detecting username enumeration requires identifying variations in response strings, HTTP status codes, and timing oracle differences during authentication processing. This exposes flaws that allow attackers to validate which usernames or emails exist in the target system.

How do I bypass rate limiting using IP rotation or client-controlled headers?

Bypassing rate limiting via IP rotation involves testing client-controlled headers like X-Forwarded-For to spoof originating IP addresses. This checks if the server incorrectly trusts these headers, allowing attackers to evade soft IP throttling restrictions.

How do I confirm ReDoS vulnerabilities with reproducible evidence?

Confirming ReDoS vulnerabilities requires executing super-linear latency testing on user input fields to detect catastrophic backtracking in regular expressions. This process generates reproducible evidence that validates the denial of service risk and eliminates false positive findings.