Three Windows protocols turn on by default and shouldn't be. SMBv1 is the EternalBlue / WannaCry vector. LLMNR is what every internal pentest abuses for Responder hashes. NTLMv1 is broken cryptography from 1993 that Active Directory still accepts when something asks nicely.
Disabling all three is fifteen minutes of PowerShell. Do it before the server is in production. After it's in production, do it on a Saturday morning because something might break.
TL;DR:
# SMBv1 off
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
# LLMNR off (registry)
New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" `
-Name "EnableMulticast" -PropertyType DWord -Value 0 -Force
# NTLMv1 off (registry)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
-Name "LmCompatibilityLevel" -Value 5
Restart-Computer
Verify after the reboot. Details and the rare exceptions below.
This belongs in the Windows Server initial setup checklist — I do it right after creating the admin account.
SMBv1 — actually disable it
SMBv1 is the file-sharing protocol from 2000. It has no signing, no encryption, and a kernel RCE that Microsoft patched in 2017 (MS17-010) but every box still ships with the protocol stack loaded.
# Check
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
# Disable
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart
-NoRestart defers the reboot — fine if you're chaining other changes.
After reboot, verify:
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Select State
Should show Disabled. Also check the SMB server side specifically:
Get-SmbServerConfiguration | Select EnableSMB1Protocol
False. Done.
The exception: old NAS devices (Synology DSM 5.x and older), legacy printers, ancient industrial control systems. If your environment has those, you need SMBv1 somewhere — but isolate it on a dedicated VLAN with one Windows host as bridge, don't leave it on every server.
LLMNR — the multicast trap
Link-Local Multicast Name Resolution. When a Windows host can't resolve a hostname via DNS, it broadcasts "hey, anyone here called fileserver?" to the local network. Anything on the network can answer "yes that's me", and the host happily authenticates against the attacker.
Responder.py — the standard internal-pentest tool — does exactly this. Five minutes on a corp network with LLMNR enabled and you have hashed credentials of half the users.
DNS works. LLMNR is the fallback when DNS doesn't. If your network has a DNS server (it does — that's what AD ships), you don't need LLMNR.
# Group Policy registry path — works even on standalone hosts
$key = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient"
if (-not (Test-Path $key)) { New-Item -Path $key -Force | Out-Null }
New-ItemProperty -Path $key -Name "EnableMulticast" `
-PropertyType DWord -Value 0 -Force
Reboot or gpupdate /force. Verify with Wireshark — capture on UDP 5355, do a name lookup that should fail, you should see no LLMNR query leave the box.
The exception: small workgroups with no DNS server. Rare on a server. If you have a server, you have AD or at least a DNS forwarder — kill LLMNR.
You should also kill NBT-NS (NetBIOS Name Service, UDP 137) which is the same trap with older protocol packaging. NBT-NS is per-interface:
$nics = Get-WmiObject Win32_NetworkAdapterConfiguration | Where-Object { $_.IPEnabled }
foreach ($nic in $nics) {
$nic.SetTcpipNetbios(2) # 0=default, 1=enable, 2=disable
}
This survives reboots. Verify with Get-WmiObject Win32_NetworkAdapterConfiguration | Select Description, TcpipNetbiosOptions.
NTLMv1 — broken since the dial-up era
NTLMv1 uses DES with a known-weak key derivation. Captured NTLMv1 hashes can be cracked in minutes on modern GPUs. Microsoft kept it enabled for backward compatibility with Windows 2000 and earlier — a 25-year-old compatibility decision that's still defaulting on.
LmCompatibilityLevel controls what your host accepts and what it sends:
| Level | Accepts | Sends |
|---|---|---|
| 0 | NTLMv1, NTLMv2, LM | LM, NTLMv1 |
| 1 | NTLMv1, NTLMv2, LM | LM, NTLMv1 (NTLMv2 if asked) |
| 2 | NTLMv1, NTLMv2 | NTLMv1 |
| 3 | NTLMv1, NTLMv2 | NTLMv2 |
| 4 | NTLMv2 only (no LM) | NTLMv2 |
| 5 | NTLMv2 only | NTLMv2 |
Default on Windows Server is 3 — which still accepts inbound NTLMv1. Set it to 5:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
-Name "LmCompatibilityLevel" -Value 5
Reboot. Verify:
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
Should show 5.
The exception: legacy clients (Windows XP, old NAS, some printers, old VPN appliances) that can't do NTLMv2. If anything on your network needs NTLMv1, the right move is replacing the legacy device, not weakening the server. If you can't, isolate.
In a domain — do it via Group Policy
The PowerShell above works per-host. In an AD environment, push it via GPO so new joins inherit:
Computer Configuration → Policies → Administrative Templates →
Network → DNS Client → Turn off multicast name resolution: Enabled
Computer Configuration → Policies → Windows Settings →
Security Settings → Local Policies → Security Options →
Network security: LAN Manager authentication level: Send NTLMv2 only. Refuse LM & NTLM
Microsoft network server: Digitally sign communications (always): Enabled
GPO push, gpupdate /force on each member, verify.
If you're not yet on a domain, see joining a Windows Server to AD.
Verify everything in one shot
# SMBv1
(Get-SmbServerConfiguration).EnableSMB1Protocol -eq $false
# LLMNR
(Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -ErrorAction SilentlyContinue).EnableMulticast -eq 0
# NTLMv1
(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa").LmCompatibilityLevel -ge 4
All three return True, you're done. Otherwise re-check the registry path that didn't take.
What this doesn't fix
This is three checkboxes. Real Windows Server hardening is a longer list — patching cadence, account hygiene (see creating Windows users from cmd), RDP access controls (see enabling RDP from PowerShell — and then locking it down with NLA + IP allow-list), Defender ASR rules, audit logging, BitLocker.
But these three are the highest-leverage single tasks. SMBv1 disable shuts down WannaCry-class worms. LLMNR/NBT-NS disable shuts down Responder. NTLMv1 refusal forces every authentication onto modern crypto. Do them on every Windows Server you build, before the box is in production.
For physical-access recovery (the opposite problem — you locked yourself out), see Utilman password reset or the Sticky Keys variant.
