Cleaning Up Risky Traffic, A Mini Series: NBNS

To view other posts in this mini series, select the tag “Cleaning Up Risky Traffic, A Mini Series”

Cleaning Up Risky Traffic, A Mini Series: NBNS

NetBIOS Name Service (NBNS) is an old protocol that was designed for early versions of Microsoft Windows to provide a naming service for NetBIOS-over-TCP/IP (NBT) network communication. NBNS works by resolving NetBIOS names to IP addresses. It is used primarily in small to medium-sized networks that don’t have a DNS infrastructure. NBNS is a legacy protocol that has many vulnerabilities and can be used by attackers to gain unauthorized access to a network.

In this article we will review what NBNS is, what controls can be implemented to prevent compromise, a list of MITRE Tactics and CVE’s associated with NBNS, and we’ll set up a honeypot to detect for this attack vector.

When a Windows computer needs to communicate with another computer on the same network, it first checks its local cache for the IP address associated with the NetBIOS name. If the IP address is not found in the cache, the computer sends a broadcast message to all computers on the network, asking for the IP address of the computer with the specified NetBIOS name.

This broadcast message can be intercepted by attackers who can then respond with a fake IP address. The Windows computer will then cache the fake IP address and send all future traffic intended for the legitimate computer to the attacker’s machine. This type of attack is known as an NBNS poisoning attack.

However, NBNS can be exploited by attackers to compromise a system in a number of ways, such as:

1. Name Spoofing: An attacker can spoof the NetBIOS name of a legitimate system to trick users into connecting to a malicious system instead. This can be used to steal sensitive information or to launch further attacks. MITRE Tactic: Deception (T1140) MITRE Link: https://attack.mitre.org/tactics/TA1140/
2. Man-in-the-middle (MITM) attacks: Attackers can use NBNS to carry out MITM attacks by spoofing the NetBIOS name of a legitimate system and intercepting the traffic between the two systems. MITRE Tactic: Man-in-the-middle (T1557) MITRE Link: https://attack.mitre.org/tactics/TA1557/
3. Denial of Service (DoS) attacks: NBNS can be used to launch DoS attacks by flooding a system with a large number of NBNS requests, causing the system to become unresponsive or crash. MITRE Tactic: Resource Exhaustion (T1499) MITRE Link: https://attack.mitre.org/tactics/TA1499/
4. SMB Relay attacks: SMB Relay attacks use NBNS to intercept SMB authentication requests and relay them to another system, allowing the attacker to gain access to the target system. MITRE Tactic: Exploitation for Credential Access (T1212) MITRE Link: https://attack.mitre.org/tactics/TA1212/
5. Information Gathering: NBNS can also be used to gather information about a target system, such as its NetBIOS name, IP address, and MAC address. This information can be used to launch further attacks against the system. MITRE Tactic: Reconnaissance (T1592) MITRE Link: https://attack.mitre.org/tactics/TA1592/

To protect against NBNS-related attacks, it is important to disable NetBIOS over TCP/IP on systems where it is not needed, and to implement network segmentation and access control to limit the exposure of critical systems to potential attacks. Additionally, using modern authentication and encryption protocols such as SMBv3 and Kerberos can help to mitigate the risks associated with NBNS.

NBNS is commonly referred to as T1557.01 on the Mitre ATT&CK framework.

T1557.01 is a technique on the Mitre ATT&CK framework that refers to the use of LLMNR/NBNS poisoning and SMB relay attacks to gain initial access to a network. Additionally, there are several CVEs related to LLMNR that have been discovered over the years, and it’s important for organizations to stay up to date on these vulnerabilities to ensure their networks remain secure.

Here are some CVEs (Common Vulnerabilities and Exposures) related to NBNS (NetBIOS Name Service):

1. CVE-1999-0524 – Denial of Service vulnerability in Windows NT 4.0 allows remote attackers to cause a denial of service (crash) via a flood of NetBIOS Name Service (NBNS) packets.
2. CVE-1999-0478 – NetBIOS Name Service (NBNS) vulnerability in Windows 95 and Windows 98 allows remote attackers to cause a denial of service (crash) via a flood of NBNS packets.
3. CVE-1999-0490 – NetBIOS Name Service (NBNS) vulnerability in Windows 95 and Windows 98 allows remote attackers to cause a denial of service (crash) via a flood of NBNS packets containing a “*” character in the name field.
4. CVE-2001-0054 – The NetBIOS Name Service (NBNS) in Microsoft Windows 2000 allows remote attackers to cause a denial of service (hang) via a flood of NBNS Name Release packets.
5. CVE-2002-0040 – The NetBIOS Name Service (NBNS) in Microsoft Windows NT 4.0 allows remote attackers to cause a denial of service (hang) via a flood of NBNS Name Release packets.
6. CVE-2002-1222 – Buffer overflow in the NetBIOS Name Service (NBNS) in multiple Microsoft Windows operating systems allows remote attackers to execute arbitrary code via a long NBNS response.
7. CVE-2003-0817 – The NetBIOS Name Service (NBNS) in Microsoft Windows NT 4.0, 2000, XP, and Server 2003 allows remote attackers to cause a denial of service (CPU consumption and system hang) via a flood of NetBIOS Name Query Request packets.
8. CVE-2006-3439 – The NetBIOS Name Service (NBNS) in Microsoft Windows 2000 SP4, XP SP1 and SP2, and Server 2003 SP1 and earlier allows remote attackers to execute arbitrary code via a crafted NBNS response.

Note that this is not an exhaustive list, and there may be other CVEs related to NBNS that have not been included.

Testing and Verification

Checking if NBNS is in your environment is easy! Wireshark can be used to capture NBNS traffic and analyze it for potential vulnerabilities. It is important for organizations to regularly test and verify their mitigation strategies to ensure they are effective against new and evolving threats.

To detect NBNS traffic using Wireshark, you can use the following display filter:

udp.port == 137 || udp.port == 138

Once the filter is applied, you should be able to see all NBNS traffic in the captured packets. This can help you identify any potential NBNS-related issues or attacks on your network.

Mitigation Strategies

Disabling NBNS is easy, a simple GPO is all you need! Follow these steps to disable NBNS:

1. Open the Group Policy Management Console (gpmc.msc).
2. Create a new GPO, or edit an existing one.
3. Navigate to Computer Configuration > Administrative Templates > Network > DNS Client.
4. Double-click “Turn off NetBIOS over TCP/IP” to open the policy settings.
5. Select “Enabled” to turn off NBNS.
6. Click “OK” to save the policy settings.
7. Link the GPO to the appropriate organizational unit (OU) or domain.

Once the GPO is applied, NBNS will be disabled on all computers within the scope of the GPO.

Honeypots!

Setting up a honeypot for NBNS can help you detect and monitor any attempts to exploit NBNS-related vulnerabilities or attacks. Here is a basic honeypot setup you can use for NBNS:

1. Set up a virtual machine: You can set up a virtual machine (VM) on your network that runs a vulnerable version of Windows with NBNS enabled. This VM will act as the honeypot for NBNS-related attacks.
2. Disable unnecessary services: To limit the attack surface of the honeypot, disable any unnecessary services or applications that are not required for NBNS functionality.
3. Monitor traffic: Use a network monitoring tool such as Wireshark to monitor traffic to and from the honeypot. Filter the traffic to show only NBNS traffic by using the display filter “udp.port == 137 || udp.port == 138”.
4. Set up alerts: Set up alerts to notify you when any NBNS-related activity is detected on the honeypot. You can use tools such as Snort or Suricata to create custom rules that trigger alerts based on specific network traffic patterns or signatures.
5. Log all activity: Log all activity on the honeypot to track any potential attacks or suspicious behavior. This can help you identify attack patterns and determine the severity of any attempted attacks.
6. Regularly review and update: Regularly review the logs and alerts generated by the honeypot to identify any new attack patterns or vulnerabilities. Use this information to update your security measures and defenses.

Note that honeypots can attract malicious actors, so it’s important to ensure that the honeypot is isolated from the rest of your network and that appropriate security measures are in place to protect your network and data.

Vulnerability Scanners and ‘Informational’ Vulnerabilities

You’ll notice on your vulnerability scanner (Nessus, Rapid7, etc.) that NBNS and many other multicast traffic controls show up as a ‘low’ or ‘informational’ vulnerability. My assumption is that it scores this as Informational because NBNS is not technically a “vulnerability” (assuming devices are patched). Meaning the software itself works as designed… There is no patch needing to be installed to make it secure.

It’s kind of like standing up an FTP server and allowing anonymous logins with full access. It’s a bad idea, but I wouldn’t expect a vulnerability scanner to scream about it unless you are running an FTP server with a known vulnerability.

In a vendor-centric world, a real internal conversation to be had at most orgs is about not hinging one’s security practices squarely on compliance requirements and/or “best practices” (present company included). Don’t count on 3rd party tools to make you secure. If they did, then we wouldn’t see breaches every week. I just recently learned more about maturity models, which are models that scan across multiple secure frameworks (NIST, PCI, GDPR, HIPAA and more) to look for overlapping controls that actually make a difference. check out SCF — Secure Controls Framework.

https://securecontrolsframework.com/

https://securecontrolsframework.com/capability-maturity-model/

Conclusion

In conclusion, NBNS is a legacy protocol that has many vulnerabilities and can be used by attackers to gain unauthorized access to a network. By disabling NBNS, utilizing alternative protocols such as DNS, and implementing network segmentation and endpoint detection and response, organizations can help to protect their networks and sensitive information. It is important for organizations to regularly test and verify their mitigation strategies to ensure they are effective against new and evolving threats.

For more information about this security control, feel free to reach out to blog@tridentstack.com. For professional services around this configuration, professionalservices@tridentstack.com, and lastly, for a full service SIEM/SOC/SOAR tool we highly recommend you check out our home page: https://tridentstack.com