DHCP may be famous for being an essential Windows networking protocol, but it is also infamous, or at least it should be, for falling victim to cyber attacks and leading adversaries to dangerous achievements. For a recap of common DHCP spoofing techniques and how to test your vulnerability to them, see part 1 in this blog series: DHCP Spoofing 101

On-premise poisoning techniques continue to be one of the leading mid-stage attacks used by adversaries to collect data, enable lateral movement, and perform privilege escalation after gaining an initial foothold in the network. In this post, we’ll explain some lesser-known methods for abusing DHCP in conjunction with NetBIOS settings that can open the door to extreme exploits, including EternalBlue attacks. 

Not only NTLM – the risk of enabling NetBIOS using DHCP 

You probably already know that attackers can attach malicious configuration data to DHCP responses. Typically, this means attackers will aim to set themselves as the DNS server and Default Gateway for their victims. And as if that weren’t enough, DHCP has control over other configurations as well, including the option to enable or disable NetBIOS. 

NetBIOS is a Microsoft Windows protocol that works on top of the transport layer, and provides three distinct services:

• Name service (NBNS) for name registration and resolution – UDP port 137
• Datagram distribution service (NBDGM) for connectionless communication – UDP port 138
• Session service (NBSS) for connection-oriented communication – TCP port 139

On Windows machines, the NetBIOS settings are derived from the DHCP server by default. So unless the client has a static IP address or the DHCP server doesn’t have an explicit configuration for this option, NetBIOS is enabled by default. Here’s a screenshot of the NetBIOS default settings: 

In other words, once attackers perform a DHCP spoofing attack, they can enable the NetBIOS settings and open the port group UDP 137, UDP 138, and TCP 139, thereby exposing their victim to further exploitation.

Let’s see what this might look like in a real-world example. Compare the network settings before & after a DHCP attack.

Note that after the attack, all of the following have changed: 

• DNS suffix
• IP address
• Subnet mask
• Default gateway
• DHCP server – changed to the attacker’s address
• DNS server
• NetBIOS over TCP/IP is now enabled

DHCP spoofing can open dangerous ports  

In the above example, we can see that the malicious DHCP configurations used the spoofing attack to open ports 139,138 & 137.  Compare the before & after states: 

Before:

After:

Now here’s what’s so significant about opening ports 139,138 & 137: 

For one, attackers could exploit NBNS on port 137 using open-source tools such as Responder, that respond to broadcast requests with false information, and from there the road towards credential harvesting is very short.

SMB on port 139

Another considerable risk is that attackers will exploit a host via port 139. Port 445 is often blocked by firewalls due to its popular use in exploitation techniques. A little known fact is that the SMB protocol can also be used on top of the NBSS protocol over port 139. In other words, any SMB vulnerability that can be exploited using port 445, can also be used and potentially exploited over port 139.   

For example, a machine with an open 139 port may be susceptible to an EternalBlue attack, which exploits a vulnerability in the SMBv1 protocol. We were able to validate this using Wireshark, the popular network protocol analyzer. 

Here’s a Wireshark screenshot of an EternalBlue attack executed over port 139: 

As a network administrator, it’s crucial to understand that even if you’ve blocked the use of NetBios in your network using DHCP, an attacker could use a DHCP spoofing attack to enable the NetBios settings, thus revealing your network to many unnecessary risks. 

Recommendations 

First and foremost – Firewall rules

Since you know that SMB is a highly vulnerable protocol, you probably already have a firewall rule to block its use. If you do, make sure that this rule also includes the NetBios port group – 137, 138 and 139. 

If you don’t have a firewall rule to block port 445, consider adding one and make sure to add the NetBios port group. 

Disabling NetBIOS – The right way

Group policy

Group policies don’t offer us a quick fix to block DHCP from turning on unwanted NetBIOS settings.  In fact, Microsoft does not currently offer the option to disable NetBIOS through Group Policy. Instead,  we recommend using GPO scripts to disable NetBIOS on domain clients. 

As a network administrator, you can create a GPO setting and use a bat file to run WMIC commands on local and remote computers. WMIC (Windows Management Instrumentation Command-line) is a Windows scripting interface for accessing and managing data from the Command Prompt. 

For example, this WIC command searches for all network interfaces that have NetBIOS enabled and disables them:
wmic nicconfig where (TcpIpNetbiosOptions!=Null and TcpIpNetbiosOptions!=2) call SetTcpIpNetbios 2

Registry

The registry value used to disable NetBios is dependent on the interface UUID, so it may not be as simple to manage it using GPOs. However, if you want to use the registry on a specific client, here is the value:

HKLMSYSTEMCurrentControlSetServicesNetBTParametersInterfaces<Interface_UUID>

If you go this route, you’ll need to create a new REG_DWORD value named “NetbiosOptions” and set it to 0x00000002 for each interface you want to disable.

After leading research projects in the Elite IDF 8200 unit, Yuval joined Pcysys as a Senior Security Researcher. Driven by her love for offensive cyber research, Yuval is constantly searching for new complex attack vectors.

Sources and additional reading

• https://www.techrepublic.com/blog/data-center/dns-changer-trojan-latest-variant-is-certainly-unique/
• https://isc.sans.org/diary/Rogue+DHCP+servers/5434
• https://attack.mitre.org/techniques/T1557/002/