Windows - Security - Mitigate WinVerifyTrust Signature Validation (CVE-2013-3900)

What the WinVerifyTrust signature validation mitigation does

This Automox Worklet™ mitigates CVE-2013-3900 by switching Windows Authenticode verification into strict certificate-padding mode, which causes WinVerifyTrust to reject signed portable executable (PE) files that have been modified after signing. The Worklet writes the EnableCertPaddingCheck registry value as REG_SZ "1" to two registry paths: HKLM:\SOFTWARE\Microsoft\Cryptography\Wintrust\Config for native code, and HKLM:\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Wintrust\Config for 32-bit code running under WOW64 on 64-bit Windows. Both paths are required because each architecture loads its own copy of wintrust.dll.

CVE-2013-3900 is a signature validation flaw, not a code bug. The Authenticode specification permits unverified data inside the WIN_CERTIFICATE structure of a signed PE, so attackers can append a malicious payload to a legitimately signed .exe, .sys, or .dll while the operating system still reports the binary as trusted. Microsoft shipped an opt-in fix in 2013 and updated guidance in January 2022 confirming the registry value is the supported mitigation. The fix is not enabled by default because of theoretical signature-compatibility risk on legacy installers; in practice, modern signed software is unaffected.

The Worklet is idempotent. It is safe to schedule on a recurring policy: endpoints already at the desired state report compliant and exit without writing, while endpoints that have drifted (newly imaged, rolled-back image, or admin error) are corrected on the next evaluation.

Why mitigate the WinVerifyTrust signature validation bypass

CVE-2013-3900 is on CISA's Known Exploited Vulnerabilities catalog and has been weaponized for over a decade to ship signed malware, ransomware loaders, and advanced persistent threat tooling that bypasses code-signing controls. Because the fix is opt-in, fresh Windows installs and re-imaged endpoints land in the catalog as exposed by default. CIS Benchmark guidance references EnableCertPaddingCheck, and NIST 800-53 SI-7 (Software, Firmware, and Information Integrity) maps to this control for regulated environments.

Pushing EnableCertPaddingCheck through a single Automox policy run lands the value on every Windows 10, Windows 11, and Windows Server endpoint in scope, and recurring evaluation re-applies the value any time a hardening baseline or sysprep cycle clears it. A workstation that pulled a fresh image last night is back in compliance on its next agent check-in rather than waiting for the next manual GPO push. That closes the gap between when an endpoint is provisioned and when the mitigation is actually in place.

How certificate padding validation enforcement works

1. Evaluation phase: The Worklet opens the LocalMachine hive through the .NET Microsoft.Win32.RegistryKey API (Registry64 or Registry32 view based on the OS architecture) and reads EnableCertPaddingCheck from SOFTWARE\Microsoft\Cryptography\Wintrust\Config and SOFTWARE\Wow6432Node\Microsoft\Cryptography\Wintrust\Config. Both values must exist, equal the string "1", and use the REG_SZ value type for the endpoint to report compliant. If either key is missing, the value is absent, the value does not match "1", or the value type drifts, the endpoint exits with code 2 and is flagged for remediation. The evaluation script does not modify the registry; it only reports state.

2. Remediation phase: The Worklet calls CreateSubKey on each Wintrust\Config path to create the keys if they are missing, then writes EnableCertPaddingCheck with SetValue using the String (REG_SZ) value kind to both the native and Wow6432Node paths. The change takes effect on the next signature verification call, so no reboot or service restart is required. The script exits 0 on success and exits 2 with a Write-Error stderr message if the registry write fails (typically because the Automox agent is not running with SYSTEM privileges, which is the default on a healthy install).

WinVerifyTrust mitigation requirements

• Windows 10, Windows 11, or Windows Server 2016 and later (the registry path and value behavior are unchanged across modern Windows)

• PowerShell 3.0 or higher; 5.1 is the typical baseline on supported Windows

• SYSTEM-level write access to HKEY_LOCAL_MACHINE\SOFTWARE (the default Automox agent context)

• Authenticode-signed software in your environment must use compliant signatures; modern vendor installers do, but verify legacy in-house installers in a pilot ring first

• No additional parameters; this Worklet has no policy-level variables to configure

Expected Authenticode behavior after remediation

After remediation, Windows rejects any PE file whose digital signature covers a header that no longer matches the file's actual contents. Genuine signed code from Microsoft, hardware vendors, and modern third-party publishers continues to execute normally because their signatures cover the full file, including the cert padding region. Attackers can no longer append a malicious payload to a signed binary and have Windows report the file as trusted, which closes the primary delivery path for the signed-malware variant of this attack.

Validate on a sample endpoint with: Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Cryptography\Wintrust\Config' -Name EnableCertPaddingCheck and the matching Wow6432Node path. Both should return the string "1". For audit evidence, capture the output and store it with the policy run identifier. The change introduces zero measurable performance overhead on signature verification and requires no end user action. The Worklet's recurring evaluation keeps the setting pinned across image refreshes, kernel upgrades, and OS feature updates, so the endpoint stays compliant for the life of the asset.