A natural question that arises after an organization experiences a BNRP attack is “How can this be prevented?” The answer is simple on paper. To completely mitigate the risk, legacy Broadcast Name Resolution protocols should be disabled by policy. This is easier said than done, especially on large networks where the necessary data flows of legacy systems and applications are not well understood. This uncertainty creates a period of anxiety as an organization prepares to address this risk. To make matters worse, many traditional compensating controls provided by host and network detection are either inconsistent or non-existent in the environment.
In simple terms, BNRP is a technique used by attackers to fool hosts on the same broadcast domain into interacting with the attacker rather than the intended destination. To accomplish this, the attacker will respond to some or all LLMNR and NBT-NS requests as the authoritative source. Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are Microsoft Windows components that serve as alternate methods of host identification. LLMNR is based upon the Domain Name System (DNS) format and allows hosts on the same local link to perform name resolution for other hosts. NBT-NS identifies systems on a local network by their NetBIOS name. As defenders, we can use this behavior to our advantage. If we inject LLMNR and NBT-NS requests for hosts that don’t exist in different subnets, we should expect our requests to go unanswered. However, if an attacker is present and spoofing name resolution responses, we can expect to receive an answer for the attacker’s address.
The benefits of this approach are twofold: Defenders are alerted to attackers’ presence at the earliest stages of compromise, and the attacker’s foothold is exposed simply by responding to the broadcast name resolution requests. The MITRE ATT&CK page for BNRP references a tool called Conveigh as an example of a LLMNR/NBT-NS spoofing detection tool. However, Conveigh has not been actively developed since 2016 and advanced attackers have been quick to discover irregularities in the way it simulates broadcast name resolution requests. Another approach is to simply introduce real LLMNR and NBT-NS requests using PowerShell on a random sample of hosts in different subnets. The following script may be used as a template for this type of trap:
$logfile = 'C:tmppoisoning.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 interval
while($true){
Start-Sleep ($interval + (Get-Random ($jitter + 1)))
try {
$ErrorActionPreference = 'stop'
$request = Get-Random $requestHosts
$ipAddr = (Resolve-DnsName -LlmnrNetbiosOnly -Name $request).IPAddress.tostring()
$ErrorActionPreference = "continue"
$event = [pscustomobject]@{
date = Get-Date -format o
host = $env:COMPUTERNAME
request = $request
attacker_ip = $ipAddr
message = "LLMNR/NBT-NS spoofing by $ipAddr detected with $request request"
}
Write-Output $event.message
$event | Export-Csv -Path $logfile -Append -NoTypeInformation
} catch [System.Management.Automation.RuntimeException],
[System.ComponentModel.Win32Exception] {
#Suppress output of timeout errors
} finally {
$ErrorActionPreference = "continue"
}
}
This script takes a log file, a list of hostnames, and an interval. When executed, it will run continuously and broadcast LLMNR, MDNS, and NBT-NS requests for the hostnames specified in $requestHosts. Any responses will be captured and logged both on the console and in the file specified by $logfile.
The most important aspect of this script is the $requestHosts array. When preparing to deploy a BNRP trap, ensure the requested hosts match the naming convention of the organization. These hostnames should also not exist. This will allow the script to accurately log spoofed responses from an attacker. The next critical piece is deployment. The most fruitful areas to prioritize this effort are subnets where an attacker is likely to gain a foothold. This includes user subnets and internet-facing DMZs.
The best way to discover this activity at scale is to run this script on at least one host in each network segment. To ensure any BNRP attacks are discovered immediately, forward the log specified in $logfile to your primary SIEM and configure a high-priority alert for all events. The log will record the attacker’s IP and the request to which the attacker responded.
Organizations should use a comprehensive approach to address the risk posed by legacy name resolution protocols. Creative threat hunting and detections can be effective compensating controls as organizations plan strategic mitigations. The detections engineered when hunting for BNRP attacks benefit organizations long after LLMNR and NBT-NS have been phased out, especially in network segments where these protocols are necessary for business-critical systems. As an added benefit, this technique will continue to catch less skilled attackers who may not know broadcast name resolution protocols have been phased out in the environment.
