Windows - Security - Disable Netbios Over TCP/IP

What the NetBIOS over TCP/IP disabler does

This Automox Worklet™ disables NetBIOS over TCP/IP on every IPv4 network adapter on a Windows endpoint. The script targets the legacy NBT layer that still ships enabled by default on Windows clients and servers. The Worklet writes the registry value that tells the NetBT driver to skip NBT-NS broadcasts, NBT datagram delivery, and NBT session services on each interface.

The Worklet edits the registry under HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\. That key contains one Tcpip_<adapter-GUID> subkey for each bound IPv4 adapter on the endpoint, including physical NICs, Wi-Fi radios, VPN tunnels, and hypervisor virtual switches. Inside each subkey, the NetbiosOptions DWORD controls the NBT mode: 0 means follow the DHCP-supplied value, 1 means enabled, and 2 means disabled. The Worklet sets the value to 2 on every adapter so no interface remains exposed.

The script is idempotent. The evaluation phase reports compliant when every adapter subkey already holds NetbiosOptions = 2 as a REG_DWORD. The remediation phase opens each subkey with write access, calls SetValue with RegistryValueKind.DWord, and closes the handle. The NetBT driver picks up the change on the next bind, so the endpoint stops responding to NBT-NS broadcasts without a reboot.

Why disable NetBIOS over TCP/IP

NBT-NS is a credential-leak channel that almost no modern Windows network needs. When a workstation cannot resolve a hostname through DNS, it falls back to broadcasting an NBT-NS query on the local subnet. Any host that answers becomes the resolver, including an attacker running Responder, Inveigh, or NBNSpoof. The victim's NTLMv1 or NTLMv2 challenge-response is sent to the attacker, who replays it against another server or cracks it offline with hashcat. CIS Microsoft Windows Benchmarks call out NetBIOS disablement as a baseline hardening control, and MITRE catalogs the technique as T1557.001 (LLMNR/NBT-NS Poisoning and SMB Relay).

This Worklet writes NetbiosOptions=2 to HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_* on every adapter on every Windows endpoint in scope, which is the registry control plane behind the NetBIOS over TCP/IP setting in the IPv4 adapter properties. The remediation iterates every TCP/IP interface key, so adapters added by a VPN client, a virtual switch, or a new Wi-Fi profile pick up the same value. A subsequent in-place upgrade that re-enables NBT on a fresh adapter surfaces in the next evaluation rather than going unnoticed.

How NetBIOS disablement works

1. Evaluation phase: The script opens the 64-bit registry view on 64-bit Windows (Registry32 on 32-bit), then opens HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\. It enumerates every Tcpip_<adapter-GUID> subkey, reads the NetbiosOptions value and its RegistryValueKind, and confirms the value is 2 and the type is DWord. Any adapter that is missing the value, holds 0 (DHCP), or holds 1 (enabled) flags the endpoint non-compliant. The script writes "Endpoint is not compliant with the desired registry configuration." to the activity log and exits 2 so Automox schedules remediation.

2. Remediation phase: The script reopens the Interfaces key with write access, walks the same adapter-GUID subkeys, and calls SetValue('NetbiosOptions', 2, RegistryValueKind.DWord) on each writable subkey using the .NET Microsoft.Win32.RegistryKey API. Each subkey is closed after the write, and the script logs "Set NetbiosOptions to 2 in <subkey>" per adapter. The NetBT driver re-reads the value on the next interface bind, so NBT-NS, NBT datagrams, and NBT sessions stop being offered on that adapter without restarting the endpoint. Any registry exception triggers Write-Error and a non-zero exit; the success path writes "Endpoint is compliant with the desired registry configuration." and exits 0.

NetBIOS disablement requirements

• Windows 10, Windows 11, Windows Server 2016, 2019, 2022, or 2025 with the NetBT driver enabled (default on every supported SKU)

• SYSTEM-level execution context (the Automox agent default) so the script can open HKLM with write access

• DNS infrastructure that resolves the hostnames the endpoint actually needs, including domain controllers, file servers, and print servers; once NBT-NS is off there is no fallback resolver on the local subnet

• No surviving NetBIOS-only applications (legacy SMB1 file shares accessed by NetBIOS name, WINS-only print servers, very old line-of-business clients); confirm with a pilot ring before fleet rollout

• Optional companion Worklets to disable LLMNR (HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast = 0) and mDNS to close the parallel name-resolution poisoning paths

Expected NetBIOS state after remediation

After the Worklet runs, every Tcpip_<adapter-GUID> subkey under HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\ holds NetbiosOptions = 2 (REG_DWORD). The endpoint stops listening on UDP 137 (NBT-NS), UDP 138 (NBT datagram), and TCP 139 (NBT session) on each affected adapter. Running nbtstat -n returns no registered NetBIOS names. Get-NetAdapterBinding -ComponentID ms_netbt reports the binding as disabled per adapter, and the WMI query Get-CimInstance Win32_NetworkAdapterConfiguration | Select-Object Description, TcpipNetbiosOptions shows TcpipNetbiosOptions = 2 for every IPv4 binding.

Validate the effect end-to-end by running a Responder pilot from an isolated host on the same VLAN before and after the policy run; the post-run capture should show no NBT-NS responses from any remediated endpoint. The next Automox evaluation reports the endpoint compliant and applies no remediation, which is the steady-state signal that the policy is holding. If a future Windows feature update, network driver reinstall, or new VPN adapter reintroduces NetbiosOptions = 0 or 1 on a fresh interface, the next evaluation catches the drift and reapplies the value with no admin involvement.