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:
- Force a victim host to release its registered NetBIOS name, knocking it offline for name-based lookups (a targeted denial of service).
- Immediately register that same name themselves, so traffic that used to reach the victim now reaches the attacker — a name hijack that sets up man-in-the-middle and credential-relay follow-ons.
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:
- Pass — the value is
1; release-on-demand is refused. - Warning — the value is
0or absent. A missing key is not treated as "probably fine": because the Windows default is exposed, an absent value warns. - Warning (fail-safe) — the value could not be read. Rather than hide an unknown, the check surfaces it.
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.