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

T1553.004: Install Root Certificate

Adversaries may install a root certificate on a compromised system to avoid warnings when connecting to adversary controlled web servers. Root certificates are used in public key cryptography to identify a root certificate authority (CA). When a root certificate is installed, the system or application will trust certificates in the root's chain of trust that have been signed by the root certificate.[1] Certificates are commonly used for establishing secure TLS/SSL communications within a web browser. When a user attempts to browse a website that presents a certificate that is not trusted an error message will be displayed to warn the user of the security risk. Depending on the security settings, the browser may not allow the user to establish a connection to the website.

Installation of a root certificate on a compromised system would give an adversary a way to degrade the security of that system. Adversaries have used this technique to avoid security warnings prompting users when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate websites in order to collect login credentials.[2]

Atypical root certificates have also been pre-installed on systems by the manufacturer or in the software supply chain and were used in conjunction with malware/adware to provide Adversary-in-the-Middle capability for intercepting information transmitted over secure TLS/SSL communications.[3]

Root certificates (and their associated chains) can also be cloned and reinstalled. Cloned certificate chains will carry many of the same metadata characteristics of the source and can be used to sign malicious code that may then bypass signature validation tools (ex: Sysinternals, antivirus, etc.) used to block execution and/or uncover artifacts of Persistence.[4]

In macOS, the Ay MaMi malware uses /usr/bin/security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/malicious/cert to install a malicious certificate as a trusted root certificate into the system keychain.[5]

EnterpriseT1553.004Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Installing a new trusted root certificate can quietly change what a workstation or server believes is safe. For leaders, the risk is not just a certificate change; it can weaken TLS warnings, support credential collection through spoofed sites, enable adversary-in-the-middle interception, or help malicious code appear trusted by signature checks.

Executive priority

Treat trusted root certificate control as a resilience and audit issue across Windows, macOS, and Linux endpoints. Ask whether the organization has an approved root certificate inventory, change-control evidence, and monitoring for unexpected trust store changes. This matters most for identity risk, SOC readiness, incident response scoping, and compliance evidence because unauthorized trust changes can undermine browser warnings, secure communications, and code trust decisions.

Technical view

This is a defense-impairment sub-technique under Subvert Trust Controls for Linux, macOS, and Windows. SOC and IR teams should validate monitoring of OS and application certificate trust stores, especially additions to trusted roots and certificate chains. Relationship context highlights DET0056 as a detection strategy, M1028 Operating System Configuration, and M1054 Software Configuration as mitigation areas. On macOS, the supplied ATT&CK description cites use of /usr/bin/security add-trusted-cert against the System.keychain. On Windows, certutil is related software and should be considered in process and command-line review where available.

Likely telemetry

  • Certificate trust store and system keychain modification events
  • Process execution and command-line telemetry for certificate-management utilities, including macOS security and Windows certutil where present
  • Endpoint file, registry, or configuration-change telemetry tied to trusted root certificate locations
  • Configuration management or asset inventory records showing approved root certificates and baseline drift
  • Browser or application trust store configuration data where applications maintain separate certificate stores

Detection direction

  • Validate DET0056-style coverage for additions or modifications to trusted root certificates rather than relying on malware signatures alone.
  • Compare endpoint trust stores against an approved enterprise baseline and investigate newly added, atypical, or locally installed roots.
  • Tune detections with business context: enterprise TLS inspection, security tooling, software deployment, OEM images, and legitimate certificate rollouts can create expected changes.
  • Correlate certificate installation with process lineage, user context, recent software installation, proxy changes, browser warnings, credential-theft alerts, or adversary-in-the-middle indicators.
  • Include macOS System.keychain activity and Windows certificate utility usage in triage workflows; build equivalent coverage for Linux trust store changes based on local distribution standards.

Mitigation priorities

  • Maintain an approved root certificate inventory and enforce change control for additions to system and application trust stores.
  • Use operating system hardening and configuration management, aligned with M1028, to limit who or what can modify trusted roots.
  • Review software and browser certificate settings, aligned with M1054, especially for applications that maintain their own trust stores.
  • Baseline gold images and supplier-provided systems for atypical pre-installed roots before deployment.
  • During incident response, remove unauthorized roots only after preserving evidence and assessing whether credentials, tokens, or signed artifacts may have been exposed or trusted improperly.
Analyst notes and limits

The technique is material because it can degrade trust decisions that users and security tools depend on. Relationship data shows use by multiple software entries, including Windows and macOS examples, and links the behavior to adversary-in-the-middle and code-signing trust abuse described in the official ATT&CK text.

ATT&CK provides no official detection text for this object in the supplied fields. Detection quality depends on local certificate baselines, endpoint logging depth, application-specific trust store visibility, and the organization’s legitimate certificate-management practices.

Official MITRE ATT&CK definition

Install Root Certificate

Adversaries may install a root certificate on a compromised system to avoid warnings when connecting to adversary controlled web servers. Root certificates are used in public key cryptography to identify a root certificate authority (CA). When a root certificate is installed, the system or application will trust certificates in the root's chain of trust that have been signed by the root certificate.[1] Certificates are commonly used for establishing secure TLS/SSL communications within a web browser. When a user attempts to browse a website that presents a certificate that is not trusted an error message will be displayed to warn the user of the security risk. Depending on the security settings, the browser may not allow the user to establish a connection to the website.

Installation of a root certificate on a compromised system would give an adversary a way to degrade the security of that system. Adversaries have used this technique to avoid security warnings prompting users when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate websites in order to collect login credentials.[2]

Atypical root certificates have also been pre-installed on systems by the manufacturer or in the software supply chain and were used in conjunction with malware/adware to provide Adversary-in-the-Middle capability for intercepting information transmitted over secure TLS/SSL communications.[3]

Root certificates (and their associated chains) can also be cloned and reinstalled. Cloned certificate chains will carry many of the same metadata characteristics of the source and can be used to sign malicious code that may then bypass signature validation tools (ex: Sysinternals, antivirus, etc.) used to block execution and/or uncover artifacts of Persistence.[4]

In macOS, the Ay MaMi malware uses /usr/bin/security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/malicious/cert to install a malicious certificate as a trusted root certificate into the system keychain.[5]

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.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1130 Install Root Certificate Install Root Certificate revoked by this object.
Enterprise T1553 Subvert Trust Controls This object subtechnique of Subvert Trust Controls.
Associated objects

Groups, software, and campaigns

Tool Enterprise

S0160: certutil

certutil is a command-line utility that can be used to obtain certificate authority information and configure Certificate Services. [1]

Windows
Tool Enterprise

S9003: evilginx2

evilginx2 is an open-source adversary-in-the-middle (AiTM) attack framework based on the open-source nginx web server. evilginx2 can be used as a reverse proxy between victims and legitimate web services to intercept and capture credentials, authentication tokens, and session cookies.[1][2][3]

IaaSIdentity ProviderOffice Suite
Malware Enterprise

S0148: RTM

RTM is custom malware written in Delphi. It is used by the group of the same name (RTM). Newer versions of the malware have been reported publicly as Redaman.[1][2]

Windows
Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1054: Software Configuration Enterprise uses · Tool S0160: certutil Enterprise revoked by · Technique T1130: Install Root Certificate Enterprise uses · Malware S0281: Dok Enterprise uses · Malware S0009: Hikit Enterprise uses · Tool S9003: evilginx2 Enterprise subtechnique of · Technique T1553: Subvert Trust Controls Enterprise detects · Detection Strategy DET0056: Detection Strategy for Subvert Trust Controls via Install Root Certificate. Enterprise uses · Malware S0148: RTM Enterprise mitigates · Mitigation M1028: Operating System Configuration Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1054: Software Configuration

Software configuration refers to making security-focused adjustments to the settings of applications, middleware, databases, or other software to mitigate potential threats. These changes help reduce the attack surface, enforce best practices, and protect sensitive data. This mitigation can be implemented through the following measures:

Conduct a Security Review of Application Settings:

- Review the software documentation to identify recommended security configurations. - Compare default settings against organizational policies and compliance requirements.

Implement Access Controls and Permissions:

- Restrict access to sensitive features or data within the software. - Enforce least privilege principles for all roles and accounts interacting with the software.

Enable Logging and Monitoring:

- Configure detailed logging for key application events such as authentication failures, configuration changes, or unusual activity. - Integrate logs with a centralized monitoring solution, such as a SIEM.

Update and Patch Software Regularly:

- Ensure the software is kept up-to-date with the latest security patches to address known vulnerabilities. - Use automated patch management tools to streamline the update process.

Disable Unnecessary Features or Services:

- Turn off unused functionality or components that could introduce vulnerabilities, such as debugging interfaces or deprecated APIs.

Test Configuration Changes:

- Perform configuration changes in a staging environment before applying them in production. - Conduct regular audits to ensure that settings remain aligned with security policies.

*Tools for Implementation*

Configuration Management Tools:

- Ansible: Automates configuration changes across multiple applications and environments. - Chef: Ensures consistent application settings through code-based configuration management. - Puppet: Automates software configurations and audits changes for compliance.

Security Benchmarking Tools:

- CIS-CAT: Provides benchmarks and audits for secure software configurations. - Aqua Security Trivy: Scans containerized applications for configuration issues.

Vulnerability Management Solutions:

- Nessus: Identifies misconfigurations and suggests corrective actions.

Logging and Monitoring Tools:

- Splunk: Aggregates and analyzes application logs to detect suspicious activity.

Mitigation Enterprise

M1028: Operating System Configuration

Operating System Configuration involves adjusting system settings and hardening the default configurations of an operating system (OS) to mitigate adversary exploitation and prevent abuse of system functionality. Proper OS configurations address security vulnerabilities, limit attack surfaces, and ensure robust defense against a wide range of techniques. This mitigation can be implemented through the following measures:

Disable Unused Features:

- Turn off SMBv1, LLMNR, and NetBIOS where not needed. - Disable remote registry and unnecessary services.

Enforce OS-level Protections:

- Enable Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), and Control Flow Guard (CFG) on Windows. - Use AppArmor or SELinux on Linux for mandatory access controls.

Secure Access Settings:

- Enable User Account Control (UAC) for Windows. - Restrict root/sudo access on Linux/macOS and enforce strong permissions using sudoers files.

File System Hardening:

- Implement least-privilege access for critical files and system directories. - Audit permissions regularly using tools like icacls (Windows) or getfacl/chmod (Linux/macOS).

Secure Remote Access:

- Restrict RDP, SSH, and VNC to authorized IPs using firewall rules. - Enable NLA for RDP and enforce strong password/lockout policies.

Harden Boot Configurations:

- Enable Secure Boot and enforce UEFI/BIOS password protection. - Use BitLocker or LUKS to encrypt boot drives.

Regular Audits:

- Periodically audit OS configurations using tools like CIS Benchmarks or SCAP tools.

*Tools for Implementation*

Windows:

- Microsoft Group Policy Objects (GPO): Centrally enforce OS security settings. - Windows Defender Exploit Guard: Built-in OS protection against exploits. - CIS-CAT Pro: Audit Windows security configurations based on CIS Benchmarks.

Linux/macOS:

- AppArmor/SELinux: Enforce mandatory access controls. - Lynis: Perform comprehensive security audits. - SCAP Security Guide: Automate configuration hardening using Security Content Automation Protocol.

Cross-Platform:

- Ansible or Chef/Puppet: Automate configuration hardening at scale. - OpenSCAP: Perform compliance and configuration checks.

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
8b9cc427b5f312ac...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 8b9cc427b5f3…
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.

Open mirrored raw JSON Open MITRE-hosted copy
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]
    Wikipedia Root Certificate

    Wikipedia. (2016, December 6). Root certificate. Retrieved February 20, 2017.

    Open source URL
  2. [2]
    Operation Emmental

    botconf eu. (2014, December 31). David Sancho - Finding Holes in Banking 2FA: Operation Emmental. Retrieved January 4, 2024.

    Open source URL
  3. [3]
    Kaspersky Superfish

    Onuma. (2015, February 24). Superfish: Adware Preinstalled on Lenovo Laptops. Retrieved February 20, 2017.

    Open source URL
  4. [4]
    SpectorOps Code Signing Dec 2017

    Graeber, M. (2017, December 22). Code Signing Certificate Cloning Attacks and Defenses. Retrieved April 3, 2018.

    Open source URL
  5. [5]
    objective-see ay mami 2018

    Patrick Wardle. (2018, January 11). Ay MaMi. Retrieved March 19, 2018.

    Open source URL
  6. [6]
    mitre-attack T1553.004
    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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use