Kraken: The Swiss Army Knife Problem in Brute Force Tooling

Hook

The most popular brute force tools aren't the most effective—they're just the easiest to remember the syntax for. Kraken bets your entire engagement strategy on that observation.

Context

During penetration tests, red teamers face a context-switching tax: SSH needs Hydra syntax, WordPress requires wpscan flags, FTP wants Medusa arguments, and subdomain enumeration demands completely different tooling. Each protocol-specific tool evolved independently, creating a fragmented ecosystem where remembering incantations wastes more time than the actual reconnaissance. Kraken emerged from this friction, proposing a radical simplification: wrap everything behind numbered menus so you never touch man pages again.

The promise is seductive for junior pentesters and CTF players—launch one script, pick option 7 for WordPress, feed it a wordlist, and watch credentials roll in. No remembering that Hydra's SSH module is 'ssh' but FTP is 'ftp' while HTTP is 'http-post-form' with arcane placeholder syntax. Just navigate menus like it's 1995. This design philosophy trades power-user efficiency for universal accessibility, which works brilliantly until you encounter the first rate-limited login form or IP-banning WAF.

Technical Insight

Kraken's architecture is deliberately primitive: kraken.py presents a text-based menu that dispatches to standalone modules living in subdirectories. There's no shared abstraction layer, no plugin system, no job queue. Each module is an independent Python script that duplicates the same patterns—read wordlist files, spawn threads, iterate credentials, print results. Here's what a typical SSH brute force module looks like under the hood:

import paramiko
import threading
from queue import Queue

def ssh_attempt(host, port, username, password, results):
    client = paramiko.SSHClient()
    client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    try:
        client.connect(host, port=port, username=username, 
                      password=password, timeout=5, 
                      allow_agent=False, look_for_keys=False)
        results.append(f"[+] {username}:{password}")
        client.close()
    except paramiko.AuthenticationException:
        pass
    except Exception as e:
        pass

def brute_ssh(host, port, usernames, passwords, threads=10):
    queue = Queue()
    results = []
    
    for user in usernames:
        for passwd in passwords:
            queue.put((user, passwd))
    
    def worker():
        while not queue.empty():
            user, passwd = queue.get()
            ssh_attempt(host, port, user, passwd, results)
            queue.task_done()
    
    for _ in range(threads):
        t = threading.Thread(target=worker)
        t.daemon = True
        t.start()
    
    queue.join()
    return results

This pattern repeats with minor variations across FTP (using ftplib), LDAP (ldap3), and database protocols. The threading model is naive—no connection pooling, no backpressure handling, no exponential backoff on failures. If you configure 50 threads against a rate-limited target, all 50 attempts fire simultaneously, trip threshold detectors, and your IP gets blacklisted before exhausting even 1% of your wordlist.

The CMS modules follow a different pattern, making HTTP requests to known admin endpoints. WordPress brute forcing targets /wp-login.php with POST requests containing log and pwd parameters, checking responses for the absence of error strings. There's no session handling for CSRF tokens, no cookie jar persistence, and zero consideration for JavaScript-rendered login forms:

import requests

def wordpress_login(url, username, password):
    login_url = f"{url}/wp-login.php"
    data = {
        'log': username,
        'pwd': password,
        'wp-submit': 'Log In'
    }
    try:
        response = requests.post(login_url, data=data, timeout=10)
        if 'wp-admin' in response.url or 'dashboard' in response.text:
            return True
    except:
        pass
    return False

This works against default WordPress installations from 2015 but fails immediately against modern setups with login throttling plugins like Limit Login Attempts, two-factor authentication, or Cloudflare bot protection. The module doesn't parse HTML to extract CSRF nonces, doesn't rotate user agents, and makes no attempt to look like legitimate traffic.

The 'finder' tools for directories and admin panels are essentially Python reimplementations of gobuster, reading wordlists and issuing GET requests while checking status codes. Performance is predictably poor—Python's GIL limits true parallelism, and the code uses threading instead of asyncio, meaning you're bottlenecked by synchronous I/O. A comparable Go-based tool like ffuf processes 10-50x more requests per second with the same thread count.

What makes Kraken interesting isn't technical sophistication but the aggregation strategy itself. By bundling Kubernetes API token brute forcing alongside WiFi WPA3 attacks and Office365 credential spraying, the tool reveals which attack surfaces matter to practitioners right now. The inclusion of modern cloud targets (O365, AWS endpoints) suggests active maintenance, while legacy protocols (FTP, Telnet) indicate comprehensiveness for lab environments. It's a barometer for what red teamers actually encounter during engagements, frozen in Python.

Gotcha

Kraken's fundamental limitation is the absence of evasion capabilities. There's no proxy chain support, no request timing randomization, no user-agent rotation, no CAPTCHA solving hooks. The moment you point it at infrastructure protected by Cloudflare, Akamai, or even basic fail2ban rules, you'll be blacklisted before finishing a 500-line wordlist. Modern authentication systems track velocity, connection patterns, and TLS fingerprints—Kraken's naked HTTP requests and rapid-fire SSH attempts scream 'automated attack' to any competent monitoring solution.

The second critical gap is credential intelligence. Successful authentication is binary—you get 'valid' or 'invalid' but no context about account privileges, password expiration policies, or whether MFA is enforced. In enterprise environments, finding a valid credential is just step one; you need to know if it's a domain admin, service account, or locked-down user. Tools like CrackMapExec provide this context for Windows environments, actually enumerating what you can access post-authentication. Kraken dumps credentials and walks away, leaving you to manually validate their utility. For protocols it claims to support but doesn't (SMB and RDP are in the GitHub topics but absent from the actual codebase), you're better off with specialized tools from the start.

Verdict

Use if: You're learning offensive security fundamentals and need a sandbox-friendly tool to understand protocol authentication mechanisms without drowning in command-line flags. Kraken excels in CTF environments, deliberately vulnerable lab networks (HackTheBox, TryHackMe), or testing your own infrastructure where you control the defensive posture and need quick default credential checks across diverse services. It's legitimately useful when you need to validate that hardening worked—if Kraken with rockyou.txt fails, your authentication is probably reasonable. Skip if: You're conducting professional red team engagements or penetration tests against defended infrastructure. The lack of evasion techniques, poor performance compared to Hydra/Medusa, and missing features like credential spraying strategies make this unsuitable for real-world assessments. Choose specialized tools—Hydra for network protocols, wpscan for CMS work, CrackMapExec for Windows environments, and ffuf for web fuzzing. Kraken's convenience doesn't justify the operational risk of noisy, easily-detected attacks that waste engagement hours and alert SOC teams before you've gained meaningful access.