Has obtained a valid SSL/TLS certificate from LetsEncrypt to provide responses to Automatic Certificate Management Environment (ACME) challenges.1
Install Root Certificate T1553.004
- Tactic
- Defense Impairment
- Platforms
- Linux, macOS, Windows
- Version
- 2.0
- Created
- 21 February 2020
- Last modified
- 12 May 2026
- Contributors
- Itzik Kotler, SafeBreach; Matt Graeber, @mattifestation, SpecterOps; Red Canary; Travis Smith, Tripwire
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.
Install Root Certificate MITRE reference T1553.004
5 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Installs a root certificate to aid in Adversary-in-the-Middle actions using the command add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /tmp/filename.12
Can be used to install browser root certificates as a precursor to performing Adversary-in-the-Middle between connections to banking websites. Example command: certutil -addstore -f -user ROOT ProgramData\cert512121.der.1
Installs a self-generated certificate to the local trust store as a root CA and Trusted Publisher.1
All 5 software entries for this technique
Offense vs defense T1553.004
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
How it got here
Adversary activity (campaign spans) over cumulative rule output. Each source is plotted independently from zero, so neither line includes the other. Campaign dates are year-granularity.
Install Root Certificate detection strategy DET0056
MITRE names one behaviour worth catching for this technique and breaks it into 3 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection Strategy for Subvert Trust Controls via Install Root Certificate.
AN0153 · Windows
Detection of unauthorized modifications to Windows root certificate stores by monitoring registry keys, certificate installation processes, and creation of new certificate entries not in baseline trusted lists.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Process CreationDC0032 | WinEventLog:Sysmon | EventCode=1 |
| Windows Registry Key CreationDC0056 | WinEventLog:Sysmon | EventCode=12 |
| Windows Registry Key ModificationDC0063 | WinEventLog:Security | EventCode=4657 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| TrustedRootHashList | Baseline list of root certificate hashes; defenders can tune based on organizational certificate policies. |
| MonitoredProcesses | Processes associated with certificate management that should be flagged if executed by non-admin users or in unusual contexts. |
| TimeWindow | Correlation window for registry modifications, certificate installation, and process creation to strengthen detection. |
AN0154 · Linux
Detection of unexpected additions or modifications to system-wide certificate stores or execution of commands adding certificates to trusted stores.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| File ModificationDC0061 | auditd:SYSCALL | open, write: File modifications under /etc/ssl/certs, /usr/local/share/ca-certificates, or /etc/pki/ca-trust/source/anchors |
| Command ExecutionDC0064 | auditd:EXECVE | execve: Execution of update-ca-certificates or trust anchor modification commands |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| CertificatePaths | Paths monitored for certificate modifications; can be tuned depending on Linux distribution. |
| AdminAccounts | Expected user accounts with privileges to install root certificates; anomalies outside this context are suspicious. |
AN0155 · macOS
Detection of malicious certificate installation via monitoring execution of the security add-trusted-cert command and modifications to system keychains.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| File ModificationDC0061 | macos:osquery | query: Enumeration of root certificates showing unexpected additions |
| Command ExecutionDC0064 | macos:unifiedlog | Execution of /usr/bin/security add-trusted-cert or keychain modifications to System.keychain |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| MonitoredCommands | Commands related to certificate management (e.g., security, profiles) that can be tuned per environment. |
| KeychainBaseline | Baseline of expected certificates in System.keychain to reduce false positives from legitimate enterprise certificates. |
Adversaries may add their own root certificate to the certificate store, to cause the web browser to trust that certificate and not display a security warning when it encounters the previously unseen certificate. This action may be the precursor to malicious activity.
D3FEND techniques
The defensive countermeasure this analytic implements, in MITRE’s D3FEND ontology.
| ID | Name |
|---|---|
| D3-PSA | Process Spawn Analysis |
Data model references
The CAR data model objects, actions and fields the logic reads. Map these to your own schema before implementing.
| Object | Action | Field |
|---|---|---|
| process | create | exe |
| process | create | command_line |
Implementations
Pseudocode is the canonical logic; the rest are CAR’s translations into vendor query languages.
You must be ingesting data that records process activity from your hosts to populate the Endpoint data model in the Processes node. You must also be ingesting logs with both the process name and command line from your endpoints. The command-line arguments are mapped to the "process" field in the Endpoint data model.
| tstats count min(_time) as firstTime values(Processes.process) as process max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process_name=*certutil* (Processes.process=*-addstore*) by Processes.parent_process Processes.process_name Processes.user
Pseudocode implementation of the splunk search below
processes = search Process:Create addstore_commands = filter processes where ( exe =”C:\Windows\System32\certutil.exe” AND command_line="*-addstore*” ) output addstore_commands
Unit tests
CAR’s own validation procedures for this analytic.
Replay the detection [dataset](https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1553.004/atomic_red_team/windows-sysmon.log) using the Splunk attack range with the commands below
["python attack_range.py replay -dn data_dump [--dump NAME_OF_DUMP]"]
execute the atomic test [T1553.004](https://github.com/redcanaryco/atomic-red-team/tree/master/atomics/T1553.004) against a Windows target.
["Invoke-AtomicTest T1553.004"]
Windows Group Policy can be used to manage root certificates and the Flags value of HKLM\\SOFTWARE\\Policies\\Microsoft\\SystemCertificates\\Root\\ProtectedRoots can be set to 1 to prevent non-administrator users from making further root installations into their own HKCU certificate store.
HTTP Public Key Pinning (HPKP) is one method to mitigate potential Adversary-in-the-Middle situations where and adversary uses a mis-issued or fraudulent certificate to intercept encrypted communications by enforcing use of an expected certificate.
Tests from Atomic Red Team (MIT licence) · technique definition