Responder mitigation

Question

The Responder tool can grab the netntlm hashes of clients on a Microsoft AD network by either using LLMNR to answer queries "accidentally" made by clients by responding as otherwise nonexistent SMB servers, or by responding to WPAD to insert itself as a local proxy server which can require Windows authentication in order to grab the same hashes.

Can this be mitigated by requiring SMB signing by clients on the network? i.e. Would this prevent the client from sending its response to the authentication challenge because the authentication challenge wasn't signed?

I sometimes read about the mitigation being to disable LLMNR, however it seems to me that the same could then be achieved via ARP spoofing or via DNS poisoning (i.e. sending a response to clients because you are suitably positioned to view requests), albeit this would be limited to the current network segment only. Is this correct?

Answer 1

Can this be mitigated by requiring SMB signing by clients on the network? i.e. Would this prevent the client from sending its response to the authentication challenge because the authentication challenge wasn't signed?

No, according to this NCC article:

Note that while requiring SMB signing can prevent the relaying of NTLM authentication to an SMB server, it does nothing to prevent either SMB or HTTP NTLM authentication from being relayed to an HTTP server. SMB signing also does not prevent the capture and offline cracking of the NTLM challenge response.

The recommended mitigations are as follows:

• Disable Broadcast Protocols
  • NetBIOS over TCP/IP
  • LLMNR
• Network segregation
• Apply the principle of least privilege

So it appears there isn't actually a solid way to prevent hashes from being MITM'd. The above reduces the likelihood, but doesn't set the risk to zero.

Enforcing long passwords (15 characters and more) and encouraging users to select passwords based upon passphrases can help mitigate captured hashed being cracked and then used by an attacker.