> ## Content Index > Fetch the complete content index at: https://blog.sudowl.com/llms.txt > Use this file to discover other available public pages before exploring further. # Windows Server Hardening — Kill SMBv1, LLMNR, and NTLMv1 - URL: https://blog.sudowl.com/windows-server-disable-smbv1-llmnr-ntlmv1/ - Published: 2026-05-05T10:00:00.000Z - Updated: 2026-10-11T08:47:37.000Z - Description: Three legacy protocols still enabled by default on Windows Server that no modern network needs. PowerShell one-liners to disable each, the rare exceptions, and how to verify. - Author: Lukas - Tags: Windows Server, Security 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:** ```powershell # 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](/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. ```powershell # 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: ```powershell Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Select State ``` Should show `Disabled`. Also check the SMB server side specifically: ```powershell 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. ```powershell # 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: ```powershell $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: ```powershell Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" ` -Name "LmCompatibilityLevel" -Value 5 ``` Reboot. Verify: ```powershell 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](/join-windows-server-ad-domain-powershell/). ## Verify everything in one shot ```powershell # 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](/create-windows-user-cmd-net-user/)), RDP access controls (see [enabling RDP from PowerShell](/enable-rdp-windows-server-powershell-cmd/) — 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](/reset-forgotten-windows-admin-password-utilman/) or the [Sticky Keys variant](/windows-password-reset-sticky-keys-sethc/). --- ### Related posts - [BitLocker on Windows Server — Encrypting the OS Volume Without Locking Yourself Out](https://blog.diengdoh.com/bitlocker-windows-server-os-volume/?ref=blog.sudowl.com) - [Active Directory Part 3 — GPO Hardening for the Whole Domain](https://blog.diengdoh.com/active-directory-part-3-gpo-hardening/?ref=blog.sudowl.com) - [Join Windows Server to AD Domain with PowerShell](https://blog.diengdoh.com/join-windows-server-ad-domain-powershell/?ref=blog.sudowl.com)