Transversal password cracking with NMAP (without downloading the hashes)

Posted on February 2, 2013

A few months back I discovered that our service desk had become a little “lazy” and were no longer using the defined process (identify user, randomly generate new password, set to change on first use) and were now handing out weak passwords without requiring the users to change them.

In order to assess the extent of the problem I wanted to do a test against the domain to see how wide-spread the problem was. I Google’d around a bit to try to identify a tool which could perform the exercise for me, but didn’t really find anything that looked suitable. I knew that I didn’t want to grab the hashes and do an off-line attack , but wanted instead to do it “live” against the domain, both to avoid the responsibility of having a copy of all the hashes (risk of is too high and as Head of Infosec I didn’t want that on my head)  and also to test the alertness of the security operations centre in detecting the attack.

My criterion was simple, find a tool that given a file of usernames and a file of passwords would test the usernames with the given passwords.

The closest thing I could find to what I was looking for was an NMAP script written by Patrik Karlsson ( that would make use of the LDAP service of Active Directory. The documentation on the script was found here : This script :

” Attempts to brute-force LDAP authentication. By default it uses the built-in username and password lists. In order to use your own lists use the userdb and passdb script arguments.

This script does not make any attempt to prevent account lockout! If the number of passwords in the dictionary exceed the amount of allowed tries, accounts will be locked out. This usually happens very quickly. “

This description made me a little nervous. I certainly didn’t want to accidentally pass the wrong parameters and have it execute a brute force against the entire domain, performing my own denial of service attack. To avoid this I placed my own account name in the users.txt file, put a few random passwords in pass.txt followed by my own password and experimented with the NMAP arguments until I had it working. The end result was the command below :

nmap -p 389 -v -v --script ldap-brute --script-args "userdb=users.txt,passdb=pass.txt,ldap.savetype=verbose"
  • replace the  with the address of your domain controller
  • users.txt contains the usernames in format : (Get them in this format using the Active Directory Tools / Active Directory Users and Computers tool, export the User Logon Name field)
  • pass.txt contains the passwords, one per line, not too many to avoid locking accounts (I used 7 – use a number a few less than your lockout threshold as you don’t want to lock your users out! )
  • results are saved to a file
Make sure you test your setup first using just one or two accounts to avoid locking out the whole domain!
In my exercise I had around 28 000 accounts that I wanted to check for commonly used passwords. Knowing that our password lockout occurs after 10 incorrect attempts I chose to use seven passwords in the list, and executed the exercise on a weekend.
I found that NMAP could not cope with this volume of accounts (the 28 000), so I had to split the accounts into batches of around 2500 (reached through a bit of trial and error). Each batch took a little under 4 minutes to run, though I guess this will vary based on your network conditions and the load on your domain controller. Since the output filename was automatically generated I needed to rename it after each batch and then combine the final files.
The ldap-brute script provides some interesting results, giving you more than just whether the account was successfully cracked or not. For each account cracked, the script outputs a single line into the text file in the format :
I simply took these results, imported into Excel, did a Text to Columns conversion (delimited with “:” as separator) and then was able to create a pivot table to provide some useful analysis of the results.
The categories of Comment I obtained from my sample included :
  • Valid credentials
  • Valid credentials, account disabled
  • Valid credentials, account expired
  • Valid credentials, account locked
  • Valid credentials, password must be changed at next logon
My testing provided some interesting results. The selection of 7 passwords (chosen because they were commonly used by the service desk) successfully authenticated numerous accounts (5.65% of the sample), and this despite the fact that Active Directory “strong” passwords are enforced.
The split based on the categories above was :
  • 65.8% Valid credentials
  • 2.9% Valid credentials, account disabled
  • 1.4% Valid credentials, account expired
  • 0.1% Valid credentials, account locked
  • 29.9% Valid credentials, password must be changed at next logon

This result confirmed the suspicion that the identified problem with the service desk not using randomly generated passwords was not just an isolated issue but fairly wide spread. Further, service desk was also not always forcing users to change their password on first use after the reset, and many users who requested a password reset through service desk were also not using their accounts immediately after the reset. I was previously unaware that you could confirm that a password is valid, and needing to be changed on next login, while at the same time not actually being required to change it.

Further analysis of the accounts with weak passwords showed that these weak passwords were also being used for generic, system or application accounts. Finally, the initial exercise was not detected by the security operations centre, the SIEM was not configured to look for transversal attempts, this has been changed and on occasion in the follow-up testing where the tester has made a mistake and locked a few accounts this has been detected quickly.

An exercise was undertaken to reinforce the service desk policies and process, and to get all of these accounts changed. This exercise certainly added value to our environment, and we have continued to perform it on a regular basis. Furthermore, it also showed that user will continue to select dumb passwords, and Microsoft will allow them to do so even when password complexity is turned on. Sadly Password1 is considered to be a complex password. We mailed our users who had weak passwords asking them to change the passwords.  Some users when asked to change their password from Password1 then went on to choose Password2 even when the mail provided explicit guidance on choosing strong passwords, no accounting for people. Wetware confirmed again to be the weakest link.

We have now implemented scripts to run on password change to prohibit the selection of some poor passwords, I would suggest you do something similar in your environment. Google common passwords, take those and add them to your banned list along with company specific common words and names.


Tags: , , , , , , ,

Categories: Research, Security

Leave a Reply

%d bloggers like this: