FrameworkGuidesModulesRelease NotesAbout

Root CA Abuse: The New Stealth Evasion Technique of 2025–26

Learn how attackers install rogue root certificates to intercept encrypted traffic and sign malicious code, and discover practical detection and hardening measures for certificate trust stores.

Root CA Abuse: The New Stealth Evasion Technique of 2025–26

The certificate trust model is one of the most fundamental assumptions in modern computing. When your browser shows a green padlock, when your operating system accepts a signed driver, when your email client validates S/MIME — all of these depend on the integrity of the root certificate store. In 2025–26, a growing number of attack campaigns have targeted this foundation directly by installing rogue root Certificate Authority (CA) certificates on compromised systems.

A single rogue root CA certificate, once installed, enables the attacker to intercept all TLS-encrypted traffic, sign arbitrary executables as trusted, and create valid client certificates for authentication — all without triggering the certificate validation warnings that users and security tools depend on.

What Changed Recently

Root CA manipulation is not new. Lenovo's Superfish incident in 2015 demonstrated the risk at scale. What is new in 2025–26 is the deliberate, targeted use of root CA abuse as an evasion technique in sophisticated intrusion sets:

  • Post-exploitation persistence — After gaining administrative access, attackers install a rogue root CA to establish a persistent, stealthy capability. Even if the initial access vector is discovered and remediated, the rogue CA persists in the trust store.
  • Code signing evasion — With a trusted root CA, the attacker can sign malicious executables, DLLs, and drivers. These signed binaries pass application whitelisting, SmartScreen, and many EDR reputation checks.
  • TLS interception for credential harvesting — A rogue root CA enables man-in-the-middle interception of HTTPS traffic on the compromised host, capturing credentials, API tokens, and session cookies in cleartext.
  • Supply chain implications — Compromised build systems with rogue root CAs can sign legitimate-looking update packages, distribution archives, and container images.

Why This Is Harder to Detect Than It Seems

Installing a root CA certificate requires administrative privileges, which is a significant barrier. However, once an attacker has admin access (which is the norm in post-exploitation scenarios), the installation is a single command:

certutil -addstore Root malicious-ca.cer

There is no user prompt, no notification, and no built-in logging for this operation in default Windows configurations. The certificate silently joins the trusted root store and immediately takes effect.

How Root CA Abuse Works at a Conceptual Level

TLS Interception

  1. Attacker generates a private CA key pair and self-signed root certificate
  2. The root certificate is installed in the target system's trusted root store
  3. A local proxy or driver intercepts outgoing TLS connections
  4. For each intercepted connection, the proxy generates a certificate for the destination domain, signed by the rogue root CA
  5. The client application trusts the proxy-generated certificate because the root CA is in the trust store
  6. All traffic is decrypted, inspected (or modified), and re-encrypted to the destination

Code Signing

  1. With the rogue root CA's private key, the attacker creates a code signing certificate
  2. Malicious binaries are signed with this certificate
  3. The operating system and security tools validate the signature against the trusted root store and accept it
  4. Signed malware passes SmartScreen, AppLocker publisher rules, and EDR reputation checks

Certificate-Based Authentication

  1. The attacker generates client certificates signed by the rogue CA
  2. If any internal services use certificate-based authentication and trust the compromised store, these certificates provide access
  3. This is particularly dangerous in environments that use mutual TLS (mTLS) for service-to-service communication

Where Defenders Can Observe It

Certificate Store Monitoring

  • Windows Event ID 4868 (Certificate Services) logs certificate operations, but only if Active Directory Certificate Services is involved. Standalone root CA installations via certutil are not logged by default.
  • Sysmon Event ID 12/13/14 (Registry events) can detect modifications to the certificate store registry keys at HKLM\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates\.
  • PowerShell — Get-ChildItem Cert:\LocalMachine\Root enumerates the trusted root store. Compare against a known-good baseline.

Endpoint Telemetry

  • Monitor certutil.exe execution with addstore arguments — this is the most common installation method.
  • Monitor PowerShell commands that write to the certificate store.
  • EDR agents that track registry modifications can alert on writes to the certificate store keys.

Network Indicators

  • TLS certificate anomalies — If a corporate proxy or internal service presents certificates with an issuer that does not match your organization's known CAs, investigate.
  • Certificate Transparency (CT) log monitoring does not directly help here since rogue CAs operate locally, but it complements detection of external certificate abuse.

Common Detection Blind Spots

  1. No baseline of expected root CAs — Most organizations cannot list which root certificates should be in their trust stores. Without a baseline, detecting additions is impossible.
  2. No registry monitoring for certificate store changes — Default Windows audit policies do not log modifications to certificate store registry keys.
  3. Code signing trust is binary — Many security tools check "is this signed?" without validating the issuer chain. A binary signed by a rogue CA passes the "is it signed?" check.
  4. Limited attention to certificate store in incident response — Standard IR runbooks focus on user accounts, scheduled tasks, and services. The certificate store is often overlooked during containment.

Practical Hardening and Monitoring Guidance

For Detection Engineering Teams

  • Monitor certificate store registry keys — Deploy Sysmon or EDR rules that alert on writes to HKLM\SOFTWARE\Microsoft\SystemCertificates\Root\Certificates\ and the equivalent current user paths.
  • Alert on certutil.exe with addstore/delstore — Process creation monitoring for certutil with store-modifying arguments is a high-fidelity detection.
  • Baseline your root store — Export the trusted root store from a known-good system and compare periodically across the fleet. Any additions that are not part of your PKI or recognized public CAs warrant investigation.
  • Validate code signing issuers — When evaluating signed binaries, check the full certificate chain, not just the signature presence. Alert on executables signed by issuers outside your expected set.

For System Administrators

  • Restrict certificate store access — Use Group Policy to limit which administrators can modify the machine certificate store. Implement approval workflows for root CA additions.
  • Deploy Certificate Pinning — For critical internal applications, implement certificate pinning or public key pinning to prevent rogue CA interception.
  • Audit Active Directory Certificate Services — If your organization runs AD CS, audit the CA configuration, certificate templates, and issuance policies. ESC1-ESC8 attack patterns are well-documented.
  • Enforce driver signature policies — Windows HVCI (Hypervisor-Protected Code Integrity) validates kernel driver signatures against a restricted set of trusted CAs, not the full root store.

Lab Testing Context

Root CA abuse is a post-exploitation technique that complements payload delivery and execution. In a lab environment, you can test whether your detection stack catches root CA installation by using the Veil Framework to generate payloads that include certificate store manipulation as a persistence mechanism. Validate your detections against the Veil command-line reference workflows.

Earlier articles in this series covered related evasion themes: process injection, sandbox awareness, and cloud-based C2 all represent techniques that become more dangerous when combined with root CA abuse.

Related Reading

The trust model is the foundation. If the root certificate store is compromised, every encrypted connection, every signed binary, and every certificate-based authentication on that system is suspect. Monitoring your certificate stores is not optional — it is foundational.