TechScrawl.com

Consider this situation and how you would respond: you come back from lunch to find thousands of your Active Directory user accounts locked because of bad login attempts. I recently had a tool run on my AD domain that had the potential to do just that, fortunately it only caused a single failed attempt for each account and did not lock them. But what if it had? It got me thinking about what I would do. The first thing I would have tried was a bulk selection of accounts in Active Directory Users & Computers, and then look for the option to mass-unlock them. Unfortunately that option isn’t there. You can bulk select accounts and Enable/Disable them, but there are no options for mass unlocking. Similarly, it appears the dsmod command line utility doesn’t support this option.

Unable to find a solution, I pieced together a script that will parse through AD accounts, and unlock any locked accounts that it finds. I also added a read only option that will just report on locked accounts. Thanks to those at the Minasi Forum for help in getting me started on this. You can get the script here. If you download it, replace the .doc extension with .vbs to run it. Keep in mind that I’m not a coder, so it may be messy, but it is tested and effective in a pinch.

In the process of working on all of this, it got me thinking about how easy it would be to mount this type of attack against an AD infrastructure, and what could be done to minimize the risks. As I mentioned above, this problem was the result of a legitimate tool that was incorrectly run. But what if someone wanted to deliberately lock all of your accounts? Imagine the damage this 12-line script would do:

On Error Resume Next
Set objFSO = CreateObject("Scripting.FileSystemObject")
acctsFile = "acct_list.txt"
Set objApp = CreateObject("WScript.Shell")
Set objNet = CreateObject("WScript.Network")
Set objFile = objFSO.OpenTextFile(acctsFile, 1)
Do While Not objFile.AtEndOfStream
acct = objFile.ReadLine
For count=0 To 2
objNet.MapNetworkDrive "", "\\server-dc01\c$", "false", acct, "badPasswd"
Next
Loop

That took me about half an hour to come up with, and it just loops through a text file listing of account names, attempting 3 logon attempts with each account, using a bad password. Depending on your account lockout policies, that would have just locked any accounts in the text file. This is basically a form of a denial of service attack. The fact that AD locks accounts after a number of incorrect login attempts is a desired behavior, it keeps resources safe from dictionary attacks and password guessing. But for someone who’s goal is a DoS attack, it makes things easy. All they need is your account names. If it’s an internal user, for the most part, you’re out of luck. They’re going to have the rights to read account names, all they need is Active Directory Users & Computers (downloaded from Microsoft) or any other number of LDAP query utilities. Using logfiles, you’re going to be able to find out who the culprit is. So you just have to hope the risk and repercussions outweigh the reward for any disgruntled employees. That statement holds true for most insider threats, whether related to technology or not.

Things are a little bit harder for an external attacker. It won’t shouldn’t be quite as easy for them to get a list of your account names. Hopefully your public email address format isn’t the same as your AD account format. If it is, you’ve made it a lot easier. Think about other potential areas of account info leakage specific to your environment. Protect your accounts & public AD exposure; 2003 AD in native mode doesn’t allow anonymous account enumeration, but if an attacker can compromise even one account, they can authenticate and enumerate account info. So what if an external attacker does get a list of your account names, the above script shouldn’t work from outside. What could he do? Do you have Outlook web access? Public web sites requiring AD authentication? Simple VPN remote access services? Any other publicly available resources that require AD authentication? It won’t be quite as easy to script those attacks, but it can be done.

So what can be done to minimize the risk? This isn’t a new problem by any means, and the traditional advice remains relevant. Guard your account information; use a different format for public email addresses; disable Guest accounts; don’t use shared accounts that can’t be audited back to a specific person; monitor your logs for suspicious activity; don’t expose unnecessary services, especially to the Internet; and make an effort to follow all other security best practices.

Disclaimer: I considered the decision whether or not to post the script snippet that causes account lockouts in this post, but feel that there was more benefit in doing so than not. If someone was truly intent on doing this type of attack, they would be able to do so without this post. Rather than describing potential risks and what “could” happen, I feel that showing how simple this could be done will be more effective in bringing it to the attention of IT professionals. That being said, don’t run that code in production.