(Attempting) to Detect Responder with Sysmon

If you've ever worked at company that has had a Penetration test performed, or have performed a pen test yourself, you have likely come across a tool called Responder.

Responder can be found here: https://github.com/lgandx/Responder - a short description is also available there.

At the most basic level, Responder does exactly what it says: "Responds"

There are various servers built in, and when a computer on the network attempts to request a resource, it gets its answer from the attacker running Responder.

For some more information, check out this link: https://www.trustwave.com/Resources/SpiderLabs-Blog/Top-Five-Ways-SpiderLabs-Got-Domain-Admin-on-Your-Internal-Network/

So, why is Responder dangerous? Well, let's say a user is browsing for a share, and mistypes this information while an attacker is running Responder on a network:

Responder then intercepts this request, pretending to be an SMB server, and grabs the hash for the user that mistyped this share:

An attacker can now grab this hash and crack it, or do some other interesting things like "Passing the Hash"

Responder is notoriously difficult to detect on a network as it's fairly stealthy.

I've seen some talks where people have used various methods to detect Responder's activity, like spraying fake credentials on the network and watching for their use ( https://github.com/Ben0xA/PowerShellDefense ).

A network Intrusion Detection System may also be able to pick up Responder traffic by analyzing packets and determining that a certain response was invalid.

There is, however, another way.

I previously wrote about an awesome tool called Sysmon. Sysmon has the ability to tell you when your computer makes a network connection - so what if we intentionally browse for a non-existent share, and then keep an eye out for who Responds ?

Here's the basic network overview of the scenario outlined above:

Domain Controller: 192.168.1.142

Attacker: 192.168.1.15

Victim: 192.168.1.128

In this scenario, as with the scenario above, the victim (192.168.1.128) browses to a non-existent file share. The attacker (192.168.1.15) responds.

Sysmon saw this activity - but it's a bit hard to spot why it's nefarious:

You can see our victim made a connection with the attacking machine (192.168.1.105) over port 445 (SMB).

For a defender to notice something is wrong, they would need to know that 192.168.1.105 is not a legitimate file server or domain controller.

One way to add some smarts to this is with PowerShell:

Import-Module C:\Users\Administrator\Downloads\Get-WinEventData.ps1

Set-Location \idontexistpc\sharenotthere -ErrorAction SilentlyContinue

$EventsID3 = Get-WinEvent -FilterHashtable @{logname="Microsoft-Windows-Sysmon/Operational";id=3} | Get-WinEventData | select EventDataDestinationPort, EventDataDestinationIp

foreach($Event3 in $EventsID3){

if(($Event3.EventDataDestinationPort -eq 445) -and ($Event3.EventDataDestinationIp -notcontains "192.168.1.142")){

Write-Host "SMB Response Sent to Untrusted": $Event3.EventDataDestinationIp

}

}

This little script does a few things.

First, it browses to non-existent share. This is designed to generate an event to which Responder will respond to.

Second, the script grabs and parses out all the Sysmon Event ID 3 (Network Connect) logs.

Finally, the script loops through these logs, and if it finds a destination port of 445 (SMB) and the destination IP is not our domain controller, then it writes a message out.

Here's what it looks like when ran:

The script can be expanded to include multiple IPs or to include port 139 (NetBIOS) as well.

The idea would be to install this script as a scheduled task, running every 10 minutes or whatever you choose on some unused PC on your network. The script will continually try to reach out to a share that you know does not exist, and will alert you when something (ie: Responder) answers. Pretty simple....

A few notes:

• Take a look at Laurent Gaffie (creater of Responder) blog here: http://g-laurent.blogspot.ca/ - I believe he is now taking monetary contributions for his work, so please support him if you find Responder useful.

• The script and techniques outlined above are NOT meant to be a comprehensive defense against Responder or another "Man in the Middle" type tools. Things like properly placed and configured IDS and disabling of legacy protocols like NetBIOS over TCP/IP are much better solutions. This method is just another layer in your defenses - it is not a silver bullet.

• Some other useful links:

https://www.trustedsec.com/july-2013/wpad-man-in-the-middle-clear-text-passwords/

https://www.praetorian.com/blog/broadcast-name-resolution-poisoning-wpad-attack-vector