Defending Against Responder.py

by Vince
in Blog
Hits: 3048

There have been plenty of articles written on Responder.py and LLMNR / NBT attacks.  A quick recap:  Essentially, computers are asking for resources, the requests are being intercepted (and poisoned), and NTLMv2 hashes are captured.

If you haven’t played with Responder.py on a network with a few dozen computers, it’s pretty amazing.  It seems to work best in the morning when people are starting up their machines.  But even then, it takes a few hours to capture some hashes.  I’ve never run it with the goal of capturing every hash but I would bet if that was your goal, it could take at least a day to get every hash.

As I mentioned previously, numerous articles have been written on how to use this tool but the question an administrator would ask is -- How do you defend against it? 

In three steps:

1.  In the Domain Group Policy:  Computer Configuration > Policies > Administrative Template > Network > DNS Client.  Set “Turn off multicast name resolution” to Enabled.  Close all of the group policy windows. 

2.  In the Domain Group Policy:  Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.  Set "Microsoft network client:  Digitally sign communications (always)" to Enabled.  Open a command prompt and execute the following:  gpudate

3.  Open the DHCP manager, expand your domain, IPv4, Scope, and select Scope Options.  Right click Scope Options, select Advanced, and select Microsoft Options under the Vendor class dropdown.  The first Available option should be “001 Microsoft Disable Netbios Option”.  Check that box, set the value to 0x2, click OK, and close the DHCP manager. 

I think it’s appropriate to mention certain caveats such as the fact that if a computer is not part of the domain, it will not receive the updated group policy.  In addition, the DHCP Scope option only applies to devices on that specific network.  To clarify that point further – if a device is off the network, at a coffee shop for example, a different DHCP server is serving different options.  Are these caveats an excuse for not implement these changes?  Of course not.  The goal is to minimize the attack surface and unless you’re running Windows 2000, this functionality is not needed and should be disabled.