CVE-2013-3900

What is the WinVerifyTrust Function?

WinVerifyTrust is a Windows API function responsible for verifying the Authenticode digital signature of Portable Executable (PE) files — the executables, DLLs, and drivers that Windows runs. When Windows Security, UAC prompts, driver installation dialogs, and security software check whether a file is digitally signed by a trusted publisher, they call WinVerifyTrust. A flaw in how this function validates signatures can allow malicious code to appear as legitimately signed software, bypassing trust checks across the entire Windows security model.

Overview

CVE-2013-3900 is a signature verification bypass (CWE-347) in the WinVerifyTrust function. The PE Authenticode signature standard computes a hash over the executable's content; however, the original standard allowed additional data to be appended to a signed PE file after the signature was computed. WinVerifyTrust verified only the originally-signed portion of the file, treating the file as validly signed even when unsigned content had been appended. Malware authors exploited this to append malicious payloads to legitimately-signed executable files — producing binaries that Windows reported as validly signed by trusted publishers but contained attacker-controlled code.

Microsoft released a fix via KB2893294 and Security Advisory 2915720 in December 2013, but the strictness enforcement was initially opt-in rather than mandatory.

Affected Versions

Technical Details

The Windows Authenticode signature format for PE files works by computing a hash over the PE file's content (excluding the signature area itself) and storing the signed hash in the file's WIN_CERTIFICATE structure. The Authenticode specification historically permitted additional data after the final section of the PE file — a region sometimes called the "certificate padding" or "overlay."

The vulnerability: WinVerifyTrust verified the Authenticode signature over the declared content but did not enforce that the PE file contained nothing beyond what the signature covered. An attacker could take any legitimately-signed executable from a trusted software vendor and append additional data after the signature boundary. WinVerifyTrust would return a valid signature result for this modified file, even though the appended data was not part of the original signed content.

Exploitation pattern: Malware appended in this way executes as part of a loader or dropper scheme — the host executable runs normally and the appended content is accessed separately (not as standard PE code from the main executable's normal entry point). This technique was used to make malware deliverables appear to be validly signed files from trusted publishers when inspected by security tools, AV engines, and Windows UI trust dialogs.

Opt-in fix: Microsoft's initial patch made stricter enforcement optional (via a registry key) rather than mandatory. This unusual choice was made to avoid breaking legitimate software that had appended data in their signed executables for reasons other than malice. The registry opt-in was EnableCertPaddingCheck.

Discovery

The WinVerifyTrust signature bypass had been known and discussed in security research for several years before CVE assignment. Microsoft formalized the fix and CVE assignment in December 2013 as exploitation became more widespread.

Exploitation Context

CISA added CVE-2013-3900 to the KEV catalog in January 2022, one of the original catalog entries, confirming sustained real-world exploitation. The technique of appending malicious content to legitimately-signed binaries was used by sophisticated malware families to bypass security product trust checks and Windows SmartScreen. By appearing legitimately signed, malware avoided prompts and security alerts that rely on WinVerifyTrust for trust decisions.

Remediation

1. Apply KB2893294 and enable strict signature checking via the EnableCertPaddingCheck registry setting — Microsoft Security Advisory 2915720 provides the specific registry values
2. For Windows 8.1 and Server 2012 R2 and later: verify the patch is applied and the enforcement key is set
3. Deploy application allowlisting (AppLocker, WDAC) — this provides trust controls independent of WinVerifyTrust signature checks
4. Do not rely solely on Authenticode signature checks as a security boundary; combine with hash-based allowlisting and behavioral detection
5. Update enterprise security tools to use stricter Authenticode validation logic that enforces file integrity beyond just the signed region