Passwords Part 2 - Passwords off the Wire using LLMNR

Passwords Part 2 - Passwords off the Wire using LLMNR
We ended yesterday’s story with what we hope was a successful password spray. Let’s assume that we can then use one of the accounts we harvested in that exercise to VPN in and RDP to a host on the inside network. That’s a pretty safe assumption – it’s pretty common to get Domain Admin access from at least one of the harvested accounts in a password spray. So, where do we go next from there? Well, let’s take a look at LLMNR – Link Layer Multicast Name Resolution. What’s that you say? Think back, think waaaay back to Windows 95. Back in those days, IP was pretty new to Windows admins, and name resolution tended to use WINS as much or more than DNS. If you didn’t happen to have WINS or DNS set up, clients would send a local multicast request out on port UDP/5355 for name resolution. And yes, that is still with us today. But surely Windows 7 or 10 won’t actually use that, right? Wrong-O! LLMNR is still very much in the name resolution search order. If you mis-type a server name when looking for or mounting a network share, mistype a printer name, or have a script that runs but targets a server that has been renamed or retired, the host will also make the LLMNR request. For instance, trying to access "\\clown\college" will generate this packet: A pentester can use a tool like responder to exploit this. Responder for instance will respond with “Yes, That’s Me” to the LLMNR request, and the host will then attempt to connect, sending the user’s credentials to authenticate the connection (userid and password hash). Running "responder -i <ip address> -I eth0" and capturing that same request as above will give you: Oops. You can then take that has as-is, feed it into hashcat (which just saw an awesome update yesterday by the way), and crack the password. First, put just the hash we’re targeting into a text file, then use a decent dictionary. Rockyou works nicely, the 1.7 million "consolidated" dictionary is my current go-to, but Troy Hunt's most recent 0.5 billion "pwnedpasswords" list might be a better option, stay tuned. The syntax for today is hashcat64.bin –m 5600 hashes.in –a 6 -1 ?s?d dictionary.in ?1?1 This takes the dictionary file, and adds 2 digits of special characters / numeric digits to each word in the dictionary. With 4 decent GPU’s, 1.7 million plus the 2 digits for one account goes pretty quick – 10 minutes does the job. What does this mean? What’s the point we’re making? The point of all this (aside from gathering credentials for the next pivot in your pentest) is to demonstrate that any malware or attacker capture these LLMNR packets once they are on the target network, and turn them into passwords. If you are on the right subnet, the chances of capturing Domain Admin level credentials is almost 100% - people tend to embed credentials into scripts, creds turn into hashes once they hit the wire, and collecting the LLMNR packets gets you those hashes. From a broader perspective, the real point and the real recommendation is that the customer should take a solid look at some hardening guides for both Windows and Active Directory - the Center for Internet Security is a good place to start for this ( https://www.cisecurity.org/cis-benchmarks/ ). The best advice is to start at the top of the guide and work your way to the end, assessing each benchmark to see what it might break or affect in your environment. I've never seen disabling LLMNR cause a problem in a production environment by the way, but please let us know in our comment form if you have!! What should you recommend to your client? Back to the specific recommendation, LLMNR is absolutely, positively NOT REQUIRED. It can be easily disabled in Group Policy, and that setting should be applied globally (Computer Configuration / Policies / Admin Templates / Network / DNS Client / Turn off multicast name resolution). LLMNR can also be disabled in the registry, for any stations that are not domain members. Stand up a packet sniffer periodically, and look for udp/5355 packets to catch any stations that might have been missed. =============== Rob VandenBrink Compugen	Rob VandenBrink 578 Posts ISC Handler Feb 22nd 2018
Thread locked Subscribe	Feb 22nd 2018 4 years ago
The big issue with disabling NetBIOs over TCP/IP is that the GUIDs are different from machine to machine, and network card to network card. So its not just as simple as running a GPO startup script, especially if your users are not local admins on their computers. It would be nice if MS would create a GPO option that would allow you to just tick off the radio button in the network card properties. Recently in SCCM, you can now run PowerShell scripts as packages. Running the following script as a package got this cleaned up fast on all our our computers: $adapters=(gwmi win32_networkadapterconfiguration ) Foreach ($adapter in $adapters){ Write-Host $adapter $adapter.settcpipnetbios(2) }	BuddyFrodis 1 Posts
Quote	Feb 26th 2018 4 years ago
That'll do the trick for Netbios over TCP (which again is not LLMNR). You can also just run that Powershell script across all domain members as admin - that's a good way to go too, as long as you have Powershell remoting enabled SCCM shouldn't be strictly required to do this. You can kill off NBT using DHCP also: Scope Options / Advanced / Microsoft Windows 2000 Options / Vendor Class / 001 Microsoft Disable Netbios Option (change to 0x2) The DHCP approach has the advantage of also fixing non-domain members, and the disadvantage of not working for laptops and mobile devices after they leave your network. Hitting this setting both in DHCP and in the device configuration using scripts is an effective "double tap" to fully disable NBT in both situations.	Rob VandenBrink 578 Posts ISC Handler
Quote	Feb 26th 2018 4 years ago

We ended yesterday’s story with what we hope was a successful password spray. Let’s assume that we can then use one of the accounts we harvested in that exercise to VPN in and RDP to a host on the inside network.
That’s a pretty safe assumption – it’s pretty common to get Domain Admin access from at least one of the harvested accounts in a password spray.

So, where do we go next from there? Well, let’s take a look at LLMNR – Link Layer Multicast Name Resolution. What’s that you say? Think back, think waaaay back to Windows 95. Back in those days, IP was pretty new to Windows admins, and name resolution tended to use WINS as much or more than DNS. If you didn’t happen to have WINS or DNS set up, clients would send a local multicast request out on port UDP/5355 for name resolution. And yes, that is still with us today.

But surely Windows 7 or 10 won’t actually *use* that, right? Wrong-O! LLMNR is still very much in the name resolution search order. If you mis-type a server name when looking for or mounting a network share, mistype a printer name, or have a script that runs but targets a server that has been renamed or retired, the host will also make the LLMNR request. For instance, trying to access "\\clown\college" will generate this packet:

A pentester can use a tool like responder to exploit this. Responder for instance will respond with “Yes, That’s Me” to the LLMNR request, and the host will then attempt to connect, sending the user’s credentials to authenticate the connection (userid and password hash). Running "responder -i <ip address> -I eth0" and capturing that same request as above will give you:

Oops. You can then take that has as-is, feed it into hashcat (which just saw an awesome update yesterday by the way), and crack the password. First, put just the hash we’re targeting into a text file, then use a decent dictionary. Rockyou works nicely, the 1.7 million "consolidated" dictionary is my current go-to, but Troy Hunt's most recent 0.5 billion "pwnedpasswords" list might be a better option, stay tuned.
The syntax for today is hashcat64.bin –m 5600 hashes.in –a 6 -1 ?s?d dictionary.in ?1?1
This takes the dictionary file, and adds 2 digits of special characters / numeric digits to each word in the dictionary.

With 4 decent GPU’s, 1.7 million plus the 2 digits for one account goes pretty quick – 10 minutes does the job.

What does this mean? What’s the point we’re making? The point of all this (aside from gathering credentials for the next pivot in your pentest) is to demonstrate that any malware or attacker capture these LLMNR packets once they are on the target network, and turn them into passwords. If you are on the right subnet, the chances of capturing Domain Admin level credentials is almost 100% - people tend to embed credentials into scripts, creds turn into hashes once they hit the wire, and collecting the LLMNR packets gets you those hashes.

From a broader perspective, the real point and the real recommendation is that the customer should take a solid look at some hardening guides for both Windows and Active Directory - the Center for Internet Security is a good place to start for this ( https://www.cisecurity.org/cis-benchmarks/ ). The best advice is to start at the top of the guide and work your way to the end, assessing each benchmark to see what it might break or affect in your environment. I've never seen disabling LLMNR cause a problem in a production environment by the way, but please let us know in our comment form if you have!!

What should you recommend to your client? Back to the specific recommendation, LLMNR is absolutely, positively NOT REQUIRED. It can be easily disabled in Group Policy, and that setting should be applied globally (Computer Configuration / Policies / Admin Templates / Network / DNS Client / Turn off multicast name resolution). LLMNR can also be disabled in the registry, for any stations that are not domain members. Stand up a packet sniffer periodically, and look for udp/5355 packets to catch any stations that might have been missed.

===============
Rob VandenBrink
Compugen

Rob VandenBrink

578 Posts
ISC Handler

Feb 22nd 2018

The big issue with disabling NetBIOs over TCP/IP is that the GUIDs are different from machine to machine, and network card to network card. So its not just as simple as running a GPO startup script, especially if your users are not local admins on their computers. It would be nice if MS would create a GPO option that would allow you to just tick off the radio button in the network card properties.

Recently in SCCM, you can now run PowerShell scripts as packages. Running the following script as a package got this cleaned up fast on all our our computers:

$adapters=(gwmi win32_networkadapterconfiguration )
Foreach ($adapter in $adapters){
Write-Host $adapter
$adapter.settcpipnetbios(2)
}

BuddyFrodis

1 Posts

That'll do the trick for Netbios over TCP (which again is not LLMNR). You can also just run that Powershell script across all domain members as admin - that's a good way to go too, as long as you have Powershell remoting enabled SCCM shouldn't be strictly required to do this.
You can kill off NBT using DHCP also: Scope Options / Advanced / Microsoft Windows 2000 Options / Vendor Class / 001 Microsoft Disable Netbios Option (change to 0x2)
The DHCP approach has the advantage of also fixing non-domain members, and the disadvantage of not working for laptops and mobile devices after they leave your network. Hitting this setting both in DHCP and in the device configuration using scripts is an effective "double tap" to fully disable NBT in both situations.

Rob VandenBrink

578 Posts
ISC Handler