T1553.003: SIP and Trust Provider Hijacking
Adversaries may tamper with SIP and trust provider components to mislead the operating system and application control tools when conducting signature validation checks. In user mode, Windows Authenticode [1] digital signatures are used to verify a file's origin and integrity, variables that may be used to establish trust in signed code (ex: a driver with a valid Microsoft signature may be handled as safe). The signature validation process is handled via the WinVerifyTrust application programming interface (API) function, [2] which accepts an inquiry and coordinates with the appropriate trust provider, which is responsible for validating parameters of a signature. [3]
Because of the varying executable file types and corresponding signature formats, Microsoft created software components called Subject Interface Packages (SIPs) [4] to provide a layer of abstraction between API functions and files. SIPs are responsible for enabling API functions to create, retrieve, calculate, and verify signatures. Unique SIPs exist for most file formats (Executable, PowerShell, Installer, etc., with catalog signing providing a catch-all [5]) and are identified by globally unique identifiers (GUIDs). [3]
Similar to Code Signing, adversaries may abuse this architecture to subvert trust controls and bypass security policies that allow only legitimately signed code to execute on a system. Adversaries may hijack SIP and trust provider components to mislead operating system and application control tools to classify malicious (or any) code as signed by: [3]
* Modifying the Dll and FuncName Registry values in HKLM\SOFTWARE\WOW6432Node]Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg\{SIP_GUID}</code> that point to the dynamic link library (DLL) providing a SIP’s CryptSIPDllGetSignedDataMsg function, which retrieves an encoded digital certificate from a signed file. By pointing to a maliciously-crafted DLL with an exported function that always returns a known good signature value (ex: a Microsoft signature for Portable Executables) rather than the file’s real signature, an adversary can apply an acceptable signature value to all files using that SIP [6] (although a hash mismatch will likely occur, invalidating the signature, since the hash returned by the function will not match the value computed from the file). * Modifying the <code>Dll</code> and <code>FuncName</code> Registry values in <code>HKLM\SOFTWARE[WOW6432Node]Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\{SIP_GUID}</code> that point to the DLL providing a SIP’s CryptSIPDllVerifyIndirectData function, which validates a file’s computed hash against the signed hash value. By pointing to a maliciously-crafted DLL with an exported function that always returns TRUE (indicating that the validation was successful), an adversary can successfully validate any file (with a legitimate signature) using that SIP [6] (with or without hijacking the previously mentioned CryptSIPDllGetSignedDataMsg function). This Registry value could also be redirected to a suitable exported function from an already present DLL, avoiding the requirement to drop and execute a new file on disk. * Modifying the <code>DLL</code> and <code>Function</code> Registry values in <code>HKLM\SOFTWARE[WOW6432Node]Microsoft\Cryptography\Providers\Trust\FinalPolicy\{trust provider GUID}</code> that point to the DLL providing a trust provider’s FinalPolicy function, which is where the decoded and parsed signature is checked and the majority of trust decisions are made. Similar to hijacking SIP’s CryptSIPDllVerifyIndirectData function, this value can be redirected to a suitable exported function from an already present DLL or a maliciously-crafted DLL (though the implementation of a trust provider is complex). * **Note:** The above hijacks are also possible without modifying the Registry via [DLL search order hijacking.
Hijacking SIP or trust provider components can also enable persistent code execution, since these malicious components may be invoked by any application that performs code signing or signature validation. [3]
Analyst context for executives and security teams
This Windows technique matters because it attacks the trust decision itself. If SIP or trust provider components are tampered with, code-signing and application-control checks that leadership may rely on for “only trusted software runs” can be misled. The business risk is not just malware execution; it is loss of confidence in security evidence that depends on Authenticode, WinVerifyTrust, and signed-code validation.
Executive priority
Prioritize this where Windows application control, signed-code policy, or audit evidence around trusted execution is important. Leaders should ask whether critical registry paths and DLL locations involved in signature validation are protected, monitored, and baselined. This is especially relevant for incident response readiness because a compromise of trust validation can make otherwise suspicious code appear acceptable to operating system or application-control workflows.
Technical view
For SOC, detection engineering, and IR teams, validate coverage for Windows changes to SIP and trust provider configuration under the documented Cryptography OID and Trust provider registry locations, including WOW6432Node paths. Also validate file-system monitoring around DLLs referenced by those registry values and investigate unexpected changes to Dll, DLL, FuncName, or Function values. Relationship context indicates DET0442 is the relevant detection strategy for this behavior, and mitigations include restricting file/directory permissions, restricting registry permissions, and execution prevention. Because ATT&CK provides no official detection text for this object, local baselining and change-control context are essential.
Likely telemetry
- Windows registry modification events for HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg and CryptSIPDllVerifyIndirectData paths
- Windows registry modification events for HKLM\SOFTWARE\Microsoft\Cryptography\Providers\Trust\FinalPolicy paths
- WOW6432Node equivalents of the SIP and trust provider registry paths
- File creation, modification, and permission-change telemetry for DLLs referenced by SIP or trust provider registry values
- Process and module-load telemetry showing applications invoking or loading unexpected signature-validation components
Detection direction
- Baseline known-good SIP GUID and trust provider GUID registry values, then alert on unauthorized or unexplained changes to DLL path and function-name values.
- Correlate registry changes with new or modified DLLs, especially where a DLL path is outside expected Windows or approved software locations.
- Treat this as a defense-impairment behavior: a successful change may reduce the reliability of downstream signed-code decisions, so do not rely only on signature status during triage.
- Tune for administrative and software-installation noise by comparing against approved change windows, patching activity, and known enterprise software updates.
- Include 32-bit and 64-bit registry views to avoid missing WOW6432Node changes.
Mitigation priorities
- Restrict registry permissions on sensitive SIP and trust provider keys so only authorized administrators or trusted processes can modify them.
- Restrict file and directory permissions for locations containing signature-validation DLLs and related components.
- Use execution-prevention controls to limit unauthorized code execution, while recognizing this technique is specifically aimed at subverting trust controls and therefore requires monitoring of the trust infrastructure itself.
- Maintain baselines and change-control evidence for code-signing validation components to support incident response and compliance reviews.
- During IR, verify the integrity of SIP and trust provider configuration before trusting signed-code conclusions on an affected Windows system.
Analyst notes and limits
This is a Windows sub-technique of Subvert Trust Controls under the defense-impairment tactic. The supplied ATT&CK relationships show mitigations M1022, M1024, and M1038, plus detection strategy DET0442. The revoked predecessor T1198 referenced stealth and persistence, and the current description notes that hijacked components may be invoked by applications performing code-signing or signature validation, creating potential persistent code execution conditions.
ATT&CK does not provide official detection text for this object, and the supplied data does not establish active exploitation, prevalence, vendor-specific coverage, or guaranteed detection. Practical assessment requires local Windows configuration baselines, registry auditing status, file-system telemetry, application-control design, and administrative change records.
SIP and Trust Provider Hijacking
Adversaries may tamper with SIP and trust provider components to mislead the operating system and application control tools when conducting signature validation checks. In user mode, Windows Authenticode [1] digital signatures are used to verify a file's origin and integrity, variables that may be used to establish trust in signed code (ex: a driver with a valid Microsoft signature may be handled as safe). The signature validation process is handled via the WinVerifyTrust application programming interface (API) function, [2] which accepts an inquiry and coordinates with the appropriate trust provider, which is responsible for validating parameters of a signature. [3]
Because of the varying executable file types and corresponding signature formats, Microsoft created software components called Subject Interface Packages (SIPs) [4] to provide a layer of abstraction between API functions and files. SIPs are responsible for enabling API functions to create, retrieve, calculate, and verify signatures. Unique SIPs exist for most file formats (Executable, PowerShell, Installer, etc., with catalog signing providing a catch-all [5]) and are identified by globally unique identifiers (GUIDs). [3]
Similar to Code Signing, adversaries may abuse this architecture to subvert trust controls and bypass security policies that allow only legitimately signed code to execute on a system. Adversaries may hijack SIP and trust provider components to mislead operating system and application control tools to classify malicious (or any) code as signed by: [3]
* Modifying the Dll and FuncName Registry values in HKLM\SOFTWARE\WOW6432Node]Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllGetSignedDataMsg\{SIP_GUID}</code> that point to the dynamic link library (DLL) providing a SIP’s CryptSIPDllGetSignedDataMsg function, which retrieves an encoded digital certificate from a signed file. By pointing to a maliciously-crafted DLL with an exported function that always returns a known good signature value (ex: a Microsoft signature for Portable Executables) rather than the file’s real signature, an adversary can apply an acceptable signature value to all files using that SIP [6] (although a hash mismatch will likely occur, invalidating the signature, since the hash returned by the function will not match the value computed from the file). * Modifying the <code>Dll</code> and <code>FuncName</code> Registry values in <code>HKLM\SOFTWARE[WOW6432Node]Microsoft\Cryptography\OID\EncodingType 0\CryptSIPDllVerifyIndirectData\{SIP_GUID}</code> that point to the DLL providing a SIP’s CryptSIPDllVerifyIndirectData function, which validates a file’s computed hash against the signed hash value. By pointing to a maliciously-crafted DLL with an exported function that always returns TRUE (indicating that the validation was successful), an adversary can successfully validate any file (with a legitimate signature) using that SIP [6] (with or without hijacking the previously mentioned CryptSIPDllGetSignedDataMsg function). This Registry value could also be redirected to a suitable exported function from an already present DLL, avoiding the requirement to drop and execute a new file on disk. * Modifying the <code>DLL</code> and <code>Function</code> Registry values in <code>HKLM\SOFTWARE[WOW6432Node]Microsoft\Cryptography\Providers\Trust\FinalPolicy\{trust provider GUID}</code> that point to the DLL providing a trust provider’s FinalPolicy function, which is where the decoded and parsed signature is checked and the majority of trust decisions are made. Similar to hijacking SIP’s CryptSIPDllVerifyIndirectData function, this value can be redirected to a suitable exported function from an already present DLL or a maliciously-crafted DLL (though the implementation of a trust provider is complex). * **Note:** The above hijacks are also possible without modifying the Registry via [DLL search order hijacking.
Hijacking SIP or trust provider components can also enable persistent code execution, since these malicious components may be invoked by any application that performs code signing or signature validation. [3]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1198 | SIP and Trust Provider Hijacking | SIP and Trust Provider Hijacking revoked by this object. |
| Enterprise | T1553 | Subvert Trust Controls | This object subtechnique of Subvert Trust Controls. |
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 4544ec077cf3… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Microsoft Authenticode
Microsoft. (n.d.). Authenticode. Retrieved January 31, 2018.
Open source URL -
[2]
Microsoft WinVerifyTrust
Microsoft. (n.d.). WinVerifyTrust function. Retrieved January 31, 2018.
Open source URL -
[3]
SpectorOps Subverting Trust Sept 2017
Graeber, M. (2017, September). Subverting Trust in Windows. Retrieved January 31, 2018.
Open source URL -
[4]
EduardosBlog SIPs July 2008
Navarro, E. (2008, July 11). SIP’s (Subject Interface Package) and Authenticode. Retrieved January 31, 2018.
Open source URL -
[5]
Microsoft Catalog Files and Signatures April 2017
Hudek, T. (2017, April 20). Catalog Files and Digital Signatures. Retrieved January 31, 2018.
Open source URL -
[6]
GitHub SIP POC Sept 2017
Graeber, M. (2017, September 14). PoCSubjectInterfacePackage. Retrieved January 31, 2018.
Open source URL -
[7]
mitre-attack T1553.003Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.