T1553: Subvert Trust Controls
Adversaries may undermine security controls that will either warn users of untrusted activity or prevent execution of untrusted programs. Operating systems and security products may contain mechanisms to identify programs or websites as possessing some level of trust. Examples of such features would include a program being allowed to run because it is signed by a valid code signing certificate, a program prompting the user with a warning because it has an attribute set from being downloaded from the Internet, or getting an indication that you are about to connect to an untrusted site.
Adversaries may attempt to subvert these trust mechanisms. The method adversaries use will depend on the specific mechanism they seek to subvert. Adversaries may conduct File and Directory Permissions Modification or Modify Registry in support of subverting these controls.[1] Adversaries may also create or steal code signing certificates to acquire trust on target systems.[2][3]
Analyst context for executives and security teams
Subvert Trust Controls matters because it targets the mechanisms users, operating systems, and security tools rely on to decide whether code, websites, or files should be trusted. If those trust signals are weakened, a signed file, modified policy, root certificate, registry change, or missing download warning can allow untrusted activity to look acceptable. For leaders, this is a control-assurance problem: execution prevention, certificate trust, endpoint hardening, and audit evidence may appear strong on paper while being bypassed in practice.
Executive priority
Prioritize this technique where business operations depend on trusted software distribution, endpoint execution controls, certificate-based trust, or regulated evidence of control effectiveness. Ask whether the organization can prove that code signing materials, root certificate stores, registry permissions, operating system trust settings, and application-control policies are governed, monitored, and recoverable across Windows, macOS, and Linux environments. The relationship to sub-techniques across Gatekeeper, Code Signing, SIP/trust provider hijacking, root certificate installation, Mark-of-the-Web bypass, and code signing policy modification makes this a cross-platform resilience and compliance-readiness issue rather than a single-tool detection problem.
Technical view
ATT&CK places T1553 under defense-impairment for Linux, macOS, and Windows. The official detection field is not provided, so SOC and detection engineering teams should validate coverage around the related detection strategy: certificate, registry, and attribute manipulation. Practical validation should focus on whether changes to trust stores, code signing policy, registry permissions, file attributes such as Mark-of-the-Web, macOS Gatekeeper-related attributes, and signature-validation components are logged and reviewable. IR teams should include trust-control integrity checks in triage when suspicious execution appears to have passed normal trust prompts or application-control decisions.
Likely telemetry
- Endpoint file metadata and attribute changes, including download-origin or quarantine-style attributes where applicable
- Code signing validation results and certificate details for executed binaries or scripts
- Certificate store changes, especially root certificate additions or modifications
- Windows registry modifications tied to trust providers, code signing policy, or other trust-control settings
- Operating system security configuration and policy change logs
Detection direction
- Because ATT&CK provides no official detection text for T1553, treat coverage as a validation exercise rather than an assumed analytic.
- Use the related DET0452 strategy as direction: look for subversion through certificate, registry, and attribute manipulation.
- Tune for unauthorized or unusual changes to certificate stores, trust providers, code signing policies, file attributes, and operating system security settings.
- Correlate trust-control changes with privileged account use, recent file execution, and application-control decisions to reduce noise.
- Expect legitimate administrative activity, software installation, browser or certificate management, and enterprise configuration changes to create false positives; baselining approved change paths is important.
Mitigation priorities
- Start with privileged account management so only authorized administrators or processes can alter trust-related configuration, certificate stores, registry locations, or execution policies.
- Restrict registry permissions for sensitive Windows trust-control and policy areas where applicable.
- Harden operating system configuration across Linux, macOS, and Windows, with attention to default trust mechanisms and security policy enforcement.
- Use execution prevention controls to limit unauthorized or untrusted code execution, while validating that those controls cannot be silently weakened by policy or trust-store changes.
- Review software configuration for applications that maintain their own trust stores or security settings.
Analyst notes and limits
The ATT&CK relationship set shows this parent technique has multiple platform-specific sub-techniques and is mitigated by registry permission restriction, privileged account management, operating system configuration, execution prevention, and software configuration. ATT&CK also maps use by Axiom and Shai-Hulud; this should be treated as threat-context enrichment, not proof of current activity in any environment. The most useful local work is to inventory where trust decisions are made, who can change them, and whether those changes generate actionable telemetry.
The official ATT&CK detection field for T1553 is not provided, and the supplied mitigation descriptions are high level. This take does not assert detection coverage, exploitation prevalence, customer exposure, or active campaigns. Local platform configuration, EDR/SIEM logging, application-control design, certificate governance, and administrative workflows are required to determine actual risk and coverage.
Subvert Trust Controls
Adversaries may undermine security controls that will either warn users of untrusted activity or prevent execution of untrusted programs. Operating systems and security products may contain mechanisms to identify programs or websites as possessing some level of trust. Examples of such features would include a program being allowed to run because it is signed by a valid code signing certificate, a program prompting the user with a warning because it has an attribute set from being downloaded from the Internet, or getting an indication that you are about to connect to an untrusted site.
Adversaries may attempt to subvert these trust mechanisms. The method adversaries use will depend on the specific mechanism they seek to subvert. Adversaries may conduct File and Directory Permissions Modification or Modify Registry in support of subverting these controls.[1] Adversaries may also create or steal code signing certificates to acquire trust on target systems.[2][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 | T1553.005 | Mark-of-the-Web Bypass Sub-technique | Mark-of-the-Web Bypass subtechnique of this object. |
| Enterprise | T1553.002 | Code Signing Sub-technique | Code Signing subtechnique of this object. |
| Enterprise | T1553.004 | Install Root Certificate Sub-technique | Install Root Certificate subtechnique of this object. |
| Enterprise | T1553.003 | SIP and Trust Provider Hijacking Sub-technique | SIP and Trust Provider Hijacking subtechnique of this object. |
| Enterprise | T1553.006 | Code Signing Policy Modification Sub-technique | Code Signing Policy Modification subtechnique of this object. |
| Enterprise | T1553.001 | Gatekeeper Bypass Sub-technique | Gatekeeper Bypass subtechnique of this object. |
Groups, software, and campaigns
G0001: Axiom
Axiom is a suspected Chinese cyber espionage group that has targeted the aerospace, defense, government, manufacturing, and media sectors since at least 2008. Some reporting suggests a degree of overlap between Axiom and Winnti Group but the two groups appear to be distinct based on differences in reporting on TTPs and targeting.[1][2][3]
S9008: Shai-Hulud
Shai-Hulud is a supply chain worm, first reported in September 2025, that spreads through code repositories, including GitHub and NPM packages. It exploits CI/CD pipeline dependencies to propagate to victims and poisons the supply chain by publishing malicious packages. Once inside a victim environment, Shai-Hulud steals credentials and access tokens from compromised repository accounts and exfiltrates them to attacker-controlled servers via encoded GitHub Actions workflows.[1][2][3][4][5][6][7]
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 | b2008d17df21… |
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]
SpectorOps Subverting Trust Sept 2017
Graeber, M. (2017, September). Subverting Trust in Windows. Retrieved January 31, 2018.
Open source URL -
[2]
Securelist Digital Certificates
Ladikov, A. (2015, January 29). Why You Shouldn’t Completely Trust Files Signed with Digital Certificates. Retrieved March 31, 2016.
Open source URL -
[3]
Symantec Digital Certificates
Shinotsuka, H. (2013, February 22). How Attackers Steal Private Keys from Digital Certificates. Retrieved March 31, 2016.
Open source URL -
[4]
mitre-attack T1553Open 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.