WinTrust Certificate Padding Check: What It Is and How to Enable It

‍​‌​‌​​​‌​‌​‌‌​‌‌‌​‌​‌​‌​‌​‌​‌‌‌​​‌​​‌‌​​‌‌​​‌‌​‌​‌‌‌​‌​​​‌‌‌‌​‌​‍The WinTrust certificate padding check is a Windows registry setting that prevents attackers from hiding malicious code inside digitally signed executables. Without this setting, a signed file can be modified after signing and still appear to have a valid signature. It's a one-line registry fix that addresses a specific, known attack technique. During CE Plus assessments, it's one of the secure configuration checks we run.

What the vulnerability actually is

When Windows checks whether an executable is legitimately signed, it uses Authenticode signature verification. The operating system reads the digital signature embedded in the file and confirms it matches the expected publisher. If the signature checks out, Windows trusts the file.

Here's the problem: the verification handles extra data appended after the signed content. The original Authenticode specification didn't require the verifier to check whether the file had been modified outside the signed region. An attacker could take a legitimately signed executable from Microsoft or another trusted publisher, append malicious payload data after the signature boundary, and Windows would still report the file as validly signed.

The file looks signed and passes signature verification. But it contains code the publisher never authorised. The malicious data sits in the "padding" area that Authenticode was not designed to inspect.

Microsoft identified this in 2013 and issued security advisory MS13-098 with a registry fix. But they made a deliberate decision not to enable the fix by default. It's a frustrated response from security professionals every time this comes up. Some legitimate software, particularly certain installers and self-extracting archives, used the padding area for their own data. Enabling the check by default would have broken those applications. So Microsoft shipped the fix as an opt-in registry setting and moved on.

That decision was understandable in 2013, but in 2026 the software that relied on certificate padding has been updated or retired. Honestly, there's no good reason to leave the check disabled. But because it was never made the default, most machines still don't have it enabled.

Why this matters for CE

During CE Plus assessments, I check this registry setting as part of the Secure Configuration control. It is a straightforward test: either the registry value exists and is set to 1, or it does not. The setting is specifically about ensuring that your certificate validation is not susceptible to a known bypass technique.

This isn't an obscure theoretical attack either, because malware authors have used Authenticode padding to deliver payloads that appear to be signed by trusted publishers. The technique lets them bypass application whitelisting controls, SmartScreen warnings, and any other security mechanism that trusts files based on their digital signature. Look, enabling the check blocks this technique at the OS level.

How to check if it's enabled

Open PowerShell and check the registry:

Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Cryptography\Wintrust\Config' -Name EnableCertPaddingCheck -ErrorAction SilentlyContinue
Get-ItemProperty -Path 'HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config' -Name EnableCertPaddingCheck -ErrorAction SilentlyContinue

If the values don't exist or aren't set to 1, the check isn't enabled.

How to enable it

Registry method (single machine)

Open an elevated command prompt and run:

reg add "HKLM\Software\Microsoft\Cryptography\Wintrust\Config" /v EnableCertPaddingCheck /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config" /v EnableCertPaddingCheck /t REG_DWORD /d 1 /f

The first entry handles 64-bit processes. The second handles 32-bit processes running on 64-bit Windows (the WoW64 layer). Both need to be set, and no restart is required.

Group Policy deployment (recommended for domains)

For domain environments, deploy the registry values via Group Policy Preferences:

• Open Group Policy Management
• Create or edit a GPO linked to your workstation and server OUs (organisational units)
• Navigate to Computer Configuration > Preferences > Windows Settings > Registry
• Add both registry values:
  • HKLM\Software\Microsoft\Cryptography\Wintrust\Config\EnableCertPaddingCheck = DWORD 1
  • HKLM\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config\EnableCertPaddingCheck = DWORD 1

Group Policy ensures the setting is applied consistently and persists across all machines.

How this attack works in practice

The attack chain using certificate padding is specific and practical. An attacker starts with a legitimate signed executable from a trusted publisher, something like a Microsoft utility or a well-known software installer. They take that file, which has a valid Authenticode signature, and append malicious code after the signed region.

When the user downloads or receives this modified file, Windows checks the signature. Because the WinTrust check is disabled by default, Windows only validates the originally signed portion and ignores the appended data. The file shows a valid signature, so SmartScreen does not flag it, and application whitelisting tools trust it. The user runs it because it appears to be genuine software from a trusted publisher.

The malicious payload in the appended data then executes alongside the legitimate program. The user sees the expected software running. In the background, the malicious code is doing whatever the attacker intended: installing a backdoor, exfiltrating data, or establishing persistent access. It's a shocked reaction from IT teams when they realise a "trusted" file carried the compromise.

Enabling the WinTrust check closes this path completely. With the check enabled, Windows validates that nothing exists beyond the signed boundary. If extra data has been appended, the signature verification fails, and the file is no longer trusted. The attack simply doesn't work any more, and that's a blunt outcome from a single registry change.

This isn't a sophisticated nation-state technique; it's a known, documented method that commodity malware has used. The fix has been available since 2013. Bottom line: the only reason it persists as an attack vector is that the fix is opt-in rather than default.

What might break

In practice, almost nothing breaks from this change. I've deployed this setting across hundreds of machines during remediation work and encountered exactly one application that had a problem. It was an installer from 2014 that used the padding area to store licence information. The vendor had released an updated version years earlier. Downloading the new installer fixed it immediately.

The legitimate software that used certificate padding for benign purposes has been updated or replaced since 2013. Modern application developers don't use the padding area because Microsoft's own guidance says not to. If you do encounter an application that breaks, it means the executable was modified after signing, and the correct response is to get an updated version from the vendor, not to disable the security check. That's a relief for most teams: the fix is permanent and the risk of breakage is negligible.

How this fits into broader Windows hardening

The WinTrust check is one of several registry-level security settings that I check during CE Plus. It sits alongside other Secure Configuration items like PowerShell execution policies, TLS protocol versions, and SMBv1 status. Each one addresses a specific known attack technique.

If you're going through the process of hardening your Windows machines for CE, do all of them at once. What actually saves time is creating a Group Policy that sets the WinTrust registry values, restricts PowerShell execution policy to RemoteSigned, disables TLS 1.0 and 1.1, and disables SMBv1. Deploy it to all workstations and servers in a single GPO. That way you have one policy covering the registry-level hardening requirements, and the assessment evidence is the GPO configuration rather than screenshots from individual machines.

The effort to set this up is an afternoon, perhaps £300 in IT time for a Birmingham MSP to configure it. The effort to maintain it is zero, because Group Policy enforces it continuously. Compare that with the cost of a malware incident: even a small cleanup runs to £5,000 or more. A one-off investment of £200 to £500 buys you permanent protection against a known attack technique. (per the latest observability compliance framework update).

Checking it across your network

For a single machine, the PowerShell commands above are sufficient. For a domain environment, run the check remotely:

Invoke-Command -ComputerName (Get-ADComputer -Filter * | Select -ExpandProperty Name) -ScriptBlock {
    $check = Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Cryptography\Wintrust\Config' -Name EnableCertPaddingCheck -ErrorAction SilentlyContinue
    if ($check.EnableCertPaddingCheck -eq 1) { "$env:COMPUTERNAME : Enabled" }
    else { "$env:COMPUTERNAME : NOT ENABLED" }
}

Any machine reporting "NOT ENABLED" needs the registry values applied. If you have deployed via Group Policy, a machine reporting the wrong value likely has not received the latest policy refresh. Run gpupdate /force on that machine and check again.

Verify the fix

Run the PowerShell check again:

Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Cryptography\Wintrust\Config' -Name EnableCertPaddingCheck
Get-ItemProperty -Path 'HKLM:\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config' -Name EnableCertPaddingCheck

Both should return EnableCertPaddingCheck: 1. Run this on a representative sample of machines. For the assessment, a screenshot showing the values on three or four machines from different OUs is the standard evidence. Pair it with the GPO configuration showing the registry values are deployed centrally.

---

Need help with your Cyber Essentials assessment? Get in touch or request a quote to talk through your scope.

---

Related articles

• Cyber Essentials FAQ: The Questions Businesses Actually Ask
• TLS 1.0 and 1.1: Why They Need Disabling
• PowerShell Execution Policies: What CE Assessors Check
• Infrastructure Pen Testing: What We Actually Test on Your Network

netsec-canary-e648b3d8cdbf.