Introduction

In modern Zero‑Trust environments a Device Trust certificate is the linchpin that provides endpoints the ability to authenticate independently and extends an additional layer of actionable controls. These certificates are typically combined into PKCS #12 (*.p12) bundles and imported into the Windows Certificate Store or macOS Keychain with the non‑exportable private key attribute set. The intention is clear: users should never be able to pull the private key out of the local store.

In practice, however, attackers (or careless insiders) can still attempt to export the private key using native utilities such as certutil.exe on Windows or the security CLI on macOS. Because the export operation leaves an audit trail in system logs, detecting Device Trust certificate exports becomes a realistic and valuable detection use‑case for any SIEM or XDR platform.

This blog walks you through:

• Why non‑exportable flags are not always enough
• The exact commands used to attempt to export on Windows and macOS
• The log events generated by each those commands
• How to translate that knowledge into reusable Sigma detection rules

Device Trust Certificates – The Security Goal and the Reality

A Device Trust certificate forums an endpoint’s identity for an additional layer of authentication and authorization in your environment . When a service receives a TLS client‑certificate handshake it can verify that the device its identity, managed, and security posture.

Administrators usually elect to set the NoExport option when importing with certutil in Windows and/or rely on the -x (non-extractable) option when using security import in macOS. Setting these flags tell the OS to keep the private key inside a protected store and not to write them to disk in clear text.

Why it still matters:

• The protection is enforced at the API level, not at the file‑system level.
• A user with administrative rights can invoke privileged utilities that request the private key from the CryptoAPI (Windows) or Security.framework (macOS).
• Attackers who have already compromised an account often have the same ability to run those utilities or advanced forensics tools

Note: If certificates are not set as non-exportable when loaded into the users certificate store. The user will be able to extract the private key and full key bundle without any additional permissions.

Therefore, detection must focus on the act of attempting an export, not just the presence of a non‑exportable flag.

Threat Scenario – Exporting a Private Key for Lateral Movement

Consider an attacker who has gained local admin rights on a laptop that is enrolled in Device Trust. The attacker’s objectives may include:

1. Steal the private key to impersonate the device when communicating with internal services.
2. Reuse the certificate on another machine to bypass device compliance checks.
3. Exfiltrate the key for later use in a authentication attacks or user impersonation .

Even if the attacker cannot directly read the private key from the store, they attempt to call certutil -exportpfx (Windows) or security export (macOS) to generate a new PKCS #12 bundle. The resulting file can be copied to a USB drive, uploaded to cloud storage, or transmitted over an encrypted tunnel—each step leaving observable footprints.

Export Techniques on Windows

Using certutil.exe

The most common native tool is certutil.exe. Users can attempt export from their local store like:

certutil -exportpfx -p "" MY <Thumbprint> C:\Temp\device-trust.p12

• -p "" supplies an empty password (or a user‑chosen one).
• My is the personal store where Device Trust certificates live.
• <Thumbprint> identifies the exact certificate to export.

If the key was not marked non‑exportable or it was specifically marked as exportable, certutil will still succeed when run under a privileged context because it uses the Cryptographic Service Provider (CSP) API that can request the private key material for an authorized user.

PowerShell Alternative

PowerShell’s Export-PfxCertificate cmdlet also works:

$cert = Get-ChildItem Cert:\CurrentUser\My\<Thumbprint>
Export-PfxCertificate -Cert $cert -FilePath C:\Temp\device-trust.p12 -Password (ConvertTo-SecureString -String "" -AsPlainText -Force)

Both commands generate a *.p12 file that can be moved off the host.

What Gets Logged?

• Windows Security Auditing – Event ID 4688 (A new process has been created) logs the full command line when audit policy Process Creation is enabled.
• Sysmon (if installed) – Event ID 1 captures the same data with additional hashes for the executable.
• Application Logs – certutil may emit an informational entry in the System or Application log, but process creation events are the most reliable source.

Note: The windows certificateservicesclient lifecycle system now also natively creates an event with id 1007 when any certificate is exported from the local certificate store (including Public-only and CA Chain certificates). This means it can commonly be triggered by various applications and can’t be scoped to specific certificates, but there is already a community approved Sigma rule for the event.

Export Techniques on macOS

Using the security CLI

On macOS the security command can read from the login keychain and write a PKCS #12 bundle:

security export -k ~/Library/Keychains/login.keychain-db -t priv -p "" -o /tmp/device-trust.p12

• -k points to the keychain file.
• -t priv requests private keys only.
• -p "" supplies an empty password for the output file (or a user‑chosen one).

If the certificate’s private key is stored in the Secure Enclave, the command may prompt for Touch ID or the user’s password. However, an attacker with a compromised admin session can bypass that prompt by using sudo.

Note: In newer versions of MacOSX the native tools do still respect the non-extractable attribute set when the certificate is imported, even with elevated privileges. But given its just an encrypted db, you can still utilize thrid-party tools like chainbreaker to export the keys with a password and hexdump.

What Gets Logged?

• Unified Logging (os_log) – The subsystem com.apple.security.keychain logs messages such as “Exported private key”.
• Auditd – If audit is enabled (audit -s), an execve record for /usr/bin/security with the export arguments appears.
• Console.app – Shows the same entries, but for automated detection we rely on the log files under /var/log/system.log or the structured logging API.

Note: It may also be possible, even with non-exportable option set, to utilize Mimikatz like mimikatz log "crypto::certificates /export /systemstore:my" exit or Chainbreaker like python -m chainbreaker --export-x509-certificates to extract certificates from the user-space during post exploitable; but that feels like a whole different topic entirely.

Building Detection Rules in Sigma

Sigma is a vendor‑agnostic rule format that can be translated into SPL (Splunk), KQL (Sentinel), Lucene DSL (Elastic) and many others. Below are two examples—one for Windows, one for macOS—targeting the export commands discussed earlier.

Windows Sigma Rule – Detect CertUtil Export

title: Detection of Device Trust Certificate Export via certutil
id: e7c9b1a4-3d6f-4eaa-b5c8-0c2f6a9c1234
status: stable
description: |
  Detects execution of certutil.exe with the -exportpfx flag which is commonly used to extract a Device Trust private key even when it is marked non‑exportable.
author: Michael Contino
date: 2025-11-06
logsource:
  product: windows
  service: sysmon
detection:
  selection_process:
    Image|endswith: '\\certutil.exe'
  selection_export:
    CommandLine|contains: '-exportpfx'
  condition: all of selection_*
fields:
  - CommandLine
  - ParentImage
  - User
level: high
tags:
  - attack.t1552.006   # Unsecured Credentials: Private Keys
  - detection.DeviceTrustExport

If you prefer the native Windows Security log, change service to security and use Event ID 4688 in the detection block.

macOS Sigma Rule – Detect security Export

title: Detection of Device Trust Certificate Export via security CLI
id: a1f4c9e2-7b2a-44d5-a6f3-58c9f2d8b765
status: stable
description: |
  Flags execution of the macOS `security` command with arguments that request export of private keys, indicating an attempt to extract a Device Trust certificate.
author: Michael Contino
date: 2025-11-06
logsource:
  product: macos
  service: auditd
detection:
  selection_process:
    exe|endswith: '/usr/bin/security'
  selection_export:
    cmdline|contains: 'export'
  selection_privkey:
    cmdline|contains: '-t priv'
  condition: all of selection_*
fields:
  - exe
  - cmdline
  - auid
level: high
tags:
  - attack.t1552.006   # Unsecured Credentials: Private Keys
  - detection.DeviceTrustExport

For environments that rely on Unified Logging, replace service with osquery or a custom parser that extracts the com.apple.security.keychain messages.

Converting Sigma to Platform Queries

Most SIEMs provide an online converter (e.g., Sigma Converter at sigmahq.io). Below are quick examples for three popular platforms.

Splunk SPL

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
(Image="*\\certutil.exe" AND CommandLine="* -exportpfx*")

Elastic Lucene DSL

{
  "query": {
    "bool": {
      "must": [
        { "wildcard": { "process.executable": "*certutil.exe" }},
        { "wildcard": { "process.command_line": "*-exportpfx*" }}
      ]
    }
  }
}

Azure Sentinel KQL

Sysmon
| where Image endswith @"\certutil.exe"
| where CommandLine contains "-exportpfx"

Apply the same conversion logic to the macOS rule, swapping process_name for exe and adjusting the field names accordingly.

Attack Flow Diagram – Exporting a Device Trust Certificate

Visualizing the steps helps analysts understand the context of an alert.

Explanation of the flow

1. Compromised Endpoint – The attacker already has local admin or system privileges.
2. Locate Device Trust Cert – Queries the certificate store (certutil -store My or security find‑identity).
3. Export Attempt – Executes a native export tool (Windows or macOS).
4. PKCS12 file written – The private key is now in clear text inside the .p12.
5. Copy to Staging Location – Moves the file to a place where it can be exfiltrated.
6. Exfiltration – Could be a cloud upload, SMB share copy, or USB drop.
7. Attacker Reuses Private Key – The stolen key is used for impersonation, lateral movement, or credential stuffing against services that trust the Device Trust certificate.

Deploying and Tuning Your Rules

Enriching Alerts

When an export is detected, enrich the event with:

• Certificate Thumbprint – Extracted from the command line to correlate with asset inventory.
• Process Hash – Compare against known good binaries (e.g., Microsoft‑signed certutil.exe).
• Endpoint Context – OS version, posture level, logged in user(s), and serial number/UUIDs.

Enrichment enables faster triage: if the exporter is a legitimate admin running from a hardened workstation, you may downgrade the alert. Otherwise, trigger an automated response.

Preventive Controls

Detection is only half of the story. Harden the environment to reduce the chance that an attacker can run the export commands:

Control	Windows	macOS
Set Non-Exportable Options	Ensure you still utilize export blocking options when importing certutil -importPFX [PFXfile] NoExport	Likewise specific the key as non-extractable with the -x when importing security import <p12_path> -x
AppLocker / SRP	Block certutil.exe except for signed admin scripts	Use /usr/sbin/launchd policies to restrict security binary execution
Group Policy	Set Do not allow private key export in PKI templates (doesn’t fully prevent certutil)	Enable Secure Enclave only keys (-T -s) which refuse export without Touch ID
Audit Policies	Enable “Process Creation” and “Credential Access” sub‑categories	Turn on auditd with execve monitoring for /usr/bin/security

Why Detection Complements Non‑Exportable Keys

• Non‑exportable flags protect against casual dumping but do not stop a privileged user from invoking OS APIs that return the private key material.
• Native utilities (certutil.exe, security) are widely available, leaving an audit trail that can be detected by any modern SIEM/XDR platform.
• By crafting Sigma rules focused on command‑line arguments and process creation events, you gain a vendor‑agnostic detection layer that works across Windows and macOS fleets.

Implementing the examples in this post will give your organization an early warning system for detecting Device Trust certificate exports, reducing the risk of credential theft, lateral movement, and unauthorized device impersonation.

Taking Action

1. Deploy the SIEM/XDR rules above into your rule repository.
2. Enable detailed process creation auditing on all Windows endpoints (Event ID 4688) and auditd logging on macOS.
3. Test the detection by intentionally exporting a test certificate in a lab environment – verify that alerts fire with the expected context.
4. Harden your endpoint policies to restrict certutil and security usage to approved admin accounts only.

Stay ahead of attackers and resistant users alike, but understand the “non‑exportable” flag is not always enough. Detecting Device Trust certificate exports gives you the visibility you need to protect the cryptographic foundation of your Zero‑Trust architecture.