For those of you who have followed the NetSPI blog, you will (hopefully) have noticed that we do try to make our posts useful and informative. We’ve kept the rants to a minimum and the speculation non-sensational. Many of our posts are technical and focused on detailed descriptions of testing techniques. Some of our posts are less technical and focused on industry trends and advice. This post is not of the technical nature (I’m the wrong guy) nor is it really about industry trends (maybe a little). I want to use this post to focus on some industry-specific vocabulary. While there have been those in the security industry that have knowingly mis-used terminology to deceive clients, it seems that the trend is growing and we’d like to take the time to help those of you who read this blog or stumble over this post really understand what a few related, but very different terms mean. Specifically I want to focus on the term ‘Penetration Testing’ and its derivative services. Please note that I’m writing this for both the people outside the security community that are buying penetration testing or penetration testing tools as well as consultants and technical assessors within our industry. I think that there are many on both sides that are either ignorant or willfully misusing language. Here’s how NetSPI (and our clients) define the term:
Penetration Test – An assessment of an environment or application (or both) that utilizes a combination of automated tools and manual processes to 1) enumerate vulnerabilities, 2) verify the existence of the vulnerabilities, and 3) safely exploit those vulnerabilities to better understand the risk that those vulnerabilities pose to the environment.
Please note that this is a three-part process. If you only enumerate vulnerabilities it is NOT a penetration test (this is sometimes called a ‘health check’ or is referred to as a ‘scan’ as it is primarily an automated exercise). If you only enumerate vulnerabilities and verify that they exist it is NOT a penetration test (this is what NetSPI calls a ‘Vulnerability Assessment’). Note also the phrase ‘a combination of automated tools and manual processes’. If you are only using automated tools and are not manually testing, verifying, and penetrating, you might be able to call what you are doing a ‘Penetration Test’, but it’s a very, very poor one. There are a lot of information security companies out there right now that provide ‘Penetration Tests’ that stop at enumeration. There are also a lot of companies out there selling ‘Penetration Tests’ that might verify some or all of the vulnerabilities they enumerate actually exist. Both of these situations are misleading and we constantly have to educate organizations on what the term ‘Penetration Test’ really means. It has ‘penetration’ in the name, for goodness sake; if there is no penetration how can it be called a ‘Penetration Test’?
Level of Service
Vulnerability Enumeration through Automated Scanning / Reporting
“Scan”, “Health Check”
Vulnerability Enumeration and Verification Through Automated Scanning and Manual Processes
Vulnerability Enumeration, Verification, and Safe Exploitation through a Combination of Automated Tools and Manual Testing
I realize that for many of you (most of you, hopefully) this post is nothing new. If so, I’m certainly sorry for wasting your time, but every time I think we as an industry are past this issue it pops up again. I’ve also discovered that non-security executives often seem to think that a pen test is a pen test is a pen test and while this certainly isn’t the case (there is real skill involved in effective penetration testing, as well as the need for a solid process), what’s really frustrating is that it’s often the situation that what people call a pen test is actually a vulnerability assessment or a scan and that drives me nuts. In any case, please let me know if you have any feedback or thoughts on this topic. This is a big one for us – NetSPI focuses very heavily on penetration testing (as well as vulnerability assessment) and, in my opinion, we are the best in the business. Even if you’re in the industry and want to argue with me on that (btw – you’re wrong), I hope that you are doing your part to help educate clients as to the differences between these terms and the levels of service associated with each. Alex Crittenden
Mobile security is the new hotness. The conventional wisdom hasn’t yet been established, but many security proponents are gunning for users who jailbreak or root their devices. Symantec and Good both offer enterprise solutions that include features to manage root privileges on employee devices. Unfortunately, malware engineers just changed their approach. As background, many approaches to mobile security rely on preventing users from gaining root access. Root access allows a user ultimate control over the phone, regardless of the inherent protections built into the device’s operating system. Many users who go about acquiring root access do so in order to harmlessly customize their device. Some users leverage root privileges to subvert controls on functionality like mobile tethering. In any case, this process is seen as a risk since a user who roots their phone is capable of granting these enhanced privileges to any application that requests escalation. If a user inadvertently grants root privileges to a piece of malware, that malware could access any data on the phone, including potentially protected, corporate information. In August, a piece of malware called GingerMaster was found to escalate to root privileges on any device compromised. From a management perspective, it no longer matters whether or not users in a given environment have rooted handsets. At this point, a user with a rooted device who installs a malicious app is just as likely to expose sensitive or controlled information as a user without a rooted device. This means there isn’t a technical control that can prevent a given user from installing a malicious app and accidentally compromising anything from their email to their entire corporate environment. Just like with SSL certificates, users will have to learn to differentiate between helpful apps and malicious ones. Thankfully, attackers are still disguising most of their malware pretty poorly. The cutting edge malware GingerMaster, for example, was disguised as “Beauty of the Day.”
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.
ipconfig / ifconfig
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.
The Reverseraider tool found on the Backtrack Linux distribution is capable of doing the same thing as an Nmap list scan.
Command: ./reverseraider -r
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.
Start sniffer and review for domains.
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.
Command (Get list of Windows systems with RDP): nmap –sS –PN –p3389
Log into the RDP using the RDP client and view available domains via the “Log on to:” drop down list.
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.
Command: NLTEST /DOMAIN_TRUSTS
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.
Command: ./dnswalk victem.com.
Enumerate Domain Controllers
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.
Command: nslookup -type=SRV _ldap._tcp.
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.
Command : nltest /dclist:
FindPDC is a tool by Joe Richards from joeware.com that will identify the primary domain controller via native Window API calls.
Command: findpdc /
NMAP Port Scan
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.
Command: nmap –sV –PN –p636,389
Here are a few methods that can be used as an authenticated domain user.
Adfind (LDAP Query)
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.
Command: net group “Domain Controllers” /domain
Enumerate Users from Domain Controllers
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.
SMB RPC: Endpoints
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.
Command: ruby c:metasploitmsf3msfcli auxiliary/scanner/smb/smb_lookupsid SMBDomain=. MaxRID=10000 RHOSTS= E > domain_users.txt
SNMP Default Strings
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.
Command: ruby c:metasploitmsf3msfcli auxiliary/scanner/snmp/snmp_enumusers SMBDomain=. RHOSTS= E
Adfind (LDAP null base/bind Query)
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.
Find SharePoint servers with nmap, Nessus, or your favorite scanner.
Attempt access via anonymous, null smb login, or existing credentials.
Once access is obtained, navigate to https://www.[website].com/sites/[sitename]/_layouts/userdisp.aspx?Force=True&ID=2
This will allow you to view domain user information by changing the ID parameter in the URL.
Use Burp Suite or your favorite fuzzer to BF the ID number and parse the users from the server response.
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.
Command: net users /domain
Enumerate Password Policy from Domain Controllers
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.
SMB RPC Endpoints
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.
Command: net accounts
Perform Dictionary Attack
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).
Command: Easy to use GUI and not CLI that I know of.
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.
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.
Command: FOR /F “tokens=*” %a in (‘type passwords.txt’) do net user \IPC$ /user: %a
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.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Discover why security operations teams choose NetSPI.