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.
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. With 4 decent GPU’s, 1.7 million plus the 2 digits for one account goes pretty quick – 10 minutes does the job.
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 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 |
Sign Up for Free or Log In to start participating in the conversation!