Blue Teaming - Defending Against Responder.py

Oh no, we at it again! #

Alright then


Isn’t it just nice that when you plug in your PC to the network, it can start discovering your local printers, shares and even other workstations? Yea, your red team thinks so, too.

During a pentest engagement, one easy thing to have running in the background is Responder. Formally maintained by SpiderLabs, now by lgandx, Responder is a project based off python to poison LLMNR, NBT-NS and MDNS requests within a network.

What makes Responder so effective, and so dangerous, is when a user either types in a server name incorrectly, or more commonly does a Google search straight from the URL bar of their web browser (come on, we all do it). Your PC will first check its local DNS server for an address, and if nothing was found it’ll then do a local LLMNR and NetBIOS Server Name Broadcast, which an attacker’s PC will be listening for via Responder. When a computer receives a response from a host running Responder, the PC ends up giving out its NTLM hash, which can be crack offline, via something like hashcat. Below is an excellent workflow of the process, straight from the Kali forms

2020-01-11 15_44_11-Clipboard.png

Example of NTLMv2 hashes that were given up by a target, which again, can be cracked offline at the attacker’s leisure.

nope.png


Explain Like I’m 5? #

Basically, an attacker can run a small python script that’ll sit and wait for your domain joined workstations to give up their Active Directory password hashes, leading to bad things.


What can we do?! #

fixitfixit

There are several steps we can take to combat the effectiveness of Responder:

  1. Have effective anti-virus
    An effective anti-virus can natively block LLMNR and NetBIOS Server Name broadcast requests, thus preventing credential harvesting. This is something I learned/stumbled upon during an Incident Response (IR) engagement. We were implementing Symantec Endpoint Security and I noticed a log entry blocking LLMNR requests, so this product for sure has the capabilities and I would imagine that other AV products can do the same. As far as I have been able to find, Windows Defender does not have this capability. Your best best is to invest in a good AV vendor solution.

  2. Good Ol’ Group Policy
    Yup, there are several policies you can enable to further protect domain joined computers. You will need to disable LLMNR and WPAD (Automatic Proxy Confguration). We’ll cover the steps below.

  3. Disable NetBIOS Broadcast
    If you’re running your own DHCP server on Windows, then this is as simple as checking a box. However, if you are not using Windows Server to host DHCP, then you’ll have to push out a PowerShell script by, you guessed it, Group Policy, to disable this setting on your hosts. We’ll go over both options below.


Remediation #

Disable LLMNR #

To disable LLMNR, drill down to the following GPO settings and enable “Turn off multicast name resolution”:

llmnr1.png

llmnr2.png


Disable WPAD #

Now this one threw me for a loop for a little bit. I kept finding guides instructing me to enable a User policy to disable WPAD, but could never get it to work on my Windows 10 hosts. I finally stumbled across a random thread instructing to push out a new registry key, via Group Policy Computer Preferences, which ended up working! Registry key needs to have the following values:

reg1.png

reg2.png

Disable NetBIOS Broadcast #

There are two ways we can do this, either in our DHCP settings if we are using Windows Server to provide DHCP services, or by pushing out a PowerShell script to our domain joined workstations

Windows Server DHCP Settings #

Simply drill down to your scope options and enable “Microsoft Disable Netbios Option” and set the value to 0x2:

dhcp1.png

dhcp2.png

PowerShell #

If you’re one of those sad sacks that either don’t have control over your DHCP server, or are not using Windows Server for DHCP (perhaps a firewall/gateway appliance), you still can disable NetBIOS Broadcast by pushing out a PowerShell script that will disable it on all of the interfaces on a workstation:

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"

Get-ChildItem $regkey |foreach { Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2}

Push this out via a computer startup script so it runs under the context of the local SYSTEM user. It will require a reboot of the workstation to kick in, so don’t expect instant results.


That’s about it. I need to be better about using this thing. I’ve got a bunch of topics I want to cover in this blog, but there is only so much time in a day.
Until next time <3

Cheers

 
9
Kudos
 
9
Kudos

Now read this

Import BIND zones to Azure DNS

One of my customers was using BIND to handle their public facing DNS. In a effort to remove technical debt, minimize their infrastructure footprint, and to make it easier for staff, I was tasked to look for a cloud alternative to BIND... Continue →