After finishing the OSCP and taking a short study break, I’ve set a few goals to further my offensive pentesting knowledge. One of these goals is learning more about Active Directory enumeration, attacks, and in general, what to do once access to an internal network has been established. I’d heard a lot of good things about how effective Responder is in capturing hashes and credentials on a network and how you can later utilize those credentials/hashes for further lateral movement. I spun up my Active Directory environment set up in my lab and played around with Responder and NTLMRelay from impacket for the last few days and wanted to write up a quick post that I can use for future reference as a cheat sheet of sorts.
After landing in an internal network we need to find out if there are machines with SMB signing enabled but NOT required for this method to work. To quote Microsoft “SMB signing is a security mechanism in the SMB protocol and is also known as security signatures. SMB signing is designed to help improve the security of the SMB protocol.” You can learn more about it here — https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/overview-server-message-block-signing
We can check SMB signing with a pretty simple NMAP script.
We can see from the results of the script that 192.168.11.8 does not require SMB signing and we should be able to capture a hash. Time to boot up Responder.
Once Responder is up and listening on the correct ethernet port, we are ready to capture a hash from our victim machine, 192.168.11.8. In my lab I just tried to access a file share from the victim machine pointing to my Kali machine to get it to send the hash over to Responder. In the real world, I think there would need to be either misconfigurations for SMB shares, typos when mapping a drive or accessing a file share or even a social engineering campaign to get a user to click on a link pointing to our Kali box.
Anyways, as soon as I tried to access the file share on my Kali machine I received a NTLMv2 hash from 192.168.11.8 for user1.
We can then take this hash and try and crack it with Hashcat. With some luck, we’ll end up with a clear text password that we can utilize to further gain access into a network.
PS C:\Program Files\hashcat-6.2.3> .\hashcat.exe -m 5600 .\hashes\relaypractice.txt .\wordlists\rockyou.txt
NTLMRelay
We can further utilize Responder to establish a session on a target machine using the hash we capture by using Impacket’s ntlmrelayx.py script.
First we need to edit Responder’s configuration file to disable SMB and HTTP. The file is located at /etc/responder/Responder.conf.
Start Responder like we did earlier in the blog post and then start ntlmrelayx.py. In this example we will be capturing a hash from 192.168.11.8 and passing those credentials to 192.168.11.5 which should establish a session.
Once a hash from a user is captured by Responder it will be passed to NTLMrelay which will hopefully establish a SMB client shell for us.
This time we captured the Admininstrator’s hash and were able to establish a session. We just need to connect to the port for the session established on our Kali machine and we should have a SMB client shell to 192.168.11.5.
We can now use this access to further enumerate 192.168.11.5, find sensitive files stored on the shares or potentially establish a fully interactive session or shell.
