TLS works because your system trusts a list of certificate authorities. Add one more entry to that list and every certificate it signs looks legitimate. MITRE ATT&CK technique T1553.004, Install Root Certificate, covers adversaries who do exactly that. The tactic is defense impairment, and it applies to Linux, macOS and Windows.
How attackers use it
Root certificates identify a root certificate authority. When one is installed, the system or application trusts certificates in that root's chain of trust. Normally, a site presenting an untrusted certificate triggers an error, and depending on settings the browser may refuse the connection.
An adversary who installs a root certificate on a compromised system removes that warning for sites they control. MITRE says adversaries have used this to avoid security prompts when compromised systems connect over HTTPS to adversary controlled web servers that spoof legitimate sites in order to collect login credentials.
MITRE describes three further angles worth knowing:
- Pre-installed roots. Atypical root certificates have been pre-installed by a manufacturer or in the software supply chain, and used with malware or adware to provide Adversary-in-the-Middle capability against TLS traffic.
- Cloned chains. Root certificates and their chains can be cloned and reinstalled. Cloned chains carry many of the same metadata characteristics as the source and can sign malicious code that then bypasses signature validation tools such as Sysinternals and antivirus.
- macOS example. MITRE notes the Ay MaMi malware used
/usr/bin/security add-trusted-certagainst the System keychain to install a malicious certificate as a trusted root.
The supply chain point matters. A device can arrive with a bad root already inside, which is why a trust store audit belongs in your baseline checks and not only in incident response.
How to detect it
MITRE lists no data sources on this page. These signals follow from the description:
- Trust store changes. New entries in the Windows root store or in the macOS System keychain. Compare against a known good list.
- Registry writes under certificate store paths on Windows. Sysmon registry events 12 and 13 capture them if your config includes those keys.
- Process activity. On macOS, the
securitycommand invoked withadd-trusted-cert. Process creation logs (Sysmon event 1 on Windows, endpoint telemetry on macOS and Linux) show these invocations. - Certificate errors that vanish. A set of hosts that suddenly stops warning about a known bad site is a sign something now trusts it.
On Linux, trust anchors live in distribution specific locations, so baseline whichever directory your distribution uses and watch it with file integrity monitoring.
How to reduce the risk
MITRE lists two mitigations.
- Operating system configuration. Windows Group Policy can manage root certificates. Setting the
Flagsvalue ofHKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRootsto 1 prevents non-administrator users from installing roots into their own HKCU certificate store. - Software configuration. MITRE cites HTTP Public Key Pinning as one method of countering a mis-issued or fraudulent certificate, by enforcing use of an expected certificate. HPKP itself is a retired browser feature, so apply the principle where you control the client: pin the certificate or public key your application expects for its own back end.
Add two practices of your own. Manage the root store centrally so that any difference from policy is visible. And inspect new hardware and images, since a pre-installed root arrives before your controls do.
Check your own environment
Read-only commands, labeled by platform.
# Windows: list machine and current user roots
Get-ChildItem Cert:\LocalMachine\Root | Select-Object Subject, Thumbprint, NotBefore, NotAfter
Get-ChildItem Cert:\CurrentUser\Root | Select-Object Subject, Thumbprint, NotBefore, NotAfter
# Windows: is the protected roots policy applied?
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots" -ErrorAction SilentlyContinue
# macOS: dump admin level trust settings (read only)
security dump-trust-settings -d
# macOS: list certificates in the System keychain
security find-certificate -a /Library/Keychains/System.keychain
What to look for:
- Roots you cannot match to a vendor or to your own internal CA.
- A current user root store with entries that the machine store does not have.
- Roots with unusually long validity that were added recently.
Quick check
Why does an installed root certificate remove browser warnings for attacker sites?
The system trusts anything chained to an installed root. A certificate signed by the attacker's root therefore validates, and no untrusted certificate error appears.
Which Windows setting stops non-administrators adding roots to their own store?
Setting the Flags value of HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\Root\ProtectedRoots to 1.
