Cheetah: How Parallel Password Submission Breaks Webshell Brute-Force Performance Barriers

Hook

Most brute-force tools submit passwords sequentially—one attempt, wait for response, next attempt. Cheetah submits thousands simultaneously, turning a 10-hour attack into minutes.

Context

When security teams discover webshells during incident response or penetration testing, recovering the password becomes critical for understanding attacker capabilities and the extent of compromise. Traditional brute-force tools like Hydra or Medusa follow a synchronous pattern: submit a password, wait for the HTTP response, evaluate success or failure, then move to the next candidate. This approach makes sense for protocols where connection state matters, but webshells are typically stateless PHP, JSP, or ASP scripts that simply check a password parameter.

This sequential bottleneck becomes painful when testing realistic password dictionaries. A 100,000-word list against a webshell with 200ms response time means 5.5 hours of waiting, even though the server could theoretically handle hundreds of concurrent requests. Cheetah emerged from the Chinese security research community to exploit this gap—recognizing that webshell password validation is embarrassingly parallel and that HTTP servers are built to handle concurrent connections. By flooding the target with parallel password attempts, Cheetah transforms the economics of webshell password recovery.

Technical Insight

Cheetah's core architectural insight is treating password brute-forcing as a concurrent I/O problem rather than a sequential iteration task. The tool maintains a thread pool or async request queue that keeps multiple HTTP requests in flight simultaneously, only limited by the --thread parameter (default 10). Each worker thread grabs passwords from a shared queue, constructs an HTTP POST request with the candidate password, and fires it at the target without waiting for siblings to complete.

The auto-detection mechanism happens in an initial reconnaissance phase. Cheetah sends probe requests and analyzes HTTP response headers like Server, X-Powered-By, and response body patterns to identify both the web server (Apache, Nginx, IIS) and webshell type (PHP, JSP, ASP, ASPX). This fingerprinting determines the request payload structure:

# Simplified conceptual example of payload construction
def build_payload(webshell_type, password, param_name):
    if webshell_type == 'php':
        return {
            param_name: password,
            'action': 'login'  # Common PHP webshell pattern
        }
    elif webshell_type == 'jsp':
        return {
            param_name: password,
            'PWD': password  # JSP shells often use PWD parameter
        }
    elif webshell_type == 'asp':
        return {
            'pass': password,
            'action': 'validate'
        }
    # Auto-detection chooses the right template

Success detection is equally critical. Cheetah doesn't just check for HTTP 200 status codes—most webshells return 200 even on failed passwords. Instead, it analyzes response body length, specific keywords (like "success", "welcome", file manager HTML structures), and response time patterns. A successful login typically returns different content length or includes admin panel markup.

The password deduplication feature addresses a practical problem: security wordlists often contain duplicates from merged sources, and submitting identical passwords wastes network bandwidth. Cheetah streams the password file through a hash set:

# Conceptual streaming deduplication
def load_passwords_deduplicated(filepath):
    seen = set()
    with open(filepath, 'r', encoding='utf-8', errors='ignore') as f:
        for line in f:
            password = line.strip()
            if password and password not in seen:
                seen.add(password)
                yield password

This generator pattern keeps memory usage constant regardless of password file size—crucial when working with multi-gigabyte wordlists. The yield approach means passwords are processed in streaming fashion rather than loading millions of entries into RAM upfront.

The batch processing mode reads a file containing multiple webshell URLs and attacks them sequentially (though each individual attack is internally parallelized). This mirrors real-world scenarios where attackers plant multiple backdoors across a compromised server farm, and penetration testers need to validate which shells are still accessible.

Header forgery is another subtle but important feature. Cheetah randomizes or spoofs User-Agent, Referer, and X-Forwarded-For headers to avoid trivial detection by basic logging systems that flag repetitive patterns. While this won't defeat sophisticated WAFs, it helps against simple IP-based rate limiting or admin dashboards that just grep logs for anomalies.

Gotcha

Cheetah's primary limitation is its complete ineffectiveness against modern web application protections. Any webshell behind a rate-limiting WAF, CAPTCHA system, or even basic request throttling will shut down the parallel attack within seconds. The tool assumes a naive target that simply evaluates passwords without tracking request frequency—an increasingly rare scenario in production environments. Cloud-based WAF services like Cloudflare or AWS WAF would detect and block the flood of concurrent POST requests almost immediately.

The auto-detection feature, while convenient, fails on custom or obfuscated webshells. Real attackers frequently modify their backdoors to avoid signature detection, which means non-standard parameter names, unusual response patterns, or encrypted communication. When auto-detection fails, you need to manually specify webshell type, password parameter name, and success detection patterns—which often requires source code analysis or significant trial and error. Additionally, the tool shows its age with Python 2.x support mentioned prominently, and the repository hasn't seen active maintenance recently. The author references a GUI version that seems to have superseded the command-line tool, suggesting this codebase may be effectively abandoned. For production penetration testing, you'd likely need to fork and modify the code to handle target-specific quirks.

Verdict

Use if: You're conducting authorized penetration tests or incident response on legacy systems where webshells are deployed without modern protections, you need to test thousands of passwords against multiple webshell instances quickly, or you're researching webshell security and need a baseline tool to understand parallel attack patterns. Cheetah excels in lab environments, security training scenarios, and controlled assessments where speed matters more than evasion. Skip if: Your targets have any modern security controls (WAF, rate limiting, CAPTCHA), you need legal defensibility and active maintenance (the project appears dormant), you're working with custom webshells requiring specialized handling, or you lack explicit written authorization (using this tool without permission is illegal in most jurisdictions). For serious penetration testing work, treat Cheetah as a starting point for building custom tooling rather than a production-ready solution.