The Short Path from DHCP Spoofing to EternalBlue
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:
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.
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 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
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:
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
Despite major investments in their security suites, organizations continue to be breached. Our Co-founder and CTO, Arik Liberzon, recently sat down with CyberNews to discuss the value of the adversarial perspective and where his inspiration from Pentera came from. Starting out, I arrived at the idea for Pentera and Automated Security Validation in a pretty...
In this post, we will examine one method of encrypting data-at-rest, specifically how to achieve Data-at-Rest Encryption for MongoDB Community Edition (CE) containers through eCryptfs. Introduction Our goal at Pentera was to implement a solution that prevents data discovery upon theft when the system is offline (e.g. if a host is stolen or someone is...
After CentOS 8 was declared end-of-life (EOL), we had to find an alternative operating system (OS) for our on-premise solution, as did many other teams and organizations. Although our deployment is container-based, we still had to prepare the groundwork for different OS areas, from security patches and network modifications to installing required packages. We had...