Hunting the Network for Responder and Inveigh

Objective: Detect the presence of Responder or Inveigh on the network.

Overview of Responder and Inveigh:

Responder is a tool that comes standard on Kali linux. It is used for responding to LLMNR, NBT-NS, and MDNS requests and intercepting the resulting data from the exchange. Responder can be used to gather Windows challenge hashes resulting from requests to nonexistent services or other maliciously redirected requests. Here are links for Responder on Kali’s website and github with more information. (https://www.kali.org/tools/responder/) (https://github.com/SpiderLabs/Responder)

Responder is a penetration testing tool that comes standard with Kali Linux.

According to its github, Inveigh is a cross-platform .NET IPv4/IPv6 machine-in-the-middle tool for penetration testers. The tool is used to conduct spoofing attacks and hash or credential captures through both packet sniffing and protocol specific listeners/sockets. Here is a link to the Inveigh github. (https://github.com/Kevin-Robertson/Inveigh)

Mitre Attack ID: T1557.001 — Adversary-in-the-Middle: LLMNR/NBT-NS Poisoning and SMB Relay

Task 1. Detect malicious responses and rogue authentication servers inside the network

Begin by navigating to the working folder where the detection script is located.

Here the module can be imported and the script can be run as seen below. The results show the ResponderGuard.ps1 script running and receiving NBNS responses from a non existent network device which indicates the presence of Responder or Inveigh.

Here is one indication of a malicious response from a rogue authentication server.

Another way to determine Responder or Inveigh being used on the network is by monitoring the usage of honey credentials. This is because ResponderGuard submits honey credentials to any rogue authentication server of Responder or Inveigh that is detected. By reviewing the security logs in Windows Event Viewer and checking for Event ID 4648 — A logon was attempted using explicit credentials — usage of honey credentials can be discovered.

Searching for Event ID 4648 in Event Viewer uncovers the usage of honey credentials.

HoneyUser account detected by checking for Event ID 4648.

A third way to detect Responder or Inveigh is to use the script Find-HoneyAccount.ps1 and run that script along with the ResponderGuard script. The response in the second screenshot below with the response “Honey Account Used” is another third indication of Responder or Inveigh in use.

Here the ResponderGuard script is loaded and ran.

After running the ResponderGuard script, the HoneyAccount script is ran revealing the honey account usage.

Task 2. Detect suspicious interactions with untrusted IP’s

Begin by clearing the Sysmon logs located in the Event Viewer at Applications and Services Logs > Microsoft > Windows > Sysmon > Operational. This creates clean baseline to review after the below scripts are ran. Attempting to access the network share and running the below scripts show a response to an untrusted share at 10.100.11.102.

Logs cleared for fresh baseline.

The Sysmon logs are refreshed in the Operational tab. Searching for event ID 3 in the Sysmon logs show suspicious connections on ports 445 and 5355. This is further evidence of Responder or Inveigh on the network.

Using Sysmon Event ID 3 a connection on port 445 is seen.

Using Sysmon Event ID 3 shows a connection on port 5355.

Task 3. Use PowerShell’s capabilities to detect Inveigh

Start by checking Registry Editor to ensure the configuration of ScriptBlockLogging is enabled.

Registry editor shows ScriptBlockLogging is enabled.

Now the Inveigh module is imported and the script is ran.

Inveigh script ran to emulate an attack which should show up in Powershell Operational logs.

Using Event Viewer and checking Applications and Services Logs > Microsoft > Windows > Powershell > in the Operational tab shows several warnings with the event ID 4104. The particular warning for Event ID 4104 in the Event Viewer screenshot below shows evidence of Inveigh’s LLMNR poisoning procedure.

Evidence of Inveigh’s LLMNR poisoning procedure.

In conclusion, here are the ways Responder and Inveigh were able to be detected on the network.

• CredDefense (listening for UDP-based responses when requesting a non-existing network resource)
• Honey Credentials (Security Event ID 4648 )
• Sysmon (Sysmon Event ID 3)
• PowerShell’s Script Block Logging (PowerShell Operational log — Event ID 4104)