CVE-2026-54121 (Certighost)

This is a proof-of-concept tool to demonstrace CVE-2026-54121 a.k.a Certighost. Read here https://gist.github.com/H0j3n/a5ef2609b5f2944ac2390a191a534c26 for the detailed analysis.

Install dependencies

The proof of concept is a self-contained Python script. It requires impacket, cryptography, pyasn1, asn1crypto, and dnspython.

sudo pip install --break-system-packages git+https://github.com/fortra/impacket.git cryptography pyasn1 asn1crypto pycryptodome dnspython

Run as root because the rogue LDAP and SMB services listen on high privileged ports 389 and 445.

sudo python3 certighost.py -d playground.local -u lowpriv -p 'Password1234' --dc-ip 192.168.1.10

Successful execution writes the target certificate (.pfx) and Kerberos cache (.ccache) to the current directory.

Create a new computer account (e.g. GHOSTABCDEFGH$) or reuse one passed via --computer-name.
Start two rogue listeners: an SMB/LSA server on port 445 and an LDAP server on port 389.
Send a certificate request as that computer account, embedding a custom cdc attribute pointing to a controlled IP (via --listener; optional, auto-detected if omitted) plus an rmd attribute carrying the target DC's DNS name.
The CA connects back to the rogue LSA/LDAP listeners. They authenticate as the created account (validated through the real DC over Netlogon) and answer the CA's lookups with the target DC's identity (sAMAccountName, SID, dNSHostName) instead.
The CA issues a valid certificate belonging to the DC.
The scripts also performs PKINIT with the DC's pfx to request .ccache and NT hash

28 July 2026 — Credits to @GregDurys for the PR fixing the STATUS_NOLOGON_SERVER_TRUST_ACCOUNT issue. certighost now ships a proper in-script hotpatch of the rogue SMB NetLogon path (setting the E bit 0x20 alongside the K bit 0x800 in ParameterControl, per MS-NRPC 2.2.1.4.15), so the exploit works against a CA hosted on a Domain Controller without worrying about installing a different / forked Impacket version.
28 July 2026 — Credits to @Hack0ura for mentioning the request-SAN fix. On a CA that honors request-supplied SANs (EDITF_ATTRIBUTESUBJECTALTNAME2 / ESC6), the certificate request now sets the SAN:dns identity to the target DC's DNS name (rmd_value) instead of the rogue computer's, avoiding KDC_ERR_CLIENT_NAME_MISMATCH at the PKINIT step. On build-from-AD templates the request SAN is ignored, so the change is a safe no-op.