
CVE-2026-54121 (Certighost) PoC d'usurpation d'identité de DC AD CS. Gestion des SAN corrigée + réutilisation de compte compatible MAQ.
Un fork fonctionnel de l'outil de preuve de concept pour CVE-2026-54121, également connu sous le nom de Certighost. Recherche originale et PoC par @H0j3n et @aniqfakhrul, analyse détaillée sur :
Ce fork corrige la gestion du SAN qui empêchait PKINIT de réussir sur les autorités de certification (CA) qui honorent le SAN demandé, durcit l'analyse de --target-san, et retravaille la gestion du compte machine afin de ne plus épuiser le quota ms-DS-MachineAccountQuota.
Exécuter en root car les services LDAP et SMB malveillants nécessitent les ports privilégiés 389 et 445.
sudo python3 certighost.py -d playground.local -u lowpriv -p 'Password1234' --dc-ip 192.168.1.10
Une fois l'exécution terminée avec succès, le certificat cible (.pfx) et le cache Kerberos (.ccache) sont écrits dans le répertoire de travail courant.
CERTIGHOST$, créé lors de la première exécution) ou utilise celui spécifié via --computer-name.cdc personnalisé pointant vers une IP contrôlée (via --listener ; optionnel, auto-détecté s'il est omis) ainsi qu'un attribut rmd contenant le nom DNS du contrôleur de domaine cible..ccache et le hash NT.L'original construisait le SAN du certificat à la fois dans l'extension subjectAltName de la CSR et dans l'attribut de requête SAN:dns= avec le nom d'hôte du compte machine malveillant au lieu du FQDN du contrôleur de domaine cible. Sur une CA qui honore le SAN demandé, le certificat émis portait donc le dNSHostName du compte malveillant, si bien que PKINIT le mappait vers le mauvais principal et échouait avec :
KDC_ERR_CLIENT_NAME_MISMATCH(Reserved for PKINIT)
Le SAN utilise désormais le dNSHostName du contrôleur de domaine cible (rmd_value / target_dns), ce qui est ce sur quoi PKINIT mappe un compte machine. Le certificat émis présente maintenant DNS:<dc>.<domain> et l'AS-REQ se conclut en tant que le contrôleur de domaine.
--target-san robuste--target-san accepte désormais MEEREEN, MEEREEN$, ou le FQDN meereen.essos.local (correspondance par sAMAccountName ou dNSHostName), au lieu de seulement la forme courte NAME.
L'original créait un nouveau compte aléatoire GHOST********$ à chaque exécution. Comme les comptes machine créés via le quota ms-DS-MachineAccountQuota sont possédés par les admins du domaine (et non par le créateur), un utilisateur à faibles privilèges ne peut pas les supprimer, si bien que des exécutions répétées épuisaient rapidement le quota (10 par défaut) avec des comptes orphelins.
Ce fork réutilise un seul compte stable (CERTIGHOST$, créé uniquement s'il n'existe pas déjà), de sorte que le quota ne croît jamais et qu'il n'y a rien à nettoyer entre les exécutions.
Lorsque le compte est créé pour la première fois, le script affiche un avertissement indiquant qu'il est laissé dans l'AD :
[!] WARNING: computer account CERTIGHOST$ was created and is left in AD.
Le compte reste disponible pour être réutilisé lors des exécutions suivantes. Pour le supprimer complètement, supprimez-le avec un admin de domaine (le propriétaire de l'objet) :
Get-ADComputer CERTIGHOST | Remove-ADComputer -Confirm:$false
impacketcryptography, pyasn1, asn1crypto, pycryptodomexUniquement à des fins de tests de sécurité autorisés et d'éducation. Utilisez-le uniquement contre des systèmes pour lesquels vous avez une autorisation explicite de test.