Why is there NBNS Traffic in My Network After Disabling NetBIOS?

Quick Answers

If you’re in a heated fluster trying to find a quick answer, please see them below. If you think one may apply in your scenario, please read the rest of the article. 
  1. You need to disable NetBIOS on each machine individually. 
  2. The NBNS (NBT-NS) traffic is part of a poisoner detection mechanism of your IDR. 

Getting into it

Nothing is more frustrating than receiving a penetration retest report stating that a security vulnerability was not remediated at the time of retesting. Money, time, and reputation are all seemingly wasted when remediation attempts come up short. This is why it is especially important to ensure your security vulnerabilities, such as NetBIOS Name Service (NBNS) are fixed before retesting. 

Disabling NetBIOS is a straightforward task. The default setting of Windows hosts is to follow the NetBIOS setting defined by the DHCP server. Disabling NetBIOS from the DHCP server, in most cases, will resolve the issue. However, this is not foolproof and may not resolve the issue on all hosts. Strafe Cybersecurity recommends directly disabling NetBIOS on each host if possible. The service can be disabled on each machine via PowerShell or the GUI on the WINS tab in Advanced TCP/IP Settings. 

NetBIOS Disabled, NBT-NS, NBNS, Responder, Security Policy, GPO, DHCP

Could IDR be Responsible?

After taking this action, there should be no more NetBIOS Name Service (NBNS) traffic on the network. Before contacting your Penetration Testing service for a retest, it is important to be aware of your security implementations and their capabilities. Some incident detection & response (IDR) systems, such as Rapid7 InsightIDR, broadcast NBNS queries. These queries are an intended function of a poisoner detection feature. The IDR will issue an NBNS query to a fake hostname that does not exist on the network. If the service receives a response, it will alert that a poisoner is on the network. The service can be confident that the response is malicious because it already knows the host doesn’t exist and under normal conditions, it should not receive a response.  A penetration engineer performing a pentest or retest may identify that NBNS traffic is present on the network and mark that as a security finding. In this case, ask the penetration tester for the name of the resource being requested. If the resource is not on your network, then it is highly likely that it is simply your IDR doing its job. Ask the pentester to ping or scan the resource; if they are unable to do so, then it would be a good idea to inform them of your IDR and the poisoner detection functionality. They may require a statement from the vendor, especially in a retest scenario where they need to prove remediation had taken place. 

Understand Your Tools

With so many powerful security tools, it can be easy to lose track of all the incredible features that protect your network. Some of these protections may look like vulnerabilities but are deceiving attackers. This can be in the form of poisoner detection like we discussed in this post, or they can manifest in a different form such as honeypots or honeynets. No matter the manifestation, it is always good to have a full understanding of the tools you use to secure your network. Especially before a penetration test or retest where a lack of knowledge may result in a potentially costly false positive on a report. 

 

LET'S HAVE A TALK

Just send us a quick message explaining your situation and get our price quote shortly. We can start by testing one part of your organization and expand as we move forward.

Or we can make an extensive testing & training plan and give you an unbeatable offer!