Detecting SIP and Trust Provider Hijacking on Windows (T1553.003)

When Windows decides whether a file is signed, it does not read the signature itself. It hands the question to a chain of components that most administrators never look at. MITRE ATT&CK technique T1553.003, SIP and Trust Provider Hijacking, is about tampering with those components so that unsigned or malicious code is treated as signed. The tactic is defense impairment and the platform is Windows.

To defend against it you need a short tour of how validation works.

How signature validation works

In user mode, Windows Authenticode digital signatures establish a file's origin and integrity. A driver with a valid Microsoft signature, for example, may be handled as safe. The check goes through the WinVerifyTrust API function, which takes an inquiry and coordinates with the right trust provider. The trust provider is responsible for validating the parameters of a signature.

Files come in many formats: executables, PowerShell scripts, installers. So Microsoft created Subject Interface Packages, or SIPs, as an abstraction layer between the API functions and the files. A SIP can create, retrieve, calculate and verify signatures. Each SIP is identified by a globally unique identifier, and catalog signing acts as a catch-all.

All of this is wired together through registry values that point to DLLs.

How attackers use it

MITRE describes three registry based hijacks. In each, the adversary changes the Dll and FuncName values (or the DLL and Function values for trust providers) so Windows calls code the adversary chose.

1. CryptSIPDllGetSignedDataMsg. This function retrieves an encoded certificate from a signed file. Pointing it at a crafted DLL that always returns a known good signature value, such as a Microsoft signature for a Portable Executable, lets an adversary apply an acceptable signature to every file using that SIP. MITRE notes a hash mismatch will likely occur and invalidate the signature, because the returned hash will not match the computed one.
2. CryptSIPDllVerifyIndirectData. This function validates a file's computed hash against the signed hash. A crafted function that always returns TRUE makes any file with a legitimate signature validate. The value can also point to a suitable exported function in a DLL that is already on the system, which avoids dropping a new file.
3. FinalPolicy of a trust provider. This is where the decoded signature is checked and most trust decisions are made. It can be redirected the same way, though MITRE notes a trust provider implementation is complex.

MITRE adds that these hijacks are also possible without touching the registry, through DLL search order hijacking.

There is a persistence angle too. These components are invoked by any application that performs code signing or signature validation, so a malicious one can give repeated code execution.

How to detect it

MITRE lists no data sources for this page, but the targets are specific and stable, which makes monitoring practical.

• Registry changes. Watch writes to the OID encoding type keys for the SIP functions and to the trust provider FinalPolicy keys. Sysmon registry events 12, 13 and 14 cover key creation or deletion, value sets, and renames.
• DLL loads. A DLL loaded by signature validation that sits outside protected directories such as C:\Windows is suspicious. Sysmon event 7 records image loads.
• Object access auditing. Windows security event 4657 records registry value modification, provided you set a system access control list on those keys first.
• Unexpected "valid" results. Application control or endpoint tools that suddenly report formerly unknown files as signed by a trusted publisher deserve a second look.

A baseline helps: these registry values rarely change on a healthy machine, outside of operating system updates.

How to reduce the risk

MITRE lists three mitigations.

1. Execution prevention. Enable application control such as AppLocker or Device Guard to block the loading of malicious SIP DLLs.
2. Restrict registry permissions. Set proper permissions on the registry hives so users cannot modify keys tied to SIP and trust provider components. MITRE cautions that components may still be hijacked to suitable functions already present on disk if malicious registry modification is not prevented, so permissions are the part that matters most.
3. Restrict file and directory permissions. Restrict storage and execution of SIP DLLs to protected directories such as C:\Windows, not user directories.

Check your own environment

These are read-only. Run them in an elevated PowerShell session on a reference machine and compare against others.

# List the SIP registrations for the GetSignedDataMsg function (64 bit view)
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg" |
  ForEach-Object { Get-ItemProperty $_.PSPath | Select-Object PSChildName, Dll, FuncName }

# List the verify registrations
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData" |
  ForEach-Object { Get-ItemProperty $_.PSPath | Select-Object PSChildName, Dll, FuncName }

# Trust provider FinalPolicy registrations
Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Cryptography\Providers\Trust\FinalPolicy" |
  ForEach-Object { Get-ItemProperty $_.PSPath | Select-Object PSChildName, '$DLL', '$Function' }

Things to look for:

• Any Dll path outside C:\Windows\System32 or other protected system folders.
• Entries that differ between machines built from the same image.
• Write permissions on these keys for anyone other than administrators and the system.

Quick check

Sources

• MITRE ATT&CK T1553.003 SIP and Trust Provider Hijacking