RSS Feed

Entries in Network (4)


Slaying Rogue Access Points with Python and Cheap Hardware

The Need for Open Source Rogue AP Protection

With the exception of cellular attacks that make use of SDR, rogue access point attacks are the most effective wireless attacks in practice today. Despite the fact that karma attacks have existed for nearly a decade, many devices still probe actively for their preferred networks, rendering them vulnerable to this form of exploitation [1]. Evil Twin attacks remain an issue for enterprise and smaller scale commercial networks alike.

Although effective solutions for detecting and responding to rogue access point attacks exist, they typically fall into a price bracket that is accessible only to enterprise customers [2][3][4]. This means that smaller scale commercial and retail networks, or even public sector networks operating with limited resources, are unlikely to be able to include rogue access point detection as part of their budgets. This lack of low-budget rogue AP protection has a severe impact on the security of the wireless landscape as a whole. Although attackers can and do use rogue access point attacks against enterprise networks, this is usually done with the intent of gaining credentials to pivot further into the target’s infrastructure. On the other hand, attackers who are focused on harvesting sensitive information such as credit card numbers are unlikely to target heavily secured and regularly audited enterprise networks. Instead, they are much more likely to employ evil twin attacks against softer targets such as local retailers and coffee shops, or make use of karma attacks in a crowded subway car or freeway. What this means is that the environments most likely to be targeted by a malicious actor are also the least protected.

In response to this problem, I developed an open source tool called sentrygun that can be run on inexpensive hardware in parallel with existing network setups. This blog post will cover the development of sentrygun, from the algorithms used to detect rogue APs to the design patterns used to leverage those algorithms by network administrators. Finally, it will document the successes and challenges faced when deploying sentrygun to protect one of the most hostile network environments in the world: BSides Las Vegas.

Building a Rogue AP Protection Platform Pt 1 – Algorithm Development

The first task in creating sentrygun was to develop a set of reliable, effective, and easily implemented algorithms for detecting evil twin and karma attacks. A lot of prior work has already been done in this area, which gave me a pretty big head start. Unfortunately, most of the more advanced methods of detecting rogue access point attacks require direct coordination with the wireless networking hardware [5]. Most networking hardware is highly proprietary, making this kind of cooperation next to impossible.

This means that the algorithms used by sentrygun would have to operate in complete independence from the network being protected. Three algorithms were identified that met this requirement: evil twin detection using whitelisting, evil twin detection through statistical analysis of signal strength, and karma detection through analysis of probe request/response patterns.

Detecting evil twin attacks using whitelisting is a classic approach outlined in multiple sources, most notably in a 2006 SANS publication by Larry Pesce [6]. In this strategy, a whitelist is created containing the ESSID and BSSID of every wireless access point on the network being protected. A packet sniffer then captures probe response packets from nearby access points. If a probe response is captured that has an ESSID from the whitelist, but a BSSID not in the whitelist, it follows that there is an evil twin attack occurring nearby.

whitelist based algorithm for detecting evil twins

The problem with this approach is that it does not account for scenarios in which the attacker sets the BSSID of the rogue access point to a BSSID used by a legitimate access point on the network. One way of addressing this issue is by adopting a different strategy entirely: attempt to identify evil twin attacks by paying attention to signal strength. Suppose we were to place a packet sniffer a fixed distance away from a legitimate access point on our network. Wireless access points are typically stationary objects, so the signal strength from the access point to the packet sniffer should not change drastically over a short period of time. Now suppose an attacker spawned an evil twin access point somewhere nearby. Packets sniffed from the evil twin should have noticeably different TX values than packets sniffed from the legitimate access point.

This means that we can augment our previous approach by establishing a baseline TX range for packets sent from each BSSID in the whitelist. Any packets received that appear to come from an access point in the whitelist, but that have a TX value that falls outside of the baseline range for that access point, are deemed to have been sent by an evil twin. This combined approach of whitelisting and signal strength analysis provides a  more effective solution to evil twin detection.


whitelist algorithm augmented with signal strength analysis

Spotting karma attacks turns out to be much simpler. Karma attacks work by configuring a rogue access point to respond to all probe requests it receives [7]. If the rogue access point receives a legitimate probe request for the ESSID “ms08067”, it will respond with a probe response for ESSID “ms08067”. Similarly, if it receives a probe request for the ESSID “\x90\x90\x90”, it will reply with a probe response for ESSID “\x90\x90\x90”. The rogue access point will send all of these responses using the same BSSID [1]. Since the targeted wireless clients need a consistent BSSID in order to remain connected to the rogue access point, cycling BSSIDs between probe responses is not an option.


algorithm to detect karma attacks

This means that karma attacks can always be identified by the one-to-many relationship that they create between a single BSSID that maps to multiple ESSIDs. Karma attacks can be detected by flagging any BSSID that sends probe responses for multiple ESSIDs. This algorithm can be further improved by periodically crafting and broadcasting probe requests for random ESSIDs using a parallel process. Doing so allows the algorithm to detect karma attacks even when no wireless clients are actively probing nearby.

Sentrygun uses all three of the algorithms described to detect evil twin and karma attacks. Additional methods for detecting evil twin and karma attacks are currently being implemented, along with improvements to the algorithms already in use.

Building a Rogue AP Protection Platform Pt 2 – System Development

Using the algorithms described in the previous section to build a functional wireless IDS system poses its own set of challenges. Such a system would have to be capable of protecting a wireless network of arbitrary size, and would have to scale with future expansions of the network. It would also have to give sole network operators a means of tracking and managing attacks across the entire network from a centralized location. The system would have to require minimal setup and fine tuning in order to work. Most importantly, the system would have to meet these requirements while still providing a reliable means of identifying, locating, and responding to wireless attacks.

Figure 1

To meet these requirements, sentrygun was developed as an array of sensors arranged in a grid connected to a centralized command and control server through ssh tunnels (figure 1). All sensor and server systems are security hardened Linux installations. Each sensor runs a packet sniffing Python script that analyzes wireless traffic using the algorithms described in the previous section. When a sensor detects a rogue access point attack, an alert is pushed to the C&C server. The C&C server stores the alert details in a time based cache, then broadcasts the alert to one or more web clients. Each web client displays a list of all alerts that have recently been sent by the sensors.

Figure 2

As shown in figure 2, alerts can be expanded to show a list of all devices currently detecting the wireless attack. Network administrators can respond by launching a flooding or deauth attack that is carried out by all sensor devices simultaneously. Additionally, network administrators can attempt to locate the rogue access point by sending security personnel to the sensor detecting the highest TX power from the attack. Sensor devices are sorted by TX and can be labeled to facilitate this functionality, as shown in figure 2. Finally, network administrators can choose to dismiss the alert. Doing so causes the C&C server to remove the alert from the time based cache and broadcast a message to all web and sensor clients. This message causes all web clients to remove the alert from the list, and causes all sensors to terminate any existing deauth or flooding attacks against the rogue access point.

This architecture provides sentrygun with the means to detect, respond to, and locate rogue access point attacks in real-time. Additionally, since the most resource intensive work is done on the C&C server, the sensor units can be built using inexpensive platforms such as the Raspberry Pi. Finally, the web interface provides an intuitive cross platform interface for controlling sentrygun and analyzing wireless attack data.

Field Test: BSides Las Vegas

Ensuring that sentrygun was able to function effectively outside of the lab environment could only be accomplished through intense field testing. Fortunately, the BSides Las Vegas NOC team generously provided me with a live environment in which to conduct such a test. Simply put: they put me in charge of wireless security for the conference. This meant that I was tasked with ensuring the integrity of attendees’ data during a week in which Vegas is home to some of the most notoriously hostile networks in the world. It seemed like an excellent opportunity to test  sentrygun.

I arrived in Las Vegas on Saturday afternoon, July 30th, three days before the start of the BSides conference. After meeting up with the rest of the BSides staff, we spent the evening unpacking boxes and making an emergency run to the local electronics depot to purchase supplies for the network. The NOC team was scheduled to build the conference network on Monday, which gave me all of Sunday to assemble and test each of the sensor units used in the sentrygun implementation. Due to the number of sensors needed to cover the conference floorspace, doing this in such a short timeframe seemed daunting.

Tuscany Suites Sweatshop. BSides Goons from left to right: Chester Bishop, Ben, and Justin Whitehead                 

These look totally harmless

Fortunately, a few of the awesome folks on the BSides security team came to the rescue to help me set up the sensors. We converted a hotel room into an electronics workshop, sat down with a couple of cases of Red Bull, and finished building the sentrygun sensor units within a few hours.

At the BSides NOC, we take cable management seriously

On Monday morning I joined the NOC team in setting up the BSides network itself. This involved running a few thousand feet of Cat5 cable, as well as configuring three wireless networks across multiple channels. Once the network was set up, the sentrygun sensors were laid out in a grid across the conference floor using copious amounts of gaff tape and Velcro.

Don’t mind the things on the walls….


On Tuesday morning, the conference opened its doors and the network was put to use. Within half an hour, a panicked attendee had already summoned security after purportedly finding a rogue access point taped to the wall. The “rogue access point” turned out to be one of our sentrygun sensor units, much to the amusement of the BSides staff. We had no similar incidents throughout the rest of the day.

No wireless threats were detected until the early evening, at which point the 802.11 spectrum seemed to come alive with hostility. At around 5pm, sentrygun detected a karma attack emanating from one of the far corners of the main conference space. Security was dispatched to investigate, and after noticeably increasing the physical security presence in the area the attack stopped. By the end of the conference on Tuesday night, several similar attacks were identified and dealt with accordingly.

The field test demonstrated that sentrygun is capable of identifying wireless threats in a live network environment. It also led to several important findings that will prove critical in sentrygun’s transition from a proof of concept to a mature wireless defense platform. One such finding is that within the context of a crowded conference venue, narrowing the location of a rogue access point down to a few meters is not always enough. There were multiple incidents in which an evil twin or Karma attack was detected and localized to an area containing at least two dozen people with backpacks or laptops. In these circumstances, noticeably increasing security presence was usually enough to stop the attack. However, the ability to consistently identify the exact source or perpetrator of the attack would be preferable.

Closing Thoughts

Overall, the sentrygun project has been a success. It has demonstrated that it is possible to provide rogue access point detection using relatively simple algorithms and inexpensive equipment. It has demonstrated that such a system can be designed and built over the course of a few weeks. It has also lead to the development or verification of three algorithms used for detecting evil twin and karma attacks. Most importantly, it has opened the doors for future research in rogue AP identification and mitigation.

There are aspects of sentrygun’s design that require further development. While sentrygun’s algorithm for detecting evil twins based on variance in TX values makes for an effective proof of concept, stronger statistical models that account for externalities such as environmental interference would be preferable. Similarly, it would be interesting to investigate the use of machine learning to distinguish between rogue and legitimate access points. Finally, a more effective technique for locating rogue access points is needed if the system is to be equally effective in highly populated environments.

Sentrygun is an open source project. If you’d like to contribute, particularly in the areas previously mentioned, please contact [email protected] or make a pull request to the appropriate Github repo from the list below: 

Additionally, be sure to check out my DEFCON talk on rogue access point detection. The PowerPoint slides are can be found here, and video footage should be on YouTube within the next few weeks.




HTTP NTLM Information Disclosure

Remote enumeration of host/service details is a core activity of any penetration test. In support of such activities, we’ve released a new Nmap script that anonymously enumerates remote NetBIOS, DNS, and OS details from HTTP services with NTLM authentication enabled.

NTLM authentication is supported over HTTP, and is often used to protect application content and resources from unauthorized access. As part of the HTTP NTLM authentication process, a series of challenge-response messages are exchanged. By analyzing the encoded NTLMSSP information contained within specific messages, potentially sensitive information can be enumerated from remote hosts.

Host information can be enumerated using NTLM over HTTP in a manner similar to NTLM authentication over SMB, in which remote host information can be enumerated by sending anonymous credentials. By sending a NTLM authentication request with null domain and user credentials (passed in the ‘Authorization’ header), the remote web server will respond with a NTLMSSP message (encoded within the ‘WWW-Authenticate’ header) and disclose information including NetBIOS, DNS, and OS build version.

While this is not an active exploit, it’s extremely useful for network reconnaissance: the information disclosed may be used as part of more complex attacks, such as leveraging domain information for brute forcing accounts, identifying internal hostnames during external to internal pivoting activities, or determining end-of-life operating systems.

Lets see how this works using the script we’ve written for Nmap:

#nmap -p443 —-script http-ntlm-info

Nmap scan report for
Host is up (0.040s latency).
443/tcp open https
| http-ntlm-info:
|  Target_Name: ACTIVEWEB
|  NetBIOS_Domain_Name: ACTIVEWEB
|  NetBIOS_Computer_Name: PRODWEB001
|  DNS_Domain_Name:
|  DNS_Computer_Name:
|  DNS_Tree_Name:
|_ Product_Version: 5.2 (Build 3790)

Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Since this script is considered default/safe, it will also run automatically when the ‘-sC’ or ‘-A’ flags are utilized.

During penetration testing such configurations are often encountered, and unfortunately are often passed over by many due to a lack of understanding the protocol and the type of information that can be anonymously enumerated. So how common are such web server configurations? Utilizing Shodan, below quantifies the number of internet facing web servers supporting NTLM authentication over HTTP and HTTPS:

Web Server Type HTTP HTTPS
Microsoft-IIS/5.0 (Windows 2000 Server) 4,342 1,067
Microsoft-IIS/5.1 (Windows XP) 1,945 151
Microsoft-IIS/6.0 (Windows Server 2003) 70,784 42,768
Microsoft-IIS/7.0 (Windows Server 2008) 13,790 8,241
Microsoft-IIS/7.5 (Windows Server 2008 R2) 47,235 34,493
Microsoft-IIS/8.0 (Windows Server 2012) 6,934 2,591
Microsoft-IIS/8.5 (Windows Server 2012 R2) 883 533
Microsoft Other (e.g. WinCE, etc.) 1,352 28
Unknown & Open Source Implementations 3,438 2,111
Total 150,703 91,983

*Note, does not account for hosts with both anonyous and NTLM authentication enabled

Currently, outside of disabling NTLM authentication over HTTP, there is no method to mitigate leaking such information under Microsoft IIS — all versions are affected by design.

This script, ‘http-ntlm-info’, has been tested against all current/past Microsoft IIS versions and open source HTTP NTLM implementations. It can be obtained here or via the current Nmap Subversion repository (r32706 or higher).

Note: If adding the script manually, the ‘nmap —script-updatedb’ command will need to be issued (as root/admin) to update the local script database.


When Domain Admin Is Not Enough

When conducting a network pentest we often find the goal of the tester, at least on a Windows domain network test, is to get Domain Admin. That is well and good, but for impact nothing beats capturing the CIOs desktop, documents or e-mail. So how do we get there?

When we are testing networks we often talk about network mapping and recon.  Its almost described as a matter of course in most books on network hacking. Sadly, often a tester will run Nmap and not even wait for the results before kicking off a scanner or running an exploit.

In actual fact, network reconnaissance can be the most important part of an assessment, and Nmap isn’t always the best or most appropriate tool for this particular job. Never underestimate the use and value of tools such as Wireshark, traceroute, ping and tcptraceroute in mapping a network.

When pentesting a Windows network, we’re probably going to be running Nmap near the start of the engagement, however at this point we are unlikely to be authenticated to the domain. We need to remember to come back to this as soon as we have managed to gain access to our first domain account - the first toehold.

The Kung Fu Toehold

Getting that first toehold can be tricky, but there are a number of ways:

  1. Sniffing (ARP poisoning or even just listening to broadcasts)
  2. SMB traffic redirection
  3. Exploit a single unpatched host

With SMB redirection we can capture hashes and crack them, but that is CPU intensive and often there are easier ways.  However sometimes the simple ways are still the best - printers can be very helpful. With only read access to printer queues, we have a goldmine of usernames. 

Dont Lock Out The Domain

Next we can kick-off a brute force attack - but lets be smart about this. Most Windows networks have account lockout policies in place. This could result in a tester doing a Denial of Service on the network if they’re not careful. Try explaining to a systems admin why you’ve locked out all of the users in the middle of the day - not something you ever want to have to do. So we need to think around the problem and proceed carefully.

On a recent test we managed to gather 20 usernames, and the lockout policy would have locked us out after 5 failed logins. So we carefully chose 3 passwords and tried them on all the accounts.  This resulted in 4 compromised accounts.  In this situation the password policy strength was set to complex passwords,  but human nature being what it is “Password1” worked for more than 1 account - make sure you think like a normal person, not a security tester. If we know a company has a strong password policy (for example, 6 characters, 1 special, upper and lower), try and come up with the easiest options that match this. “Pa55word!” would work, or even better use permute.exe and give it the company name. 

From Humble Beginnings

Now that we have one or two user accounts we can get all the usernames from the domain, we can fully identify what the password policy is, and we can find out who the domain administrators are.  Tools such as and Nmap are fantastic when we want to enumerate users from domain controllers.   We could then just repeat this process and brute force out passwords hoping to get lucky - perhaps  a domain administrator has got the password of “Passw0rd1”  but its unlikely.  If we use the information we have gathered to identify interesting targets this would more likely result in access to the real goal - data.  Also remember with domain access you can potentially view corporate Intranet pages, or sometimes we can see this without a username and password.  If we don’t already have it from external recon, we are likely to find data on the CIO (their name at very least), and perhaps members of the Board. Remember that organisational charts are often a boon in this case.  At this point, hopefully, we now know who we are targeting and can make a decent guess at the  format of the username.

Stay On Target

So now we have our target accounts, what next?  We could use the company Intranet site again;  perhaps finding XSS and using tools like “Shell of the Future” or “BeEF”  to poison requests from the users that we particularly want when we see them come in.  We could even redirect those requests to Metasploit http-ntlmrelay and target specific boxes. This may succeed, however, it could be less surgical than we require. Enter Nmap again.

With Nmap’s SMB scripts and an authenticated user acount we can get the name of a user that is logged in and the IP address of their host machine when scanning the domain controller.  This gives us our target host - the CIOs laptop/desktop.  Once again we may get lucky - this box may not have  been patched. However it is likely that it will be, CIOs are important  and tech support like to make sure that they’re safe.  What next? We could send a malicious document via email. This may hit antivirus, or they may not open it. What we need is hosts that the CIO has sent their password to.

Say we breach a mail server, Citrix server, or even an Intranet web server - we are likely to get something very useful, user passwords. Lost of users will login to these hosts.  We can start off by pulling out the hashes from these machines and passing them across the network.  It is likely that more systems can be compromised this way, however there is a cleaner way. If we want the CIOs desktop we really also want the password in our hand,  so we can turn to WCE.exe, mimikatz or procdump

Windows Credentials Editor, mimikatz and procdump are awesome pieces of software.  They will pull decrypted passwords out of memory (in the case of procdump just the memory). No nasty cracking,  rainbow tables or hash passing.  We just need admin access on the host that our target is logged into, and to disable the antivirus (we’ve found pulling passwords out of memory can trigger some modern antivirus solutions).  This could be a mail server,  Citrix server or perhaps even a desktop.  We dump the passwords and were done.  So we now have the CIOs credentials, but there’s one more thing to think of.

One Desktop To Rule Them All

The next activity is so simple it took me a while to realise how powerful it was.  Presuming we have admin access to a machine on the domain (the CIOs desktop), we can RDP into that host as a privileged user, use “Run As”  with the password or token (via incognito) of the CIO to get a shell, and kill that user’s instance of Explorer.  Then run Explorer from the shell that you have just started.  Your desktop will restart as the CIO  user. We can now easily startup tools like Outlook and have Windows do all the hard work for us.  We can also use this technique when targeting developers.  Using Windows authentication tokens extracted by Metasploit to do the same thing and start up SQL Server Management Studio and (if the SQL Servers are using domain authentication) connect directly to development SQL Servers.  Often the passwords used on those machines can potentially give you access to production hosts.  So just remember Domain Administrator is good, but it isn’t always the most interesting user on the network.


Nmap (smb scripts)
Nmap (ldap scripts)
Metasploit (smb_relay)
Metasploit (http_ntlmrelay)


Network Testing 101: If Your Name's Not Down, You're Not Getting In

Looking at the basics of network testing, user enumeration is critical. If we can get usernames, access is only a hop skip and a jump away. Well, perhaps only a decent dictionary brute-force away.

The thing is how do we get these usernames? A few basic network pentesting tricks are listed here. Also, as a lot of user names are predictable combinations (such as a combination of first and last names, and initials) it can be fun to find amusing user names on a network.

Simple User Name Enumeration

Time to start with some of the simple stuff, SNMP (Simple Network Management Protocol). Some interesting MIBs (Management Information Base) that result in user enumeration are:



*nix in general



  • Windows    USERS
  • Windows    SHARES

The MIBs listed above give away usernames. Some are obvious. The ones that are less obvious are RUNNING SOFTWARE PATHS and (in Windows) INSTALLED SOFTWARE these may disclose information in the path names as shown below:

. = STRING: “/usr/bin/login”
. = STRING: “/bin/bash”
. = STRING: “/home/auser/tail”

As we can see, the user name auser is disclosed if the full path of the running binary is used. Remember this works only if the user has used the full path to run the process.

The snmpwalk tool is a good place to start for enumerating SNMP data out of a host. There is also the small matter of the community string you’ll also need, however in many cases you can go with the defaults and get information back. Changing these from the default is often overlooked when SNMP is enabled on servers.

Print My User Name

Web and telnet interfaces on printers are often unauthenticated, unencrypted or use default or weak passwords. It is often possible to connect to these repositories of information leakage and grab document names, share locations, and most importantly user names.

As a lot of printers have no lockout controls, even if admin account passwords have been changed you can often brute force passwords on these safely. If we can gain admin access to the printer, there may be other interesting options available as well. In one case, we came across an option to fax a copy of every document printed to a number of our choice. 

Old Problems Never Die

Username enumeration on a Windows domain can be easy or a pain. On a box that accepts null connections we win. We can get the users and also the password policy, shares etc, and tools like enum and enum4linux still have a valuable place in the tool kit. But in a modern Windows AD domain don’t forget the use of LDAP. If it is possible to use null binds via LDAP, tools like, ldp.exe and nmap (—script ldap-search) are a good starting point to give you that user list. However, if you don’t have null shares or anonymous bind then you may need to make authenticated connections to the domain to get the same data. This means that one bad password on the network is a foothold to accessing the rest of the domain.

Research, Research, Research

In a lot of Exchange environments the user’s email address will contain their username. Robert Smith, for example, is [email protected] - it’s likely that “rsmith” is his login. But do remember that with common names this may not be the case.  A lot of this kind of data can be gathered from company web pages or Intranet sites…. or even bouncing a couple of emails into the organisation can work for this. If the company has an internal anonymously accessible wiki this can be a nice resource as well.

Listen, Did You Smell That?

Sniffing network traffic can also help out with delivering those user names. You may even get those passwords you’re looking for - never discount the amount of clear text protocols that are still in use. Also many companies will use TLS/SSL on their public web sites, but not encrypt internally.

I Never Metadata I Didn’t Like

In Office documents the metadata will contain, amongst other things, the name of the user who created that document. If we know the schema, this can give you the username. Also if the company writes Silverlight or .NET applications, then decompilation can give you pathnames, again with valid usernames.

Now Pay Attention 007

There is a reason to wear headphones with no music playing. If you are sitting onsite amongst IT Staff or developers you may hear the phrase: “What user should I log on as?” around you. If you are lucky they may even shout out passwords. Also there is the old tried and true method of just asking. Some call it social engineering but that’s a topic for another post. 

Sharing Your Toys

So you find a file share. Now there are lots of awesome things you can do: SMB relay attacks, trojan documents, DLL injection (if some one is dumb enough to share the wrong thing). But one of the other things you can do when a domain user visits the share is have a file there that points back to us. This could be an image in the document, a second embedded document in our Excel sheet (that we host), or a malicious shortcut file with an icon on our machine. When they access this, a bit of metasploit SMB sniffing and we can get the username as well as NTHASH and (if they are using it) the LMHASH. 

Guess Who - Are You “bin”?

On smtp, ftp, and ssh there have been ways to brute force out usernames. This is ok, but is really dependant on the list of usernames you start with. In the spirit of recycling, never throw anything away - every time you gather a name, put it in a file. Next time you have a chance to brute-force out names on an SMTP server via RCPT EXPN and VRFY you will have a good starting point.

Go Wide!

So you’ve got your big list of users? Now we take a big dictionary and hit go! - lock out the accounts and get asked to leave OR perhaps there is a better way? Time to chose a common password and wide-band it across all the accounts. A usual rule is to assume they lock the accounts after 3 failed attempts. So we could choose 2 candidate passwords and try those. If you haven’t found anything at all about the password policy before this stage, now would be a good time to do it. When we know what we can risk, we can make the call and do some brute forcing.  For me, Medusa is my brute forcer of choice. A nice feature is that Medusa that will let you look for “Joe Logins” as well as blank passwords. The nice thing about this one is the tool is modular and supports a large list of protocols. So now from a big list of users we send out 2 passwords per user per hour/day/week. Eventually we get a hit. Next we can use this authenticated access to get more user names and start the brute force loop again. Voila!