Based on my experience, nine out of ten environments will have at least one account configured with a weak or default password. Those weak configurations usually lead to the compromise of the entire Windows Domain, so it is important to understand how to audit for them. Default passwords can usually be identified by your favorite vulnerability scanner or through manual review. However, weak passwords typically need to be identified through dictionary attacks (although there are other methods). Also, commonly referred to as “password guessing attacks”, dictionary attacks have proven to be almost as affective today as they were 20 years ago. Although they’re not very sexy, dictionary attacks should be part of every penetration tester’s approach. In this blog I will cover the basics of how to perform dictionary attacks against Active Directory accounts safely. Below is an overview of the steps that will be covered:
Note: Most of the tools and techniques will be done from Windows systems. Also, just as an FYI, I use the UNIX Windows ports for parsing in some of the examples.
Below are a few common methods for enumerating Windows domains as an unauthenticated user.
In most cases, simply using the IPCONFIG command will provide the domain associated with a DHCP assigned IP address. This is nice because it’s an easy solution that uses native technology.
NBTSTAT is also a native Windows command line tool that allows users to enumerate some basic information about a remote Windows system like the domain, workgroup, computer name etc. Below I’ve shown how to issue a basic NBTSTAT command to enumerate the domain associated with a remote Windows system.
Combining some basic scripting with Nmap list scan output can return a list of domains associated with systems on known network segments.
The Reverseraider tool found on the Backtrack Linux distribution is capable of doing the same thing as an Nmap list scan.
Sniffing can usually reveal some domain information from browser and DNS traffic. Common tools for network monitoring (sniffing) include Wireshark, TCPdump, Cain, and Network Minor.
This is not a very efficient method, but it still works. Simply remote desktop to a Windows system on the network and view domains from the standard drop down.
Additional domains can be enumerated using some of the basic methods below.
Nltest is a diagnostic tool that has many uses, one being the ability to enumerate trusted domains. It should be noted that many other tools including, but not limited to, Nessus, NeXpose, IP360, Super Scan, can do this as well if null smb logins are possible.
DNSwalk should be able to enumerate subdomains via domain transfer. Also, there are quite a few DNS brute force tools available that could be used.
When attacking domain controllers it really helps to know where they are. To help with that I’ve provided a few common methods that can be used from a Windows system for an unauthenticated perspective.
This is by far the quickest method I know of at the moment. To my knowledge, when a server is promoted to a domain controller, a DNS service entry is automatically added for LDAP, Kerberos, etc. This allows users to issue a basic DNS service query to get a list of those servers. This can be accomplished with the native Windows nslookup command from non-domain Windows system.
Nltest test has the ability to query for a list domain controllers via broadcast request as well. This tool has been a Native Windows command line tool since Windows 7, but I believe it has been available in the admin toolkit since Windows 2k.
FindPDC is a tool by Joe Richards from joeware.com that will identify the primary domain controller via native Window API calls.
Simply scanning for LDAP ports 636 and 389 should help you find domain controllers as well. It will not guarantee that every system found is a domain controller, but it will get you started in the right direction.
Here are a few methods that can be used as an authenticated domain user.
Lots of information is available to regular domain users via LDAP queries. Adfind is another tool by Joe Richards from joeware.com that will allows users to query for a domain controller list. I should also note that if you are able to create a null/bind and get full access to the LDAP directory you may be able to accomplish this without being an authenticated Domain user. FYI – In the past I’ve also used LDAP Miner, LDAP Browser, and LDAP explorer in Windows. They can do the same thing and have pretty GUIs for screenshots.
Hooray for native tools! The ‘net group’ is another native Windows command used to manage groups, and it is capable of listing members of the “Domain Controllers” OU (among others). This needs to be run from a Windows system already on the domain.
Some people like shooting in the dark by using a large list of potential usernames during dictionary attacks. I, on the other hand, am a little partial to saving time so I prefer to just dump a list of users from the domain controller via available services. For those who also prefer the latter I’ve provided some common user enumeration methods below.
With a null SMB connection and a few poorly configured group policies you should be able to enumerate all of the users in the domain via SMB RPC endpoints. There are quite a few tools out there, but I have had some consistent success with Enum and Dumpsec. Sometimes one will work when the other one doesn’t. My guess is that it has something to do with what RPC endpoints are being accessed, but I don’t really know. If someone does know the actual answer please let me know! I haven’t had much luck with the Metasploit ‘smb_enumusers’ or ‘‘smb_enumusers_domain modules, but I could be missing something. Side note: Don’t forget to review the user comments in Active Directory for passwords. It’s incredibly common.
The method brute forces SIDs associated with user accounts. There is a old tool called ‘getacct’ created by a company called Security Friday that still works and has a nice export, but I recommend using the Metasploit module for the sake of centralization. However, be sure to set the MaxRID parameter to 10000 or greate to make sure you can enumerate all of the domain users. The “sid2user” and “user2sid” tools combined with some scripting can accomplish the same goal if you would like another scriptable option . In the example below, I show how to call the module from msfcli on a Windows system, but it can be executed from the msfconsole as well.
It’s kind of surprising how many domain controllers out there are configured with SNMP and a default community string of ‘public’. Such configurations will allow you to conduct an SNMP walk to enumerate all kinds of interesting information about the system, including a list of users. There are many tools that could be used for this but the most common seem to be snmpwalk, MIBBrowser, and the Metasploit ‘snmp_enumusers’ module.
Adfind can also be used to dump domain users from domain controllers that allow a full anonymous null/bind. This is more typical on legacy Windows 2000 DCs; these days, I don’t see that often. Once again, in the past I’ve also used LDAP Miner, LDAP Browser, and LDAP explorer in Windows to do the same thing.
Although SharePoint sites usually don’t live on domain controllers, they do exist in most enterprise environments. With that in mind, they can make a pretty dependable vector for enumerating domain users. Please note that in some cases you may have to establish null smb login prior to accessing pages, and in some instances access to site may be completely restricted for anonymous users. This particular method is a little more multi-step then the other options.
Here are a few methods that can be used as an authenticated domain user.
WMI is a Windows scripting language that allows users to query and manage local and remote Windows configurations. WMIC is a nice command line tool that is basically a wrapper for WMI queries. Based on my half an hour of research, it sounds like WMI has been around since Windows 2000, but Microsoft didn’t introduce the WMIC command line tool until Server 2003. Either way, it can do fun things like start and stop processes, manage shares, and (you guessed it) dump users.
Who could forget the “net users” command? As its name suggests, it’s a native Windows command that can be used to manage local and domain users. Contrary to popular opinion, the “net users” command can only be used by an authenticated local or domain user. That means it cannot be used to enumerate users that exist on a remote system, but can be used to enumerate domain users if the system running the command is associated with the domain. If anyone knows better please let me know.
This may be the most important thing you do. If you don’t respect account lockout policies during a dictionary attack you could potentially take down the entire environment by locking out accounts. I’ve never experienced it, but I have heard some crazy horror stories. Without going into too much detail, the things you need to know are the “lockout threshold”, and “lockout reset/observed reset time”. The “lockout threshold” refers to how many logins the user can attempt before their account is locked. The “lockout reset” refers to the number of minutes that go by before the login attempt count is reset to 0. So, for example a threshold of 5 and a reset of 15 means that a user can attempt 4 passwords every 15 minutes without locking the account (in most situations). Below are a few options for getting the policy information.
We’ll use some familiar tools to grab the policy information. You can use either of the options below for the same result.
Here is at least one other method that can be used as an authenticated domain user. It can also be done via SNMP and some other protocols.
Another net command, what do you know? As an authenticated domain user, the follow command will provide the password policy.
Suprise! There are a lot of options for performing dictionary attacks against Windows systems. Regardless of the toolset and dictionaries used, the important thing is to respect the password policy when the attack is performed. That way, accounts configured with weak passwords can be identified and none of them will get locked out. As far as dictionary lists are concerned you can always grow your own, but a few of the more popular ones include the Rockyou and John the Ripper lists. Below I’ve listed a few tool options. Note: Don’t forget that for some the options below require a null smb login first.
This seems to work pretty well on Linux and is a little faster than Bruter. However, I haven’t been able to get it to work on any Windows systems. It also supports using hashes instead of a traditional pw list, which is pretty cool.
Say what you will about GUI Windows tools, but this dictionary attack tool consistently works. It has a few good options and makes pretty screen shots for reports (with redacted passwords, of course).
This is another nice option that I have had some success with. I hear the recommend thread count is 15 on Windows and 254 on Linux – so it can go pretty fast, but it has no output to file option. So at the moment I just parse it with other tools. Either way it can be executed through any of the Metasploit interface including the msfconsole and msfcli (which can be handy for scripts). Below is how to run it with msfcli on Windows.
This can be a little buggy, but sometimes it works without throwing up on itself. My guess is that I’m just missing some switches, but maybe others have had more success.
Here is a native Windows scripting option if you happen to find yourself without a real dictionary attack tool. It’s a very slow method, but it does work in a pinch. Also, I guess you could do a nested FOR loop to target multiple users, but I haven’t tested that.
As I’ve tried to point out, there are many tools and techniques available for conducting dictionary attacks against Active Directory, so don’t give up just because your first vector fails. Once again, don’t forget to respect those password policies! Good luck and hack responsibly.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Read More
Name | Domain | Purpose | Expiry | Type |
---|---|---|---|---|
YSC | youtube.com | YouTube session cookie. | 52 years | HTTP |
Name | Domain | Purpose | Expiry | Type |
---|---|---|---|---|
VISITOR_INFO1_LIVE | youtube.com | YouTube cookie. | 6 months | HTTP |