Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

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]

EnterpriseT1553TechniqueObject v2.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

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.

Official MITRE ATT&CK definition

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]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

6 rows
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.
Associated objects

Groups, software, and campaigns

Group Enterprise

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]

Malware Enterprise

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]

LinuxSaaSWindows
Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

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 .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
b2008d17df211edd...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle b2008d17df21…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    SpectorOps Subverting Trust Sept 2017

    Graeber, M. (2017, September). Subverting Trust in Windows. Retrieved January 31, 2018.

    Open source URL
  2. [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. [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. [4]
    mitre-attack T1553
    Open source URL
Source and licensing

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.