← All posts

NetBIOS Name-Release Attacks: How an Attacker Steals Your Computer Name

A single-packet, unauthenticated LAN attack can knock your Windows machine's NetBIOS name offline and hijack it. Here's how NoNameReleaseOnDemand stops it - and how WinSentinel audits for it.

NetBIOS over TCP/IP (NBT) is a decades-old name-resolution protocol that Windows still ships enabled on most networks. It is best known as the "NBT-NS" half of the LLMNR/NBT-NS poisoning attacks that tools like Responder abuse to harvest NTLM hashes. But NBT hides a second, quieter weakness that most hardening guides skip entirely: name-release on demand.

The attack: one forged packet, and your name is gone

When a Windows machine joins a network it registers its NetBIOS name so other hosts can find it. The NBT name service also honours the reverse operation — a Name-Release request that tells a host to give up a name it has registered. The problem is that, by default, Windows will act on a Name-Release datagram that arrives unsolicited and unauthenticated from anywhere on the local segment.

That is all an attacker on the same LAN needs. By spoofing a Name-Release datagram they can:

It pairs naturally with LLMNR/NBT-NS poisoning and rogue-WPAD: first evict the legitimate owner of a name, then answer for it. There is no authentication anywhere in the exchange, so on a flat network it is a single-packet attack.

The fix: NoNameReleaseOnDemand

Microsoft documents a machine-wide control that makes the NBT name service refuse these unsolicited release demands — accepting them only from a WINS server. It lives at:

HKLM\SYSTEM\CurrentControlSet\Services\Netbt\Parameters
    NoNameReleaseOnDemand  (DWORD)

The catch is the default. When the value is 0 or simply absent — which is the out-of-the-box state on most systems — the host will honour release-on-demand. Setting it to 1 closes the door:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Netbt\Parameters' -Name NoNameReleaseOnDemand -Value 1

The NBT driver reads this at start-up, so reboot after applying it. This is also the CIS Windows Benchmark "MSS: (NoNameReleaseOnDemand)" recommendation, so if you are chasing a CIS Level 1 baseline it is already on your list — whether or not you knew what it defended against.

The most durable mitigation is to disable NetBIOS over TCP/IP entirely where you don't need it. But on networks that still rely on NBT, NoNameReleaseOnDemand = 1 removes the release-on-demand hijack without breaking name registration.

How WinSentinel audits it

WinSentinel's Network audit now checks NoNameReleaseOnDemand as part of its single-machine posture scan, right alongside the LLMNR, NBT-NS, WPAD, ICMP-redirect, source-routing and IRDP checks. It reads the registry value and grades the posture, not the raw number, so the result is unambiguous:

Every warning ships with the exact one-line Set-ItemProperty fix above, ready to apply. Run it with:

winsentinel --audit --category Network

This is a local, single-machine check — part of the free, open-source core. If you manage a fleet, WinSentinel Pro rolls the same finding up across every node so you can see, in one view, which machines still honour NetBIOS name-release on demand and push the fix org-wide.

Why the small checks matter

Name-release-on-demand is exactly the kind of finding that never shows up on a vulnerability scan — there's no CVE, no patch, just a default that has been quietly wrong for twenty years. Those are the settings attackers count on. Auditing for them is the whole point of a posture tool: it's not about the exotic zero-day, it's about the boring registry value that turns a flat LAN into an attacker's playground.