Active Directory: My Way (Part 2)
In this post we’re gonna go through 2 attack vectors that you would do in the beginning itself. Explaining the attacks in the best way possible, I have tried to include flow diagram wherever possible, not to miss out, the reference for further reading are mentioned at the end of this post.
Whenever we start a pentest in an AD environment, we lookout for a way to get into the network. Typically we’re remote or on site without any credentials or anything. So here we’re gonna look for how we can abuse features of windows and misconfigurations and utilize those to get access to get access to user accounts, credentials and machines as well.
Attack Vectors:
1. LLMNR Poisoning:
What is LLMNR?
→ LLMNR stands for Link-Local Multicast Name Resolution (LLMNR) and is a protocol based on the Domain Name System (DNS) packet format that allows both IPv4 and IPv6 hosts to perform name resolution for hosts on the same local link. Earlier it was known as NBT-NS (Netbios Name Service).
→ The catch here is that whenever a machine on a windows network, sends a DNS request for a particular host then it can be fooled to make it believe that a hacker on the same network has the requested resource, which results in that victim machine sending the username and NTLMv2 hash which can be cracked locally by using any password cracking tool such as hashcat.
The diagram perfectly explains the concept:
So basically, whenever you begin a pentest in an AD environment, start the responder tool which can be found in the impacket tool set.
Concept: Responder, as the name suggests, responds to these requests. It listens on the network for such requests and if any such request is found then responder responds and receives the username and NTLM hash for that user.
Syntax: Responder.py -I tun0 -rdw
Mitigation for LLMNR Poisoning:
In this case, the best defence is to disable LLMNR and NBT-NS because if DNS fails, it goes to LLMNR and if LLMNR fails it goes to NBT-NS.
Steps:
1. For disabling LLMNR:
Go to Group Policy Editor and click on “Local Computer Policy” > “Computer Configuration” > “Administrative Templates” > “Network” > “DNS Client” and select “Turn OFF Multicast Name Resolution”.
2. For disabling NBT-NS:
Go to “Network Connections” > “Network Adapter Properties” > “TCP/IPv4 Properties” > “Advanced Tab” > “WINS tab” and select “Disable NetBIOS over TCP/IP”.
If for some reasons, disabling these services is not an option then you can:
- Set up Network Access Control (Setting up MAC based access to certain connections/ports.
- Suggest users to use strong passwords so that the hash can’t be cracked (+14 chars, upper/lower, special symbols and everything else on the keyboard).
2. SMB Relay Attack:
What is SMB?
SMB stands for Server Message Block and is a protocol for sharing files, printers, serial ports. It is a client server, request-response protocol.
→ The vulnerability arises when we relay the hash we get from LLMNR poisoning or any other method, to some other machine (most probably, a server) and possibly, gain access. The diagram below tries to explain what actually happens versus what happens when an attacker performs this attack. Below is a diagram representing the flow of attack.
The one necessary condition for this attack to work is that SMB signing must be disabled on the target machine and the reason is because SMB is a packet level protocol and so, it can recognize if the request that is being relayed is from the original user or not. Now, to discover all the hosts which have SMB signing disabled, we can use the NSE (Nmap Scripting Engine) in the following way:
nmap --script=smb2-security-mode.nse -p445 < IP of subnet >/24
Example: nmap --script=smb2-security-mode.nse -p445 192.168.34.0/24
We will take the IP address of the hosts which return with either of the following results (from our nmap script):
- SMB signing disabled
- SMB signing enabled but not required
And save them in a file name “hosts.txt” for our relay script, to forward to.
This will give us the hosts where we can relay the initial request with hopes of gaining access to a machine. Now this is actually similar to the fundamental concept of password spraying, since what we are really doing is taking a request and spraying it on all the possibly-vulnerable hosts, in hope that this user might have an account on one host (and mind that this user needs to have an admin account on it) and we might get access to it.
So at first, we’re gonna turn the responder off for SMB and HTTP port and the reason for that is simply because if we catch any kind of request on these ports, then we don’t want to respond but relay that request to some other machine. We’re gonna do that by changing ‘On’ → ‘Off’ in file
/etc/responder/Responder.conf
and then setting up our responder to listen for these incoming requests and also have our NTLM relay script from the impacket collection, to forward to our possibly-vulnerable hosts:
ntlmrelayx.py -tf hosts.txt -smb2support -i
Here, the flag:
“tf” stands for target file.
“smb2support” stands for adding support of SMB2.
“i” stands for interactive, meaning we want an interactive shell.
Now when any host attempts to connect to any such server, our responder will capture the request and the ntlmrelay script will relay that to our target hosts which we found from the nse script and when we do get a connection, our ntlmrelay script will get us a shell on a port. Since we are connecting over smb, this will be an smb client and the script will show us the port number on which we have that shell. We can start a netcat listener in a different terminal and receive that connection to interact with it.
We can have multiple options with this script:
- Use it to execute a reverse shell executable and get a meterpreter session through multi handler with the ‘-e’ flag:
ntlmrelayx.py -tf hosts.txt -smb2support -e revshell.exe
- Use the same script with ‘-c’ (command) option to execute any particular command as we receive the shell:
ntlmrelayx.py -tf hosts.txt -smb2support -c “dir”
The following flowchart explains the execution of the scripts:
Mitigation for SMB Relay Attack:
- Enable SMB signing on all devices.
Pro: Completely stops the attack.
Con: Might cause the rise to performance issues. - Disable NTLM authentication on network.
Pro: Completely stops the attack.
Con: If kerberos stops working then windows will fall back to NTLM. - Account tiering:
Pro: Provides limited permissions to the domain admins leading them to execute certain tasks only.
Con: Enforcing policy might be hectic because loopholes might go unnoticed. - Local Admin Restriction:
Pro: Will definitely stop the scope of lateral movement.
Con: The number of service desk tickets might arise due to the limited access.
External References:
- Cqure Academy (Link)
- Sans Resource (Link)
- SecureAuth Resource (Link)
- byt3bl33d3r’s blog (Link) <Personally recommend this one>
- TCMs’ YT Resource (Link)
I’d also like to give a huge shout-out to TCM for his course on Udemy (link). I’d highly recommend his course if you want to learn more in-depth things.
