Transversal password cracking with NMAP (without downloading the hashes)
Posted on February 2, 2013A 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 (cqure.net) that would make use of the LDAP service of Active Directory. The documentation on the script was found here : http://nmap.org/nsedoc/scripts/ldap-brute.html. 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" DC1.org.net
- replace the DC1.org.net with the address of your domain controller
- users.txt contains the usernames in format : username@org.net (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
- USERNAME:PASSWORD:Comment
- Valid credentials
- Valid credentials, account disabled
- Valid credentials, account expired
- Valid credentials, account locked
- Valid credentials, password must be changed at next logon
- 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: active directory, cqure.net, ldap, ldap-brute, nmap, password cracking, Patrik Karlsson, poor passwords
Categories: Research, Security
What people say
Close block