Windows - Security - Mitigate CredSSP Remote Code Execution Vulnerability ( CVE-2018-0886 )

What the CVE-2018-0886 CredSSP mitigation does

This Automox Worklet™ hardens Windows endpoints against CVE-2018-0886, a remote code execution vulnerability in the Credential Security Support Provider protocol. CredSSP is the authentication transport that Remote Desktop Protocol, WinRM, PowerShell remoting, and several other Windows services use to delegate user credentials to remote hosts. The vulnerability lets a network-positioned attacker downgrade the protocol, intercept a CredSSP handshake, and replay the delegated credentials against the target server.

The Worklet writes the AllowEncryptionOracle policy value under HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters and sets it to 0 (REG_DWORD). This is the Force Updated Clients setting in Microsoft KB 4093492, the strictest of the three documented states. Once the value is in place, CredSSP refuses to fall back to the legacy oracle behavior on either the client or server side of the connection.

The script is idempotent. The evaluation phase reads the current value, type, and parent key, and only triggers remediation when the configuration drifts from the desired state. Repeated policy runs leave a compliant endpoint untouched, which keeps the change-control footprint small on healthy fleets.

Why mitigate CVE-2018-0886 across every Windows endpoint

CVE-2018-0886 carries an NVD CVSS v3.0 base score of 7.0 and remains a recurring finding on vulnerability scanners (Qualys QID 91445, Tenable plugin 109184, Rapid7 windows-hotfix-ms18-mar). The Microsoft security update from March 2018 patched the underlying CredSSP code, but the patch ships in a compatible mode by default. Until AllowEncryptionOracle is set to 0, a patched server still accepts authentication from clients negotiating the vulnerable encryption oracle, which leaves the relay path open even on a fully patched fleet. CIS Microsoft Windows benchmarks and DISA STIG WN10-CC-000260 both call out the missing registry value as a separate compliance failure from the missing KB.

CVE-2018-0886 is a textbook last-mile remediation: Microsoft shipped the CredSSP patch years ago, the registry hardening is one DWORD under HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters, and the gap between the patch being installed and the registry value being set is where the credential-relay risk actually lives. This Worklet writes AllowEncryptionOracle to 0 on every Windows endpoint in scope and verifies the value on each evaluation pass, covering the long tail of remote workstations, jump hosts, and bastion servers that vulnerability scanners keep surfacing.

How the CredSSP encryption oracle hardening works

1. Evaluation phase: A Test-Registry function opens HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters through [Microsoft.Win32.RegistryKey]::OpenBaseKey using the Registry64 or Registry32 view that matches the OS architecture. The script confirms the Parameters subkey exists, that AllowEncryptionOracle is present in GetValueNames(), that GetValueKind() returns DWord, and that the value equals 0. A missing key, a missing value, a wrong type (REG_SZ left behind from a manual edit), or any value other than 0 marks the endpoint non-compliant. The check exits 0 when the state matches and 1 when remediation is required, which is what Automox uses to schedule the next phase.

2. Remediation phase: The remediation script calls a Set-Registry function that opens the LocalMachine hive with [Microsoft.Win32.RegistryKey]::OpenBaseKey, runs CreateSubKey on SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters (which creates the subkey if it is missing), then writes AllowEncryptionOracle with SetValue using the [Microsoft.Win32.RegistryValueKind]::DWord kind. SetValue overwrites a pre-existing value of the wrong type, which is the common state on endpoints that were hand-edited during the 2018 patch cycle. The script exits 0 after the write completes and emits Write-Error with exit code 1 if the registry call throws.

CVE-2018-0886 mitigation requirements

• Windows 7 SP1, Windows 8.1, Windows 10, Windows 11, Windows Server 2008 R2, 2012 R2, 2016, 2019, or 2022 with the March 2018 security update (or any later cumulative update) installed

• PowerShell 3.0 or later (default on every supported OS above)

• Local administrator rights for the Automox agent so it can write under HKEY_LOCAL_MACHINE (the default agent context already meets this)

• Every CredSSP peer (RDP clients, jump hosts, RD Gateway, WinRM endpoints) must already have the security update before you set the registry value to 0; an unpatched peer will lose RDP and PowerShell remoting connectivity

• Reboot the endpoint after the value is written so CredSSP, RDP, and dependent services reload the policy (the script author flags reboot as required to complete the change)

• Stage the policy on a pilot ring first when the fleet includes legacy appliances or third-party RDP gateways that may not honor the patched CredSSP behavior

Expected CredSSP registry state after remediation

After a successful run, HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\AllowEncryptionOracle reads as REG_DWORD with value 0. CredSSP now rejects any client or server attempting to negotiate the legacy encryption oracle, which closes the relay path described in CVE-2018-0886. Subsequent Automox evaluations report the endpoint as compliant without invoking remediation again, because the evaluation phase finds the desired state in place.

Validate from an elevated PowerShell prompt with Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters' -Name AllowEncryptionOracle. The cmdlet should return AllowEncryptionOracle : 0. For RDP-side confirmation, attempt an RDP connection from a patched workstation to a patched server; the session should succeed. From a deliberately unpatched test client, the same RDP attempt should fail with CredSSP error 0x80004005 or the 'An authentication error has occurred' dialog, which proves the policy is enforced. Re-run your vulnerability scanner; CVE-2018-0886 and the linked Qualys, Tenable, and Rapid7 plugin IDs should clear on the next scan.