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.
Feb 22nd 2018
|Thread locked Subscribe||
Feb 22nd 2018
2 years ago