TL;DR how to perform name poisoning in the lab and how to mitigate.
Background
In previous articles I went over some common post exploitation attack methods an intruder will use in a Windows domain once they have gained access as a domain user and/or a local administrator on a workstation and mitigations against them. This is about how an attacker might gain access to an account in the first place. This assumes that they have only gotten access to the LAN that domain workstations are on.
Link Local Multicast Name Resolution (LLMNR) is an older protocol that is included in Windows to this day for backwards compatibility. There is really no need for it in most Enterprise environments today and there are some security concerns with leaving it enabled. The problem is that by default in Windows 10 LLMNR broadcasts a query if the requested resource is not found in DNS. For example a domain user might type \\fileservet by accident instead of \\fileserver if they are manually connecting to the share drive. Since Windows will broadcast a query for ‘fileservet’ in this scenario, an attacker can simply run a script that listens for these broadcasts and then responds that it is in fact ‘fileservet’. Windows will then attempt to authenticate to the attacker.
LLMNR and NBT-NS poisoning:
All the attacker needs is Kali running on the same network to execute this. They can simply run the aptly named Responder and wait for someone to fat finger a share name:
responder -I eth0 -rdwv
If Responder gets a domain workstation to attempt to connect it will show the IP, username, and authentication details.
The attacker can then simply copy and paste this response into a text file and put hashcat to work cracking it:
hashcat -m 5600 TEST_hash.txt mywordlist.txt --force(That is “<dash><dash>force”. Medium converts it to a single dash.)
In this case the attacker used a bit of social engineering, scraped the employee’s social media accounts, and guessed that they were a Carolina Panthers fan. They then built a wordlist based on that educated guess and ran permutations to figure out what the password is.
crunch 20 20 -t CarolinaPanthers^^%% -o /root/Documents/mywordlist.txtCheat sheet for tacking things onto the end of a base password in crunch:
- @ = lower case letters
- , = upper case letters
- % = numbers
- ^ = symobls
Attackers know that the default password requirement in a Windows domain is two upper case, two lower case, two special characters, and two numbers. They are also well aware of habits that users tend to follow.
NTLM relay:
What if we didn’t have a good wordlist based on the employee’s social media though, or if they used a password that is based on something known only to them? Is there a way to abuse the captured authentication attempt without needing to find the actual password?
As it turns out there is an old attack method for this known as ntlm relay. This attack relies on intercepting an authentication attempt just as Responder does, then relaying it to another Windows client automatically. Windows Servers require signing by default, but Windows 10 clients do not. The attack requires that the targeted account have local admin privileges on the targeted client system.
Attackers can scan for domain workstations that are vulnerable by running an nmap script.
nmap -p 445 --script smb2-security-mode <IP range>
They can then copy/paste the IPs of vulnerable systems into a text file and use it as a target list for a tool in Impacket aptly named ntlmrelayx. This tool is not included with Kali ‘out of the box’. It can be downloaded from https://github.com/SecureAuthCorp/impacket . Then simply unzip it, cd into the directory, and run:
pip3 install .Turn off the SMB and HTTP options in Responder by editing the ‘/etc/responder/Responder.conf’ file. Simply change the ‘On’ to ‘Off’ on the relevant lines.
Open a pair of terminal windows and execute
responder -I eth0 -rdwvIn one and in the other
ntlmrelayx.py -tf targets.txt -smb2supportAfter that just wait. Sooner or later someone will fat finger a share name or otherwise request something that does not exist in DNS. LLMNR and/or NBT-NS kick in by default at that point, Responder responds, and ntlmrelayx catches the authentication attempt and relays it.
The script automatically dumps the local accounts on the target systems. In this specific case all the accounts are disabled except for ‘test’. That account is managed by the Local Admin Password Solution (LAPS), so in this case it will not do the attacker much good. However in many environments this is not the case and all workstations have the same local admin with the same password. There is also the issue that the local admin account by default has debug privileges in Windows. This means that an attacker can run a Mimikatz style tool. Things can get really ugly really quick after that if a domain administrator uses that compromised workstation.
In this case since we just publicly posted the local admin hash to one of our VMs we will go ahead and tell LAPS to change it.
Mitigating LLMNR & NBT-NS poisoning:
The best mitigation is to disable LLMNR and NetBIOS Enterprise wide. Like most things in Windows, this can be centrally managed via Group Policy. Create a new GPO and link it to the Organizational Unit (OU) containing domain workstations. Edit the GPO, navigate to
Computer Configuration\Policies\Administrative Templates\Network\DNS Client
And disable multicast name resolution.
Disabling NetBIOS, and by extension NBT-NS, is slightly more complicated. One of the easier methods is to create a PowerShell script containing the following:
$regkey = “HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces”Get-ChildItem $regkey | foreach { Set-ItemProperty -Path “$regkey\$($_.pschildname)” -Name NetbiosOptions -Value 2 -Verbose}
Save it in
C:\Windows\SYSVOL\sysvol\test.local\scripts
On a Domain Controller (DC). This will cause it to automatically propagate to the SYSVOL on the domain (\\test.local\SYSVOL\test.local\scripts). Then add the script to Startup under
Computer Configuration\Policies\Windows Settings\Scripts
Once the domain workstations restart the script will disable NetBIOS on all network interfaces automatically.
After these GPOs take effect Responder will no longer capture authentication attempts by simply waiting on a user to fat finger an address. If a user accidentally types an address that doesn’t exist for a share they will simply see
And the attacker will see
Well, they won’t see anything. The client will fail to find anything in DNS and that will be that. They will not broadcast a request for the attacker to respond to.
Mitigating NTLM relay style attacks:
This style of attack is simple to mitigate against. However it is not setup this way by default. Merely navigate to
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Set ‘Digitally sign communications (always)’ to Enabled for client & server.
While a system administrator is in there it is not a bad idea to go ahead and navigate to
Computer Configuration\Policies\Windows Settings\Security Settings\System Services
and disable proxy auto-discovery.
Conclusion:
Taken together these mitigations will stop domain workstations from broadcasting resolution requests for an attacker to respond to. If the attacker does manage to attempt a relay attack the domain workstations will not allow authentication as the request is not coming from the correct system.
References:
https://tools.kali.org/sniffingspoofing/responder
https://cccsecuritycenter.org/remediation/llmnr-nbt-ns
http://woshub.com/how-to-disable-netbios-over-tcpip-and-llmnr-using-gpo/
https://medium.com/@benichmt1/secretsdump-demystified-bfd0f933dd9b
https://edico.no/tech/the-dangers-of-wpad-and-llmnr-protect-your-network/
https://osandamalith.com/2017/03/24/places-of-interest-in-stealing-netntlm-hashes/
