It is nearly 2024, and broadcast protocols and lack of SMB signing are still default settings on Microsoft Windows hosts. This means the classic technique of broadcast traffic poisoning to relay Net-NTLMv2 via SMB is still a viable way to gain a foothold on an internal network. However, some Endpoint Detection and Response packages (EDRs) and Network Administrators have caught on and now use honeypot LLMNR and NBT-NS requests to identify and alert on broadcast poisoning attacks! The purpose of this blog post is to detail common tools used to set up honeypot broadcast requests and to detail how to identify these bait requests to continue poisoning broadcast traffic undetected.
Several technologies can be used to detect broadcast protocol poisoning. The basic premise is to issue fake LLMNR and NBT-NS requests that should not receive any legitimate answers, as the requested resources do not exist. Any host that does answer the bait requests is assumed to be performing a malicious broadcast protocol poisoning attack and should be alerted on.
This type of detection could be performed from a dedicated single server on each subnet, but then it is more readily identifiable by attackers. There are several open-source projects that can be used to implement this type of honeypot. Praetorian details a strategy to run a small PowerShell script from a variety of endpoints that requests and logs LLMNR and NBT-NS responses (1). This is effective because to an attacker it looks like legitimate broadcast requests coming from multiple endpoints, and requests can be configured to match the naming convention of the company’s resources to further blend in. Using this method and disabling all legitimate broadcast protocol traffic is a highly-effective layered defense that prevents the attack, and also alerts defenders to the presence of any attackers attempting to poison traffic.
Running the default Praetorian PowerShell script from 192.168.0.149 results in the following output in Responder:
Running Responder without Analyze mode poisons the request, and the Praetorian PowerShell script logs the activity in the specified log file as well as in the script console:
This tool creates local log files (by default in C:\tmp\poisoning.csv) that are required to be forwarded to a Security Incident and Event Management (SIEM) tool or log investor for alerting. Additionally, it has options to configure a list of hostnames to be randomly chosen, as well as the time between requests and a “jitter” to randomize the timing:
$logfile = 'C:\tmp\poisoning.csv'
$requestHosts = @('CORP-TX-FILE-01','COPY-NY-DC-02') #False hostnames to request
$interval = 30 #The minimum number of seconds to wait between requests
$jitter = 30 #The maximum value for a random number of seconds to add to the intervalConveigh (2) is another PowerShell tool that can be used to similar effect. The default settings will send randomly named LLMNR and NBNS requests at an interval between 2-30 minutes. I sped this up to send requests every 1-2 minutes for demonstration:
These show up in Responder looking like this:
Conveigh can also be configured to randomly choose a set of hostnames to blend in with the naming convention of an environment:
This lends credibility and makes it more difficult to identify the requests as fake by attackers:
File output can be enabled on Conveigh as well to log to a file using the -fileOutput flag, which can then be ingested by an SIEM:
Vindicate (3) is another open-source broadcast poisoning detection tool written in C#:
The default setting uses individual static names “ProxySvc” for LLMNR and “WPAD-PROXY” for NBT-NS requests:
These can be configured to blend in with the environment’s host naming convention:
.\VindicateCLI.exe -v --mdns-lookup testsql.test.lab --llmnr-lookup filesrv1.test.lab -eThis tool is meant to be run as a service and will output results to event logs. The SIEM will need to be configured to alert on these custom events (see the Vindicate Github page for how to configure this).
CanaryPi (4) is another tool used for Broadcast Protocol honeypot-style detections. It is in Alpha stage and therefore was not tested for this blog post. It uses randomly generated names for the bait requests by default.
Symantec Endpoint Protection also includes options for this type of detection and performs fake LLMNR and NBT-NS requests from the endpoints themselves to make them look legitimate. This is a sample excerpt from Responder in Analyze Mode on a network with Symantec Endpoint Protection broadcast poisoning detections:
The downside of this method is that the requested names are easily identifiable as random strings. I’m not sure if it is possible to modify the names to blend into the environment, as I did not have a test instance to experiment with. If this method could be configured to blend in, it is highly effective because the requests are initiated from actual workstations.
I was not able to test this, but Fortinet’s FortiEDR claims to have detections for these types of attacks (5).
I was not able to test this, but Rapid7 InsightIDR (6) claims to have detections for these types of attacks. One note about InsightIDR is that apparently it is configured to detect Responder poisoning, but may not work to detect Inveigh (7). This would be an interesting topic for further research.
The basic premise of bypassing these detections is to monitor broadcast traffic (e.g., using Analyze mode in Responder) to determine which broadcast requests are legitimate and which ones are bait, then only poison the legitimate ones. This requires two conditions:
The following is a list of hints to help with identifying bait broadcast traffic:
Vindicate uses the following default names for broadcast requests:
Note the below screenshot from Responder-Session.log has the same two requests sent every 10 seconds exactly (bait requests are from Vindicate):
Alright, let’s say you have identified some legitimate broadcast traffic and have a list of request names and IP addresses that you suspect are serving bait requests. Now you just need to respond to the legitimate requests and ignore the bait requests! The three common tools for poisoning broadcast requests all have options to filter on IP addresses or request names either via allowlist or denylist.
To configure Responder (8) to ignore or respond to certain names or IP addresses, modify Responder.conf (the default location is /etc/responder/Responder.conf):
; Specific IP Addresses to respond to (default = All)
; Example: RespondTo = 10.20.1.100-150, 10.20.3.10
RespondTo = 192.168.0.149
; Specific NBT-NS/LLMNR names to respond to (default = All)
; Example: RespondTo = WPAD, DEV, PROD, SQLINT
;RespondToName = WPAD, DEV, PROD, SQLINT
RespondToName =
; Specific IP Addresses not to respond to (default = None)
; Example: DontRespondTo = 10.20.1.100-150, 10.20.3.10
DontRespondTo =
; Specific NBT-NS/LLMNR names not to respond to (default = None)
; Example: DontRespondTo = NAC, IPS, IDS
DontRespondToName = ISATAPInveigh (9) has the following options to ignore or respond to only certain requests based on name or IP address:
.PARAMETER SpooferHostsIgnore
Comma separated list of requested hostnames to ignore when spoofing with LLMNR/mDNS/NBNS.
.PARAMETER SpooferHostsReply
Comma separated list of requested hostnames to respond to when spoofing with LLMNR/mDNS/NBNS.
.PARAMETER SpooferIPsIgnore
Comma separated list of source IP addresses to ignore when spoofing with LLMNR/mDNS/NBNS.
.PARAMETER SpooferIPsReply
Comma separated list of source IP addresses to respond to when spoofing with LLMNR/mDNS/NBNS.
Pretender (10) also has the “spoof” and “don’t-spoof-for” options to filter on names:
pretender -i eth0 --spoof "testsql.test.lab" --dont-spoof-for "CORP-TX-FILE-01,COPY-NY-DC-02"Broadcast protocols like LLMNR, NBT-NS, and mDNS are still commonly found in internal networks and are still enabled by default even on recent Windows versions. There exist several robust and relatively simple-to-install tools that make it possible to detect broadcast poisoning.
Defenders should make sure their broadcast poisoning honeypot meets the following criteria:
When these detection tools are configured and implemented correctly, they are nearly impossible to fingerprint as bait requests. However, if the above criteria are not satisfied, attackers may be able to identify and filter the bait requests. If legitimate broadcast traffic still exists, this allows them to fly under-the-radar and potentially obtain a foothold on the network via broadcast poisoning. This honeypot broadcast traffic technique in conjunction with effective Group Policy settings to disable legitimate broadcast traffic should be implemented on all internal networks for optimum security.
Cyber Advisors specializes in providing fully customizable cyber security solutions & services. Our knowledgeable, highly skilled, talented security experts are here to help design, deliver, implement, manage, monitor, put your defenses to the test, & strengthen your systems - so you don’t have to.
Read more from our technical experts...