MITRE ATT&CK T1553 Subvert Trust Controls: Detecting Signature and Trust Tampering

Most endpoint controls decide what to trust from a signature, a download flag or a root certificate, and an attacker who subverts that decision runs code that every control waves through. MITRE ATT&CK T1553 Subvert Trust Controls covers attacks on those trust mechanisms: abusing valid code signatures, stripping or avoiding download markers, hijacking the Windows signature validation components, installing rogue root certificates and switching off signing enforcement. In ATT&CK v20 it sits in the Defense Impairment tactic (TA0112) for Linux, macOS and Windows, with six sub-techniques. This guide explains each one, the detection strategies and log sources MITRE maps to them, and the configuration that keeps trust decisions honest. It is for detection engineers, endpoint and platform owners and threat hunters, and covers defence only.

Key takeaways

• Six different trust mechanisms, one ID. Gatekeeper, code signing, SIP and trust providers, root certificate stores, Mark-of-the-Web and signing enforcement policy each need their own telemetry and hardening.
• Code signing abuse dominates. In the ATT&CK v20 dataset T1553.002 is linked to 28 groups, 8 campaigns and 57 software entries, including the SolarWinds and 3CX supply chain campaigns.
• A valid signature is not a verdict. Detection has to look at who signed, when the certificate was issued, whether it has been revoked and whether the publisher fits the host and path.
• Trust stores and policy keys are crown jewels. Root certificate stores, SIP registry keys, boot configuration and macOS System Integrity Protection should be baselined and alerted on like domain admin group changes.
• Most sub-techniques need admin rights. Removing standing local admin and root closes trust provider hijacking, machine-wide root installs and signing policy changes in one move.

The six sub-techniques

T1553.002 produces a valid signature; the related T1036.001 Invalid Code Signature (Stealth) copies signature metadata that does not validate. Acquiring certificates is mapped separately under Resource Development as T1588.003 and T1587.002. For the tactic-level view, see the ATT&CK Stealth and Defense Impairment Tactics Guide.

How each sub-technique works

Gatekeeper Bypass (T1553.001)

ATT&CK describes Gatekeeper acting on the com.apple.quarantine extended attribute that downloading applications set: on first run it prompts the user, checks system policy, checks the Developer ID signature and checks the notarisation ticket. Files arriving from USB media, network shares or tools such as curl may not get the flag, and ATT&CK notes that before macOS 13 Ventura signing and notarisation were only checked on first launch. Malware recorded includes OSX/Shlayer, XCSSET and Cuckoo Stealer. See the macOS Security Guide for Enterprises.

Code Signing (T1553.002)

Adversaries sign malware with certificates they create, buy or steal so that allow-by-publisher rules and reputation systems trust it. ATT&CK records Scattered Spider using stolen certificates originally issued to NVIDIA, the SolarWinds compromise in which SUNBURST was signed with SolarWinds certificates after malware was injected into the build, and TeamPCP receiving legitimate project signing through compromised release workflows. Key protection and signing pipelines are covered in the Code Signing Security Guide; this page covers detecting the abuse.

SIP and Trust Provider Hijacking (T1553.003)

Windows validates Authenticode through WinVerifyTrust, which calls Subject Interface Packages and trust providers registered under HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\ and ...\Cryptography\Providers\Trust\FinalPolicy\. Redirecting the Dll and FuncName values to a DLL that always returns success makes unsigned or tampered files appear validly signed to every tool that asks, and also gives persistence.

Install Root Certificate (T1553.004)

A rogue root lets an adversary intercept TLS without browser warnings or sign code that chains to a trusted root. ATT&CK records the macOS malware Dok adding a trusted root with security add-trusted-cert and RTM adding a certificate to the Windows store, and notes supply chain cases where atypical roots were pre-installed to enable interception. See the Certificate trust stores and root CA management guide.

Mark-of-the-Web Bypass (T1553.005)

Windows tags downloaded files with a Zone.Identifier alternate data stream that triggers SmartScreen and Office Protected View. Files inside ISO, VHD and some archive formats may not inherit the tag when mounted or extracted. ATT&CK records QakBot packaged in ISO files, TA505 using ISO files for LNK payloads and APT29 embedding ISO and VHDX images in HTML. See the ISO and Container File Malware Delivery Guide and the HTML Smuggling Guide.

Code Signing Policy Modification (T1553.006)

Adversaries switch off enforcement: bcdedit -set TESTSIGNING ON on Windows or csrutil disable from macOS recovery, or patch kernel variables such as g_CiOptions after loading a vulnerable signed driver. Microsoft documents that test signing needs administrator rights and a restart, that the change is refused while protected by Secure Boot policy, and that Windows shows a "Test Mode" watermark. ATT&CK records Turla modifying kernel memory to disable Driver Signature Enforcement and APT39 turning off the RequireSigned feature. The driver route is covered in the BYOVD and EDR Killers Guide.

Detection

ATT&CK v20 maps a detection strategy to the parent (DET0452) and to each sub-technique. The table summarises MITRE's analytics and log sources.

Detections to build first

1. New root certificates: any addition to machine or user root stores that is not in the approved baseline, on every platform. Rare in normal operations, high value.
2. SIP and trust provider registry changes: any write to the CryptSIPDll* or FinalPolicy values. Legitimate changes come almost only from Windows servicing.
3. Signing enforcement changes: bcdedit test signing or integrity check flags, and macOS hosts reporting SIP disabled in MDM inventory.
4. Publisher and certificate rarity: executables or drivers signed by a certificate first seen in your estate in the last few days, issued very recently, or later revoked. Re-run past executions when a certificate is revoked.
5. Executables launched from mounted images: processes whose image path is on a newly mounted ISO or VHD volume, especially from Explorer after a mail or browser download.
6. Quarantine flag removal: xattr removing com.apple.quarantine outside known software installers.

Metrics

• Root store drift: hosts whose root stores differ from the approved baseline. Target zero unexplained.
• Enforcement posture: percentage of Windows hosts with Secure Boot on and test signing off, and of Macs with SIP enabled.
• Signed-malware lag: time from a certificate revocation or industry report to blocking that certificate in application control.
• Container exposure: share of inbound ISO, IMG, VHD and VHDX attachments blocked at mail and web gateways.
• Rule coverage: number of the six sub-techniques with a tested detection in production.

Prevention and hardening

Decision guidance

• Publisher rules or hash rules: publisher rules survive updates but trust anything the certificate signs; pair them with product name and minimum version, and keep hash rules for small, static tool sets.
• TLS inspection roots: if you run TLS inspection, your own root is legitimately on every device. Record its thumbprint in the baseline so that any other new root stands out. See the TLS Inspection Guide.
• Developers and test signing: give driver and kernel developers isolated machines or virtual machines with test signing, rather than exceptions on their daily-use endpoint.
• Small organisations: start with root store baselining through MDM, container blocking at the mail filter, Secure Boot and SIP checks, and SmartScreen enforced. Large estates add application control and certificate rarity analytics.

How to implement

1. Baseline trust: export the approved root store per platform image, record Secure Boot, test signing and SIP state, and capture current SIP registry values.
2. Turn on the telemetry: Sysmon with registry, image load and stream creation events; auditd watches on trust store paths; macOS unified log and osquery collection for quarantine and certificate events.
3. Run detections in report-only: two to four weeks to identify legitimate installers, management agents and inspection roots.
4. Enforce in rings: ProtectedRoots and gateway container blocking first (low risk), then application control in audit mode, then enforced on a pilot ring. Rollback is removing the policy or returning the ring to audit mode.
5. Revocation drill: pick a certificate, simulate its revocation and confirm you can find every binary it signed and block it within a target time. See the Compromised Code Signing Certificate Playbook.

Common failure patterns

• Allowing whole certificate authorities: an allow rule for a commercial CA lets any signed malware through. Scope rules to publishers and products.
• Trusting signatures after theft: certificates stolen in the NVIDIA code-signing certificate theft were later used to sign malware, and ATT&CK records Scattered Spider using them. Expired or revoked status has to feed blocking rules.
• Build compromise yields real signatures: in the SolarWinds supply chain compromise the malicious code was signed by the vendor's own certificate, so detection had to rely on behaviour rather than signature checks.
• Not watching the root store: rogue roots are rare and loud, yet many SIEMs collect no certificate store events at all.
• Containers left open: ISO and VHD attachments allowed because a few teams use them, with no compensating detection on mounted-volume execution.
• Developer exceptions spread: test signing or SIP disabled for one project and never re-enabled.

Framework mapping

Where identity fits

Code signing certificates and root CAs are machine identities: whoever holds the private key can make code or servers look trusted. Signing keys sit in build pipelines and are used by service accounts and CI tokens, which is how build-system compromises turn into validly signed malware. Treat signing keys as privileged non-human identities with an owner, hardware or cloud KMS custody, approval for every signing request and logging of each use. See the Code Signing Security Guide.

Practitioner checklist

• Baseline root stores per platform and alert on any unapproved addition.
• Set ProtectedRoots Flags to 1 and manage roots by Group Policy or MDM.
• Alert on writes to SIP and trust provider registry values.
• Keep Secure Boot, memory integrity and SIP on, and report hosts where they are off.
• Alert on bcdedit test signing changes and csrutil disable.
• Block ISO, IMG, VHD and VHDX at gateways where possible and detect execution from mounted images.
• Scope application control publisher rules to products, not CAs.
• Feed certificate revocations and threat reports into blocking rules and retro-hunts.
• Remove standing local admin and root on endpoints.

Standards and references

• MITRE ATT&CK: Subvert Trust Controls (T1553)
• MITRE ATT&CK: Code Signing (T1553.002)
• MITRE ATT&CK: Mark-of-the-Web Bypass (T1553.005)
• Microsoft Learn: The TESTSIGNING boot configuration option
• Microsoft Learn: Configure trusted roots and disallowed certificates
• Microsoft Learn: Attack surface reduction rules reference
• Apple: Gatekeeper and runtime protection in macOS
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: MITRE ATT&CK Guide for Defenders · Code Signing Security Guide · T1036 Masquerading Defensive Guide · Application Control and Endpoint Prevention Buyer's Guide · T1685 Disable or Modify Tools Defensive Guide