Recently, we were requested to be on-site for a short pentest engagement carrying out an internal test on an Active Directory environment and a bit of WiFi testing. The network was fairly small-medium sized as all staff members within the company worked through an Azure workspace via SSH connection at all times – with the exception of one particular VLAN which hosted a number of Domain Controllers and local machines. We ran multiple port scans and performed deep enumeration as much as possible to find a foothold from a black-box perspective, however in the background of performing manual enumeration, I let Responder & Ntlmrelayx run in the background with the following flags:
Responder
Essentially what we are doing here is performing an LLMNR/NBT-NS Poisoning attack on the entire VLAN. Responder falls under the category of a Man-in-The-Middle vulnerability and pretty much aims to poison the entire network on various protocols by sending out/replying to broadcast messages and ARP requests constantly.
In a nutshell, Responder is relying on DNS to fail in the network so it can fall-back on LLMNR/NBT-NS (Enabled by default) to maintain the flow of traffic i.e. name resolution. This can be something like a user requesting to visit an SMB share but they end up mistyping the sharename or IP address. When this happens, our Responder tool is going to be the first IP address to “respond” to the client in which their password hash, Net-NTLMv2-SSP, is sent to us along with their username and domain. The issue with LLMNR/NBT-NS is that it is obviously vulnerable to poisoning and there’s no fix for it!
Below is an example of how LLMNR Poisoning works, what services Responder poisons and running ntlmrelayx:
At this point, all we need to do is let these tools run in the back (ideally first thing in the morning before staff enter, or just before lunch ends).
Ntlmrelayx
This tool is going to allow us to relay the captured hashes from Responder and send them across the entire VLAN and abuse those machines which have SMB Message Signing Disabled or “Enabled, but not required”. Upon doing so, ntlmrelayx will dump their local SAM database contents in which we can then steal NTLMv2 administrator password hashes and use them in a “Pass The Hash” (PTH) attack or try crack them. Responder may seem like the Holy grail of internal pentesting, and it probably would be (in my mind) if it weren’t for the fact that the hashes Responder captures MUST be cracked and cannot be used in a PTH method. For this reason, it is crucial to run ntlmrelayx in conjunction!
Near the end of the day, we didn’t pick anything up as all staff members are using their own laptop devices and remotely connect to an Azure workspace via SSH, so we didn’t see any traffic on Responder which was discouraging, a little.
Eventually, we ended up capturing 2 password hashes – one belonging to a machine account for some reason (denoted by the name ending with a ‘$’ symbol) which is near impossible to crack, and the other belonging to an actual user.
It turned out – the user ended up being the actual client himself who had DA privileges throughout the entire six VLANs. Incredible luck!
Our Responder ended up assuming the IP address of an existing RADIUS server as far as I know and when the client initiated an RDP session to what he thought was their own server, was actually Responder.
At this point in an engagement, you pretty much owned the entire network from a black-box perspective meaning any local threat actor had the ability to perform the same attack with malicious intent. With the captured hash you can try cracking it with various Hashcat wordlists, rules and mutations or if you’d remembered to keep Ntlmrelayx running alongside (which I didn’t…) you probably don’t need to crack that hash and can continue moving laterally within the network and steal all the passwords!
Remediation Advice:
With LLMNR/NBT-NS Poisoning it’s a really simple fix. The following should be applied to all machines and should be easily managed via Group Policy:
- Disable LLMNR
- Disable NBT-NS
- Enforce and enable SMB Message Signing
