In this post we will look at a common pentesting scenario that works on most organizations I work with. While many people think that pentesting is all about missing patches and default passwords, even in a up to date environment, features of the protocols and operating systems can give up the keys to the kingdom as easily as a remote code execution vulnerability. In the next post we will look at ways to stop this sort of attack from working in your enterprise environment.
On internal pentests one of the first things I do is start up a rogue HTTP and SMB service to do Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) poisoning and capture NETNTLM hashes. There are a number of different ways to do this, but the easiest is using a tool called Responder.
Although NETNTLM hashes are not useful for techniques such as pass the hash, I can use a standard password cracking tool such as Hashcat to recover the passwords. Give it a solid wordlist and some of the rule files included with the tool, and chances are I’ll get at least a few plaintext passwords.
From there I can use a tool such as SMBExec to use the credentials to log into machines and look for additional password hashes, or better yet plaintext passwords in memory. SMBExec is a great tool for this sort of thing because it utilizes the Windows Credential Editor (WCE) to recover local password hashes, domain cached credentials and any password stored in memory. The passwords stored in memory are my favorite because they are in clear text so it doesn’t matter how long or complicated they are. Generally, I go for the local admin password hash first because then I can take advantage of the pass-the-hash attack.
Many organizations have the same local Administrator password throughout the enterprise so, once I get access to the local admin hash for one machine, I can use it to log into additional machines using pass the hash without having to first crack the hashes. Another great feature of SMBExec is the ability to login to lots of machines very rapidly and check to see if a domain or enterprise admin is logged in.
By moving around the enterprise this way, I don’t have to run any exploits or payloads and I am bound to find a Domain Administrator logged in to a machine, where I can recover the password in plaintext from memory.
First we use Responder to listen for and reply to all LLMNR and NBT-NS requests on the network. LLMNR was introduced in Windows Vista with the expectation that it would replace NBT-NS. When DNS is unable to resolve a hostname, these protocols call out to the broadcast domain and help look for the right host.
Let’s take a look at an example. Start Responder with the command below, where 192.168.1.77 is your local IP address.
root@kali:/opt/Responder# ./Responder.py -i 192.168.1.77
For example, many people search from the URL bar in the browser. Consider that you search for turtle in the URL bar of a Windows 7 machine that is a member of domain. The DNS server does not have an entry for turtle, so the Windows 7 target moves on to LLMNR to figure out where it is supposed to go.
Normally it would receive no response. However Responder will listen for the request, respond that our attack machine (192.168.1.77) has the name turtle, and send over a salt for the password hash. The Windows 7 target will respond with the NetNTLM hash.
In this case, this is an NetNTLMv2 hash. Some clients may use NetNTLMv1, which is easier to crack, but both rely upon weak passwords and/or a solid wordlist. Since we are not able to use pass the hash technique to authenticate over SMB with this hash, we will need to recover the password hash with a password cracker such as Hashcat.
NetNTLM hashes include a salt, which is sent by the server before the client sends over its password, hashed with the salt included. This is why we cannot just listen passively on the network for these hashes; we need the salts as well. Hashcat will take the words in our wordlist, hash them with the NetNTLMv2 algorithm using the supplied salt. If the resulting hash is the same as the one we captured, we have found the correct plaintext password.
Use the command below to run Hashcat where 5600 is the mode for NetNTLMv2, capture.txt is the output of Responder, capture.cracked is our output file and words.txt is the wordlist.
root@kali#:hashcat -m 5600 capture.txt –o capture.cracked words.txt
Assuming the correct plaintext password is in our wordlist, Hashcat should be able to recover the password. In this case, the password for the user martin in the BULBSEC domain is Password1, a bad password indeed.
From here we can use SMBExec to see what machines BULBSEC\martin has SMB login access to and dump any password hashes from the SAM file, memory and Active Directory MSCACHE cached credentials. To dump passwords, from the main SMBExec menu, choose option 3. Obtain Hashes. Input the correct values for the IP addresses and login information.
In this case, SMBExec was able to find five local users, three MSCACHE credentials from cached previous domain user logins (the default group policy option is to save the last 10), and four plaintext passwords for logged on users in memory.
Any local hashes we find can be used to login over SMB with pass the hash, saving us the trouble of having to crack the hash with Hashcat. Pass the hash works because SMB logins do not use a salt so access to the hash equals access to the correct response to the server challenge. Just paste the hash into the password field in SMBExec to pass a local hash to other systems to try to dump more credentials. Rinse, lather, and repeat until we find credentials for a domain administrator or an enterprise administrator, giving us control of the entire domain.
In this case it finds the user georgia which is a domain admin in this environment.
