SIP and Trust Provider Hijacking: Faking Authenticode Signatures on Windows

Almost every defensive control on Windows leans on one implicit assumption: that a valid Authenticode signature means the file is what it claims to be. Application allowlisting policies carve out exceptions for "signed by Microsoft." EDR reduces scrutiny on signed binaries. Analysts triage a signed DLL differently than an unsigned one. That assumption is convenient — and it is exactly where SIP and trust provider hijacking lives. By corrupting the small, poorly-monitored plumbing that decides whether a signature is valid, an attacker can make arbitrary malware return a clean bill of health from the operating system itself.

How Windows actually validates a signature

When something calls WinVerifyTrust, Windows does not verify a signature in one monolithic function. It delegates to two pluggable, registry-configured component types:

• Subject Interface Packages (SIPs) — DLLs that know how to locate and extract the hash and signature blob from a specific file format (PE, MSI, CAB, PowerShell script, CTL, and so on). Each SIP exports functions like CryptSIPGetSignedDataMsg and CryptSIPVerifyIndirectData.
• Trust providers — the policy layer that walks the certificate chain and decides "trusted / not trusted," reached through the FinalPolicy callback registered under the {action GUID} for a given verification action.

The catch: the mapping from file type to SIP, and from action to trust provider, is just registry data pointing at DLLs and function names. Change the pointer and you change the verdict.

The hijack primitives

Two well-documented techniques (MITRE ATT&CK T1553.003) exploit this:

1. SIP hijacking

The attacker overwrites the Dll and FuncName values under a SIP's provider key so that the "get signed data" and "verify indirect data" callbacks point at attacker-controlled code that simply returns TRUE. The relevant hives are:

HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\
    CryptSIPDllVerifyIndirectData\{SIP-GUID}
HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\
    CryptSIPDllGetSignedDataMsg\{SIP-GUID}

Once CryptSIPDllVerifyIndirectData is repointed at a stub that always succeeds, any file of that subject type validates — the real hash is never compared.

2. Trust provider hijacking

Instead of the SIP, the attacker replaces the FinalPolicy function of a trust provider (for example the Software Publisher Trust Provider) under:

HKLM\SOFTWARE\Microsoft\Cryptography\Providers\Trust\
    FinalPolicy\{action-GUID}

The malicious FinalPolicy returns ERROR_SUCCESS regardless of the actual chain, so revoked, self-signed, or entirely forged certificates all read as trusted.

The signature never has to be forged. The verifier is compromised, so a garbage signature — or a legitimately signed but unrelated certificate copied into the malware — passes.

Why this is so dangerous — and so quiet

These keys are set once, at install time, and essentially never change on a healthy system. That makes them a near-perfect persistence and evasion combo:

• It requires local administrator or SYSTEM, but so does most post-exploitation — and it pays off by neutering signature-based defenses fleet-wide on that host.
• The modification is a handful of registry values, not a running process, so memory-scanning EDR often walks right past it.
• Downstream tools that "trust signed code" now trust the attacker's code, quietly widening every allowlist you thought you had.

Auditing for it

The good news: because these mappings are static and well-known, drift is highly detectable. A quick manual spot-check of the trust provider action:

reg query "HKLM\SOFTWARE\Microsoft\Cryptography\Providers\Trust\FinalPolicy\{603BCC1F-4B59-4E08-B724-D2C6297EF351}" /s

Every legitimate Dll value here should resolve to a Microsoft-signed system binary such as WINTRUST.DLL or C:\Windows\System32\ntdll.dll, and every FuncName should match the documented export. Red flags:

1. A Dll value pointing outside System32 (user profile, ProgramData, Temp).
2. A referenced DLL that is unsigned or signed by a non-Microsoft publisher.
3. Registry keys whose last-write time is recent on a machine that hasn't been reimaged.
4. Unknown SIP GUIDs added under the OID\EncodingType 0 subkeys.

Pair the registry audit with a functional test: sign a deliberately-tampered file and confirm Get-AuthenticodeSignature reports HashMismatch, not Valid. If a corrupted binary comes back valid, your verifier is lying to you.

Where WinSentinel fits

WinSentinel treats the cryptographic trust plumbing as a first-class part of its attack-surface audit. On any single machine — free, with all 33 modules and no limits — it enumerates every registered SIP and trust provider, resolves each backing DLL, checks that it lives in System32 and carries a valid Microsoft signature, and flags any pointer that has drifted from the known-good baseline. That turns an invisible, one-time registry edit into a concrete finding with remediation guidance, right next to your allowlisting and Defender posture checks.

For organizations, WinSentinel Pro rolls those per-host findings into fleet-wide orchestration: the central node collects trust-provider integrity results across every managed endpoint, raises a drift alert the moment one node's SIP mapping diverges from the fleet baseline, and feeds the result into compliance rollups. A hijacked verifier on one laptop stops being a silent local compromise and becomes a triaged, org-visible incident.

Bottom line

Signature validation is only as trustworthy as the components that perform it. SIP and trust provider hijacking doesn't break cryptography — it bribes the referee. Add the Cryptography\OID and Cryptography\Providers\Trust hives to your integrity monitoring, verify the verifier with a tampered-file test, and never let "it's signed" be the end of your analysis.