Most vulnerability reports land on a technical team as a list of findings with no obvious action attached. The scanner names the weakness, cites a reference, assigns a score, and stops. Somebody then spends an afternoon working out that three of the findings are the same registry value.
If your report covers any of the findings below, here are suggested fixes for each one, along with what the change is likely to affect in your environment. They are suggestions rather than instructions: your estate, your software and your users decide whether each is appropriate, and you are the one who has to support the result.
Read this before you paste anything
You run these commands at your own risk. Test first, on a device you can afford to rebuild.
That is not a disclaimer for its own sake. Every setting below exists as an optional setting rather than a default because Microsoft judged the compatibility cost too high to impose on everyone. Whether that cost applies to you depends on software Microsoft has never seen, so the decision has to be yours, taken deliberately.
Test on a representative device. Not a clean virtual machine. A device that looks like the ones your people actually use: the same line of business applications, the same peripherals, the same age, the same security agent. A clean build will accept almost anything; a fifteen year old accounting package on a laptop with a label printer attached is where you find out.
How to apply the settings across your estate
The commands below are written as reg add because that is the clearest way to describe exactly which value changes. How you actually deploy them depends on the size and shape of your organisation, and there is no single right answer.
Microsoft Intune, or another mobile device management platform. The usual choice for cloud managed estates. Settings are deployed as configuration profiles or through the settings catalogue, and where a setting is not exposed natively you can deploy the same registry change as a platform script or a custom profile. The advantage that matters is coverage: a device enrolled next month receives the configuration automatically, without anyone remembering to do it.
Group Policy. The equivalent for domain joined estates. Most of these settings have a native policy object; the remainder can be applied through Group Policy Preferences as registry items. Same principle, same benefit: new machines pick up the configuration when they join.
A script run at build time. Perfectly reasonable if your deployment process is image or task sequence based. Fold the changes into the build so every machine leaves the bench configured, and keep the script in version control so you can see what changed and when.
By hand, if your estate is small. If you have eight laptops and no management platform, applying these by hand is a legitimate answer, and better than not applying them at all while you shop for a tool. Two conditions make it work: write down what you changed, and add it to whatever checklist you follow when you set up a new machine. The reason larger estates use policy is not that manual configuration is wrong, it is that manual configuration does not scale and gives you no way to prove the setting is still in place a year later.
The point of all four options is the same. Whatever you choose, make sure new devices get these settings too, because the machine bought in six months is the one that will still be answering LLMNR broadcasts long after everything else has been fixed.
If your report covers these, here are the suggested fixes
| Scan finding | Registry fix |
|---|---|
| WinVerifyTrust signature validation, CVE-2013-3900 | EnableCertPaddingCheck on both 64 bit and 32 bit paths |
| SMB signing not required | RequireSecuritySignature on server and workstation |
| SSL/TLS birthday attack, SWEET32, CVE-2016-2183 | Disable Triple DES 168 in SCHANNEL ciphers |
| LLMNR and NBT-NS poisoning exposure | EnableMulticast off, DisableSmartNameResolution on |
| Cleartext credentials in memory, WDigest | UseLogonCredential off, plus LSA as a protected process |
| Anonymous SAM enumeration, null sessions | RestrictAnonymous, RestrictAnonymousSAM, RestrictRemoteSAM, RestrictNullSessAccess |
| LM and NTLMv1 permitted | LmCompatibilityLevel set to 5 |
| AlwaysInstallElevated privilege escalation | AlwaysInstallElevated off in both hives |
| Administrator account enumeration at logon | EnumerateAdministrators off |
| Autorun and autoplay enabled | NoAutorun and NoDriveTypeAutoRun |
| PowerShell version 2 present, downgrade attack | Remove the optional feature |
| No PowerShell logging for detection | Script block and module logging on |
1. CVE-2013-3900, WinVerifyTrust signature validation
The finding that surprises people, because the patch has existed since 2013 and does nothing until you switch it on.
The weakness allows attacker controlled data to be appended to the authenticode signature block of a signed binary without invalidating the signature. The file still verifies as signed by a trusted publisher while carrying content that was never signed. Microsoft shipped the hardening as opt in rather than default, because enabling it can invalidate signatures on installers that legitimately relied on the padded area.
Both keys are required. Setting only the 64 bit path leaves 32 bit binaries validated the old way, which is exactly what a scanner will flag on the next run.
reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Wintrust\Config" /v "EnableCertPaddingCheck" /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" /v "EnableCertPaddingCheck" /t REG_DWORD /d 1 /f
What it can break: older installers and self extracting archives whose signature depended on the padding. Test your deployment tooling and any bespoke installers before rolling out broadly.
2. SMB signing not required
A finding on practically every internal test, and the enabler for relay attacks: an attacker who can position themselves between two systems can pass authentication through to a third rather than needing to crack anything. Signing makes tampering detectable and relaying substantially harder.
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v "RequireSecuritySignature" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v "EnableSecuritySignature" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v "RequireSecuritySignature" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" /v "EnableSecuritySignature" /t REG_DWORD /d 1 /f
A warning worth more than the commands. If you have copied these from a document, check the quotation marks. Word processors silently convert straight quotes to curly ones, and reg add with curly quotes fails or writes a value name nobody will ever find. Paste into a plain text editor first and look.
What it can break: older network attached storage, legacy printers and embedded devices that do not support signing. Those devices are usually the reason signing was never required in the first place, and they are worth a conversation of their own.
3. SWEET32, the birthday attack on Triple DES
CVE-2016-2183. Block ciphers with a 64 bit block size become vulnerable to collision attacks over long lived connections, and Triple DES is the one still enabled on Windows for compatibility.
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168" /v Enabled /t REG_DWORD /d 0 /f
What it can break: very old clients with no modern cipher in common. On a current estate this is usually safe, but check anything embedded, medical or industrial before assuming.
4. LLMNR and NBT-NS poisoning
Not a patchable vulnerability, a protocol behaviour, and one of the most reliable footholds on an internal test. When name resolution fails, Windows broadcasts asking the local network who holds the name. An attacker answers, receives an authentication attempt, and captures or relays the hash.
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v DisableSmartNameResolution /t REG_DWORD /d 1 /f
Disable NetBIOS over TCP/IP on your adapters as well, through DHCP options or adapter configuration, or half the exposure remains.
What it can break: environments relying on flat name resolution without proper DNS suffixes. If disabling it breaks something, that something was depending on a protocol an attacker was equally welcome to answer.
5. Credential dumping and LSA protection
Two findings, related: cleartext credentials retrievable from memory through WDigest, and LSASS accessible to tools that scrape credentials from it.
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" /v UseLogonCredential /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation" /v AllowProtectedCreds /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.exe" /v AuditLevel /t REG_DWORD /d 8 /f
The audit value is the one people skip and should not: it logs processes attempting to access LSASS, which is how you find out someone tried.
What it can break: LSA protection blocks unsigned or improperly signed plug-ins from loading into LSASS, which occasionally includes smart card middleware, single sign on agents and older endpoint security products. Enable the audit level first, review what is being blocked, then enforce.
6. Anonymous enumeration and null sessions
A cluster of findings that all mean the same thing: an unauthenticated attacker can ask a machine to describe its accounts and shares.
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RestrictAnonymous /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RestrictAnonymousSAM /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RestrictRemoteSAM /t REG_SZ /d "O:BAG:BAD:(A;;RC;;;BA)" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" /v RestrictNullSessAccess /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LimitBlankPasswordUse /t REG_DWORD /d 1 /f
RestrictRemoteSAM takes a security descriptor rather than a number: the value above permits administrators only.
7. Legacy authentication protocols
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 5 /f
Level 5 sends NTLMv2 only and refuses LM and NTLMv1. This is the change most likely to break something, because anything that only speaks NTLMv1 stops authenticating immediately. Audit before enforcing.
8. Privilege escalation through installers
AlwaysInstallElevated allows any user to run an installer package as SYSTEM. It appears in scan output as a local privilege escalation finding, and it is trivially exploitable when present.
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated /t REG_DWORD /d 0 /f
reg add "HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer" /v AlwaysInstallElevated /t REG_DWORD /d 0 /f
Both hives, because the vulnerability requires both to be enabled and the fix is only complete when both are off.
9. Housekeeping that still shows up
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\CredUI" /v EnumerateAdministrators /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoDriveTypeAutoRun /t REG_DWORD /d 255 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v NoAutorun /t REG_DWORD /d 1 /f
And remove the PowerShell version 2 engine, which exists only as a downgrade path around modern logging:
Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root
10. Logging, which fixes nothing and finds everything
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging" /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging" /v EnableModuleLogging /t REG_DWORD /d 1 /f
Script block logging records what PowerShell actually executed after deobfuscation, which is frequently the only readable evidence of what happened. It closes no vulnerability and is one of the highest value settings on this page.
Enable the audit-only settings first and watch for a fortnight. Then the low risk items: certificate padding, autorun, administrator enumeration, installer elevation, PowerShell logging. Then the compatibility sensitive ones one at a time, with a rollback ready and a way to reverse them across the estate: SMB signing, LSA protection, Triple DES, and the NTLM level last of all.
How this connects to certification
Two of the Cyber Essentials controls live here. Secure configuration expects unnecessary functionality to be removed or disabled, which is most of this page. Security update management requires updates rated high or critical by the vendor to be applied within 14 days, which is why several of these findings recur: the patch was installed and the hardening was never enabled.
Running a vulnerability assessment regularly is what turns this from an annual scramble into a routine, because it tells you which of these are still outstanding and how long they have been. We wrote separately about the difference between assessment and penetration testing, and about what a good test report should contain.
If you would rather someone independent told you which of these apply to your estate, and which would break something if you applied them, get in touch or call 01722 445972.
These registry values are provided as suggested fixes for common vulnerability findings, for use on systems you are responsible for. Test on representative devices, keep a rollback path, and apply them at your own risk. Malwise Cyber Ltd accepts no liability for changes made to systems outside an agreed engagement.