• Thread-based parallel testing. Brute-force testing can be performed against multiple hosts, users or passwords concurrently.
• Flexible user input. Target information (host/user/password) can be specified in a variety of ways. For example, each item can be either a single entry or a file containing multiple entries. Additionally, a combination file format allows the user to refine their target listing.
• Modular design. Each service module exists as an independent .mod file. This means that no modifications are necessary to the core application in order to extend the supported list of services for brute-forcing.

Why?

Why create Medusa? Isn't this the same thing as Hydra? Here are some of the reasons for this application:

• Application stability. Maybe I'm just lame, but Hydra frequently crashed on me. I was no longer confident that Hydra was actually doing what it claimed to be. Rather than fix Hydra, I decided to create my own buggy application which could crash in new and exciting ways.
• Code organization. A while back I added several features to Hydra (parallel host scanning, SMBNT module). Retro-fitting the parallel host code to Hydra was a serious pain. This was mainly due to my coding ignorance, but was probably also due to Hydra not being designed from the ground-up to support this. Medusa was designed from the start to support parallel testing of hosts, users and passwords.
• Speed. Hydra accomplishes its parallel testing by forking off a new process for each host and instance of the service being tested. When testing many hosts/users at once this creates a large amount of overhead as user/password lists must be duplicated for each forked process. Medusa is pthread-based and does not unnecessarily duplicate information.
• Education. I am not an experienced C programmer, nor do I consider myself an expert in multi-threaded programming. Writing this application was a training exercise for me. Hopefully, the results of it will be useful for others.

Technorati Tags: Array Ethical Hacking Tools