# Login Brute Forcing ## Hydra ### Basic Usage Hydra's basic syntax is: Hydra ```bash hydra [login_options] [password_options] [attack_options] [service_options] ``` | Parameter | Explanation | Usage Example | | ----------------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | `-l LOGIN` or `-L FILE` | Login options: Specify either a single username (`-l`) or a file containing a list of usernames (`-L`). | `hydra -l admin ...` or `hydra -L usernames.txt ...` | | `-p PASS` or `-P FILE` | Password options: Provide either a single password (`-p`) or a file containing a list of passwords (`-P`). | `hydra -p password123 ...` or `hydra -P passwords.txt ...` | | `-t TASKS` | Tasks: Define the number of parallel tasks (threads) to run, potentially speeding up the attack. | `hydra -t 4 ...` | | `-f` | Fast mode: Stop the attack after the first successful login is found. | `hydra -f ...` | | `-s PORT` | Port: Specify a non-default port for the target service. | `hydra -s 2222 ...` | | `-v` or `-V` | Verbose output: Display detailed information about the attack's progress, including attempts and results. | `hydra -v ...` or `hydra -V ...` (for even more verbosity) | | `service://server` | Target: Specify the service (e.g., `ssh`, `http`, `ftp`) and the target server's address or hostname. | `hydra ssh://192.168.1.100` | | `/OPT` | Service-specific options: Provide any additional options required by the target service. | `hydra http-get://example.com/login.php -m "POST:user=^USER^&pass=^PASS^"` (for HTTP form-based authentication) | #### Hydra Services Hydra services essentially define the specific protocols or services that Hydra can target. They enable Hydra to interact with different authentication mechanisms used by various systems, applications, and network services. Each module is designed to understand a particular protocol's communication patterns and authentication requirements, allowing Hydra to send appropriate login requests and interpret the responses. Below is a table of commonly used services: | Hydra Service | Service/Protocol | Description | Example Command | | ------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | ftp | File Transfer Protocol (FTP) | Used to brute-force login credentials for FTP services, commonly used to transfer files over a network. | `hydra -l admin -P /path/to/password_list.txt ftp://192.168.1.100` | | ssh | Secure Shell (SSH) | Targets SSH services to brute-force credentials, commonly used for secure remote login to systems. | `hydra -l root -P /path/to/password_list.txt ssh://192.168.1.100` | | http-get/post | HTTP Web Services | Used to brute-force login credentials for HTTP web login forms using either GET or POST requests. | `hydra -l admin -P /path/to/password_list.txt http-post-form "/login.php:user=^USER^&pass=^PASS^:F=incorrect"` | | smtp | Simple Mail Transfer Protocol | Attacks email servers by brute-forcing login credentials for SMTP, commonly used to send emails. | `hydra -l admin -P /path/to/password_list.txt smtp://mail.server.com` | | pop3 | Post Office Protocol (POP3) | Targets email retrieval services to brute-force credentials for POP3 login. | `hydra -l user@example.com -P /path/to/password_list.txt pop3://mail.server.com` | | imap | Internet Message Access Protocol | Used to brute-force credentials for IMAP services, which allow users to access their email remotely. | `hydra -l user@example.com -P /path/to/password_list.txt imap://mail.server.com` | | mysql | MySQL Database | Attempts to brute-force login credentials for MySQL databases. | `hydra -l root -P /path/to/password_list.txt mysql://192.168.1.100` | | mssql | Microsoft SQL Server | Targets Microsoft SQL servers to brute-force database login credentials. | `hydra -l sa -P /path/to/password_list.txt mssql://192.168.1.100` | | vnc | Virtual Network Computing (VNC) | Brute-forces VNC services, used for remote desktop access. | `hydra -P /path/to/password_list.txt vnc://192.168.1.100` | | rdp | Remote Desktop Protocol (RDP) | Targets Microsoft RDP services for remote login brute-forcing. | `hydra -l admin -P /path/to/password_list.txt rdp://192.168.1.100` | ### Brute-Forcing HTTP Authentication Imagine you're tasked with testing the security of a website using basic HTTP authentication at `www.example.com`. You have a list of potential usernames stored in `usernames.txt` and corresponding passwords in `passwords.txt`. To launch a brute-force attack against this HTTP service, use the following Hydra command: Hydra ```bash hydra -L usernames.txt -P passwords.txt www.example.com http-get ``` This command instructs Hydra to: * Use the list of usernames from the `usernames.txt` file. * Use the list of passwords from the `passwords.txt` file. * Target the website `www.example.com`. * Employ the `http-get` module to test the HTTP authentication. ### Targeting Multiple SSH Servers Consider a situation where you have identified several servers that may be vulnerable to SSH brute-force attacks. You compile their IP addresses into a file named `targets.txt` and know that these servers might use the default username "root" and password "toor." To efficiently test all these servers simultaneously, use the following Hydra command: Hydra ```bash hydra -l root -p toor -M targets.txt ssh ``` This command instructs Hydra to: * Use the username "root". * Use the password "toor". * Target all IP addresses listed in the `targets.txt` file. * Employ the `ssh` module for the attack. ### Testing FTP Credentials on a Non-Standard Port Imagine you need to assess the security of an FTP server hosted at `ftp.example.com`, which operates on a non-standard port `2121`. You have lists of potential usernames and passwords stored in `usernames.txt` and `passwords.txt`, respectively. To test these credentials against the FTP service, use the following Hydra command: Hydra ```bash hydra -L usernames.txt -P passwords.txt -s 2121 -V ftp.example.com ftp ``` This command instructs Hydra to: * Use the list of usernames from the `usernames.txt` file. * Use the list of passwords from the `passwords.txt` file. * Target the FTP service on `ftp.example.com` via port `2121`. * Use the `ftp` module and provide verbose output (`-V`) for detailed monitoring. ### Brute-Forcing a Web Login Form Suppose you are tasked with brute-forcing a login form on a web application at `www.example.com`. You know the username is "admin," and the form parameters for the login are `user=^USER^&pass=^PASS^`. To perform this attack, use the following Hydra command: Hydra ```bash hydra -l admin -P passwords.txt www.example.com http-post-form "/login:user=^USER^&pass=^PASS^:S=302" ``` This command instructs Hydra to: * Use the username "admin". * Use the list of passwords from the `passwords.txt` file. * Target the login form at `/login` on `www.example.com`. * Employ the `http-post-form` module with the specified form parameters. * Look for a successful login indicated by the HTTP status code `302`. ### Advanced RDP Brute-Forcing Now, imagine you're testing a Remote Desktop Protocol (RDP) service on a server with IP `192.168.1.100`. You suspect the username is "administrator," and that the password consists of 6 to 8 characters, including lowercase letters, uppercase letters, and numbers. To carry out this precise attack, use the following Hydra command: ```bash hydra -l administrator -x 6:8:abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 192.168.1.100 rdp ``` This command instructs Hydra to: * Use the username "administrator". * Generate and test passwords ranging from 6 to 8 characters, using the specified character set. * Target the RDP service on `192.168.1.100`. * Employ the `rdp` module for the attack. Hydra will generate and test all possible password combinations within the specified parameters, attempting to break into the RDP service. ### Basic Auth with Hydra ```bash hydra -l basic-auth-user -P 2023-200_most_used_passwords.txt 127.0.0.1 http-get / -s 81 ``` Let's break down the command: * `-l basic-auth-user`: This specifies that the username for the login attempt is 'basic-auth-user'. * `-P 2023-200_most_used_passwords.txt`: This indicates that Hydra should use the password list contained in the file '2023-200\_most\_used\_passwords.txt' for its brute-force attack. * `127.0.0.1`: This is the target IP address, in this case, the local machine (localhost). * `http-get /`: This tells Hydra that the target service is an HTTP server and the attack should be performed using HTTP GET requests to the root path ('/'). * `-s 81`: This overrides the default port for the HTTP service and sets it to 81. ### Login Forms ```http POST /login HTTP/1.1 Host: www.example.com Content-Type: application/x-www-form-urlencoded Content-Length: 29 username=john&password=secret123 ``` ```bash hydra [options] target http-post-form "path:params:condition_string" ``` #### Understanding the Condition String In Hydra’s `http-post-form` module, success and failure conditions are crucial for properly identifying valid and invalid login attempts. Hydra primarily relies on failure conditions (`F=...`) to determine when a login attempt has failed, but you can also specify a success condition (`S=...`) to indicate when a login is successful. The failure condition (`F=...`) is used to check for a specific string in the server's response that signals a failed login attempt. This is the most common approach because many websites return an error message (like "Invalid username or password") when the login fails. For example, if a login form returns the message "Invalid credentials" on a failed attempt, you can configure Hydra like this: ```bash hydra ... http-post-form "/login:user=^USER^&pass=^PASS^:F=Invalid credentials" ``` In this case, Hydra will check each response for the string "Invalid credentials." If it finds this phrase, it will mark the login attempt as a failure and move on to the next username/password pair. This approach is commonly used because failure messages are usually easy to identify. owever, sometimes you may not have a clear failure message but instead have a distinct success condition. For instance, if the application redirects the user after a successful login (using HTTP status code `302`), or displays specific content (like "Dashboard" or "Welcome"), you can configure Hydra to look for that success condition using `S=`. Here’s an example where a successful login results in a 302 redirect: ```bash hydra ... http-post-form "/login:user=^USER^&pass=^PASS^:S=302" ``` In this case, Hydra will treat any response that returns an HTTP 302 status code as a successful login. Similarly, if a successful login results in content like "Dashboard" appearing on the page, you can configure Hydra to look for that keyword as a success condition: ```bash hydra ... http-post-form "/login:user=^USER^&pass=^PASS^:S=Dashboard" ``` #### Manual Inspection ```html

Login

``` The HTML reveals a simple login form. Key points for Hydra: * `Method`: `POST` - Hydra will need to send POST requests to the server. * Fields: * `Username`: The input field named `username` will be targeted. * `Password`: The input field named `password` will be targeted. With these details, you can construct the Hydra command to automate the brute-force attack against this login form. #### Constructing the params String for Hydra After analyzing the login form's structure and behavior, it's time to build the `params` string, a critical component of Hydra's `http-post-form` attack module. This string encapsulates the data that will be sent to the server with each login attempt, mimicking a legitimate form submission. The `params` string consists of key-value pairs, similar to how data is encoded in a POST request. Each pair represents a field in the login form, with its corresponding value. * `Form Parameters`: These are the essential fields that hold the username and password. Hydra will dynamically replace placeholders (`^USER^` and `^PASS^`) within these parameters with values from your wordlists. * `Additional Fields`: If the form includes other hidden fields or tokens (e.g., CSRF tokens), they must also be included in the `params` string. These can have static values or dynamic placeholders if their values change with each request. * `Success Condition`: This defines the criteria Hydra will use to identify a successful login. It can be an HTTP status code (like `S=302` for a redirect) or the presence or absence of specific text in the server's response (e.g., `F=Invalid credentials` or `S=Welcome`). Let's apply this to our scenario. We've discovered: * The form submits data to the root path (`/`). * The username field is named `username`. * The password field is named `password`. * An error message "Invalid credentials" is displayed upon failed login. Therefore, our `params` string would be: Code: bash ```bash /:username=^USER^&password=^PASS^:F=Invalid credentials ``` * `"/"`: The path where the form is submitted. * `username=^USER^&password=^PASS^`: The form parameters with placeholders for Hydra. * `F=Invalid credentials`: The failure condition – Hydra will consider a login attempt unsuccessful if it sees this string in the response. Downloading wordlists if needed: ```bash curl -s -O https://raw.githubusercontent.com/danielmiessler/SecLists/master/Usernames/top-usernames-shortlist.txt curl -s -O https://raw.githubusercontent.com/danielmiessler/SecLists/refs/heads/master/Passwords/Common-Credentials/2024-197_most_used_passwords.txt ``` ```bash hydra -L top-usernames-shortlist.txt -P 2023-200_most_used_passwords.txt -f IP -s 5000 http-post-form "/:username=^USER^&password=^PASS^:F=Invalid credentials" ``` ## Medusa *** Medusa, a prominent tool in the cybersecurity arsenal, is designed to be a fast, massively parallel, and modular login brute-forcer. Its primary objective is to support a wide array of services that allow remote authentication, enabling penetration testers and security professionals to assess the resilience of login systems against brute-force attacks. ### Installation Medusa often comes pre-installed on popular penetration testing distributions. You can verify its presence by running: Medusa ```bash medusa -h ``` Installing Medusa on a Linux system is straightforward. Medusa ```bash sudo apt-get -y update sudo apt-get -y install medusa ``` ### Command Syntax and Parameter Table Medusa's command-line interface is straightforward. It allows users to specify hosts, users, passwords, and modules with various options to fine-tune the attack process. Medusa ```bash medusa [target_options] [credential_options] -M module [module_options] ``` | Parameter | Explanation | Usage Example | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `-h HOST` or `-H FILE` | Target options: Specify either a single target hostname or IP address (`-h`) or a file containing a list of targets (`-H`). | `medusa -h 192.168.1.10 ...` or `medusa -H targets.txt ...` | | `-u USERNAME` or `-U FILE` | Username options: Provide either a single username (`-u`) or a file containing a list of usernames (`-U`). | `medusa -u admin ...` or `medusa -U usernames.txt ...` | | `-p PASSWORD` or `-P FILE` | Password options: Specify either a single password (`-p`) or a file containing a list of passwords (`-P`). | `medusa -p password123 ...` or `medusa -P passwords.txt ...` | | `-M MODULE` | Module: Define the specific module to use for the attack (e.g., `ssh`, `ftp`, `http`). | `medusa -M ssh ...` | | `-m "MODULE_OPTION"` | Module options: Provide additional parameters required by the chosen module, enclosed in quotes. | `medusa -M http -m "POST /login.php HTTP/1.1\r\nContent-Length: 30\r\nContent-Type: application/x-www-form-urlencoded\r\n\r\nusername=^USER^&password=^PASS^" ...` | | `-t TASKS` | Tasks: Define the number of parallel login attempts to run, potentially speeding up the attack. | `medusa -t 4 ...` | | `-f` or `-F` | Fast mode: Stop the attack after the first successful login is found, either on the current host (`-f`) or any host (`-F`). | `medusa -f ...` or `medusa -F ...` | | `-n PORT` | Port: Specify a non-default port for the target service. | `medusa -n 2222 ...` | | `-v LEVEL` | Verbose output: Display detailed information about the attack's progress. The higher the `LEVEL` (up to 6), the more verbose the output. | `medusa -v 4 ...` | #### Medusa Modules Each module in Medusa is tailored to interact with specific authentication mechanisms, allowing it to send the appropriate requests and interpret responses for successful attacks. Below is a table of commonly used modules: | Medusa Module | Service/Protocol | Description | Usage Example | | ---------------- | -------------------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | FTP | File Transfer Protocol | Brute-forcing FTP login credentials, used for file transfers over a network. | `medusa -M ftp -h 192.168.1.100 -u admin -P passwords.txt` | | HTTP | Hypertext Transfer Protocol | Brute-forcing login forms on web applications over HTTP (GET/POST). | `medusa -M http -h www.example.com -U users.txt -P passwords.txt -m DIR:/login.php -m FORM:username=^USER^&password=^PASS^` | | IMAP | Internet Message Access Protocol | Brute-forcing IMAP logins, often used to access email servers. | `medusa -M imap -h mail.example.com -U users.txt -P passwords.txt` | | MySQL | MySQL Database | Brute-forcing MySQL database credentials, commonly used for web applications and databases. | `medusa -M mysql -h 192.168.1.100 -u root -P passwords.txt` | | POP3 | Post Office Protocol 3 | Brute-forcing POP3 logins, typically used to retrieve emails from a mail server. | `medusa -M pop3 -h mail.example.com -U users.txt -P passwords.txt` | | RDP | Remote Desktop Protocol | Brute-forcing RDP logins, commonly used for remote desktop access to Windows systems. | `medusa -M rdp -h 192.168.1.100 -u admin -P passwords.txt` | | SSHv2 | Secure Shell (SSH) | Brute-forcing SSH logins, commonly used for secure remote access. | `medusa -M ssh -h 192.168.1.100 -u root -P passwords.txt` | | Subversion (SVN) | Version Control System | Brute-forcing Subversion (SVN) repositories for version control. | `medusa -M svn -h 192.168.1.100 -u admin -P passwords.txt` | | Telnet | Telnet Protocol | Brute-forcing Telnet services for remote command execution on older systems. | `medusa -M telnet -h 192.168.1.100 -u admin -P passwords.txt` | | VNC | Virtual Network Computing | Brute-forcing VNC login credentials for remote desktop access. | `medusa -M vnc -h 192.168.1.100 -P passwords.txt` | | Web Form | Brute-forcing Web Login Forms | Brute-forcing login forms on websites using HTTP POST requests. | `medusa -M web-form -h www.example.com -U users.txt -P passwords.txt -m FORM:"username=^USER^&password=^PASS^:F=Invalid"` | ### Targeting an SSH Server ```bash medusa -h 192.168.0.100 -U usernames.txt -P passwords.txt -M ssh ``` ### Targeting Multiple Web Servers with Basic HTTP Authentication ```bash medusa -H web_servers.txt -U usernames.txt -P passwords.txt -M http -m GET ``` ### Testing for Empty or Default Passwords ```bash medusa -h 10.0.0.5 -U usernames.txt -e ns -M service_name ``` This command instructs Medusa to: * Target the host at `10.0.0.5`. * Use the usernames from `usernames.txt`. * Perform additional checks for empty passwords (`-e n`) and passwords matching the username (`-e s`). * Use the appropriate service module (replace `service_name` with the correct module name). ## Custom Wordlists ### Username Anarchy #### **Installation** ```bash sudo apt install ruby -y git clone https://github.com/urbanadventurer/username-anarchy.git cd username-anarchy ``` #### Usage ```bash ./username-anarchy Jane Smith > jane_smith_usernames.txt ``` ### CUPP (Common User Passwords Profiler) The efficacy of CUPP hinges on the quality and depth of the information you feed it. It's akin to a detective piecing together a suspect's profile - the more clues you have, the clearer the picture becomes. So, where can one gather this valuable intelligence for a target like Jane Smith? * `Social Media`: A goldmine of personal details: birthdays, pet names, favorite quotes, travel destinations, significant others, and more. Platforms like Facebook, Twitter, Instagram, and LinkedIn can reveal much information. * `Company Websites`: Jane's current or past employers' websites might list her name, position, and even her professional bio, offering insights into her work life. * `Public Records`: Depending on jurisdiction and privacy laws, public records might divulge details about Jane's address, family members, property ownership, or even past legal entanglements. * `News Articles and Blogs`: Has Jane been featured in any news articles or blog posts? These could shed light on her interests, achievements, or affiliations. OSINT will be a goldmine of information for CUPP. Provide as much information as possible; CUPP's effectiveness hinges on the depth of your intelligence. For example, let's say you have put together this profile based on Jane Smith's Facebook postings.
FieldDetails
NameJane Smith
NicknameJaney
BirthdateDecember 11, 1990
Relationship StatusIn a relationship with Jim
Partner's NameJim (Nickname: Jimbo)
Partner's BirthdateDecember 12, 1990
PetSpot
CompanyAHI
InterestsHackers, Pizza, Golf, Horses
Favorite ColorsBlue
CUPP will then take your inputs and create a comprehensive list of potential passwords: * Original and Capitalized: `jane`, `Jane` * Reversed Strings: `enaj`, `enaJ` * Birthdate Variations: `jane1994`, `smith2708` * Concatenations: `janesmith`, `smithjane` * Appending Special Characters: `jane!`, `smith@` * Appending Numbers: `jane123`, `smith2024` * Leetspeak Substitutions: `j4n3`, `5m1th` * Combined Mutations: `Jane1994!`, `smith2708@` #### Installation ```bash sudo apt install cupp -y ``` #### Usage (interactive mode) ```bash cupp -i ``` #### Adapt/Filter for Password policy Example: * Minimum Length: 6 characters * Must Include: * At least one uppercase letter * At least one lowercase letter * At least one number * At least two special characters (from the set `!@#$%^&*`) ```bash grep -E '^.{6,}$' jane.txt | grep -E '[A-Z]' | grep -E '[a-z]' | grep -E '[0-9]' | grep -E '([!@#$%^&*].*){2,}' > jane-filtered.txt ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.rtlcopymemory.com/login-brute-forcing.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.