Subvert Trust Controls: 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 a man-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]

ID: T1553.004
Sub-technique of:  T1553
Tactic: Defense Evasion
Platforms: Linux, Windows, macOS
Permissions Required: Administrator, User
Data Sources: Digital certificate logs, SSL/TLS inspection
Defense Bypassed: Digital Certificate Validation
CAPEC ID: CAPEC-479
Contributors: Itzik Kotler, SafeBreach; Matt Graeber, @mattifestation, SpecterOps; Red Canary; Travis Smith, Tripwire
Version: 1.0
Created: 21 February 2020
Last Modified: 19 March 2020

Procedure Examples

Name Description
certutil

certutil can be used to install browser root certificates as a precursor to performing man-in-the-middle between connections to banking websites. Example command: certutil -addstore -f -user ROOT ProgramData\cert512121.der.[6]

Dok

Dok installs a root certificate to aid in man-in-the-middle actions.[7]

Hikit

Hikit uses certmgr.exe -add GlobalSign.cer -c -s -r localMachine Root and certmgr.exe -add GlobalSign.cer -c -s -r localMachineTrustedPublisher to install a self-generated certificate to the local trust store as a root CA and Trusted Publisher.[8]

RTM

RTM can add a certificate to the Windows store.[9][10]

Mitigations

Mitigation Description
Operating System Configuration

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. [4]

Software Configuration

HTTP Public Key Pinning (HPKP) is one method to mitigate potential man-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. [11]

Detection

A system's root certificates are unlikely to change frequently. Monitor new certificates installed on a system that could be due to malicious activity. [4] Check pre-installed certificates on new systems to ensure unnecessary or suspicious certificates are not present. Microsoft provides a list of trustworthy root certificates online and through authroot.stl. [4] The Sysinternals Sigcheck utility can also be used (sigcheck[64].exe -tuv) to dump the contents of the certificate store and list valid certificates not rooted to the Microsoft Certificate Trust List. [12]

Installed root certificates are located in the Registry under HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\Root\Certificates\ and [HKLM or HKCU]\Software[\Policies]\Microsoft\SystemCertificates\Root\Certificates\. There are a subset of root certificates that are consistent across Windows systems and can be used for comparison: [13]

  • 18F7C1FCC3090203FD5BAA2F861A754976C8DD25
  • 245C97DF7514E7CF2DF8BE72AE957B9E04741E85
  • 3B1EFD3A66EA28B16697394703A72CA340A05BD5
  • 7F88CD7223F3C813818C994614A89C99FA3B5247
  • 8F43288AD272F3103B6FB1428485EA3014C0BCFE
  • A43489159A520F0D93D032CCAF37E7FE20A8B419
  • BE36A4562FB2EE05DBB3D32323ADF445084ED656
  • CDD4EEAE6000AC7F40C3802C171E30148030C072

References