Un usuari de domini normal —d'aquells que només poden imprimir i obrir el correu— podia, amb un compte qualsevol i sense permisos d'administrador, fer-se passar per un Domain Controller i sortir-ne amb les claus de tot el domini. Es diu Certighost, és la CVE-2026-54121, i no va ser una fallada del kernel ni un 0-day exòtic: va ser la part de Windows que emet confiança —els certificats— fiant-se de qui no havia de fiar-se.
Microsoft el va corregir al Patch Tuesday del 14 de juliol de 2026. Els investigadors que el van trobar —H0j3n i Aniq Fakhrul— van publicar el 24 de juliol un PoC completament funcional. És a dir: fa deu dies que el pedaç està disponible i ara hi ha codi públic que l'explota. Si el teu directori actiu té una CA integrada (i molts en tenen sense saber-ho), aquest post és el teu pla del dia.
Certighost en una frase (i per què fa tant de mal)
Active Directory Certificate Services (AD CS) és l'autoritat de certificació que moltes empreses munten dins del seu domini Windows. En emetre un certificat, si la CA no aconsegueix tota la informació de l'entitat final, el protocol d'inscripció permet un mecanisme de reserva anomenat chase: el sol·licitant pot aportar uns atributs —cdc (quin servidor de directori consultar) i rmd (quin objecte de màquina resoldre)— perquè la CA vagi a buscar les dades que li falten.
La fallada: la CA seguia el host que li passava el sol·licitant sense comprovar abans que fos un Domain Controller de veritat. L'atacant aixecava serveis LDAP i SMB falsos, responia amb la identitat d'un DC real (el seu SID i el seu nom), i la CA signava aquesta identitat al certificat. Amb un certificat que diu "soc un Domain Controller", la resta és de manual: una credencial Kerberos amb drets de replicació, un DCSync per treure el hash del compte krbtgt i, amb això, control total del domini. Microsoft el va classificar com a autorització indeguda amb un CVSS de 8,8.
El detall que ho fa tan accessible: l'atacant necessitava un compte de màquina per donar identitat vàlida, i aquí entra una altra peça. Per defecte, qualsevol usuari del domini pot crear fins a 10 comptes de màquina (l'atribut ms-DS-MachineAccountQuota val 10). No cal ser administrador de res. Només tenir un usuari i ser a la xarxa.
Això no és un bug solt: AD CS fa anys que és la drecera preferida
Si Certighost et sona d'alguna cosa, és perquè no és el primer. Des que el 2021 SpecterOps va publicar la primera família de tècniques d'escalada d'AD CS —avui ampliada fins a les ESC1–ESC16—, l'autoritat de certificació s'ha convertit en un dels camins més nets de "usuari normal" a "administrador del domini". La raó és de fons: la CA és la màquina que fabrica identitat. Qui aconsegueix que emeti un certificat al seu nom —o al d'un DC— no necessita robar cap contrasenya: l'hi signa la mateixa infraestructura de confiança.
I aquí ve la part incòmoda: AD CS se sol muntar una vegada, "perquè el WiFi amb certificat i el VPN funcionin", i després ningú no hi torna a mirar. No surt a l'inventari d'aplicacions, no té un propietari clar, i les seves plantilles de certificat —on viu la major part de les males configuracions— les va tocar algú fa tres anys. El pedaç de Certighost tapa aquest forat; no et diu si la plantilla que permet que un usuari posi el seu propi nom de subjecte (el clàssic ESC1) segueix oberta des del 2019.
El pla del dia: què fer, en aquest ordre
No és una llista de 20 punts. Són cinc decisions, ordenades pel que de veritat redueix el risc:
- 1Aplica el pedaç. L'actualització de juliol de 2026 és la solució definitiva: afegeix una validació (
_ValidateChaseTargetIsDC) que comprova que l'objectiu és un DC real —rebutja IPs literals, noms amb caràcters d'injecció LDAP i exigeix que el compte tingui el flagSERVER_TRUST_ACCOUNT—. Hi ha una mitigació temporal per a qui no pugui pedaçar ja (deshabilitar el chase ambcertutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDCi reiniciarCertSvc), però els mateixos investigadors només la van provar al laboratori: és un torniquet, no la cura. - 2Esbrina si tens AD CS —i quantes CAs—. Sona absurd, però és el pas que més gent es salta. Molts dominis hereten una CA que va muntar un consultor fa anys per a un projecte puntual i que segueix viva, emetent, sense propietari. Si no és al teu inventari, no l'estàs pedaçant ni vigilant.
- 3Baixa
ms-DS-MachineAccountQuotaa 0. Que un usuari normal no pugui crear comptes de màquina talla la primitiva que necessiten Certighost i mitja dotzena d'atacs més (relay NTLM, RBCD…). Només els administradors o comptes delegats haurien d'unir equips al domini. És un canvi d'un valor, gratis, i treu una palanca a un munt de tècniques alhora. - 4Audita les plantilles i els permisos de la CA. Aquí és on viu el risc crònic. Eines com
Certipy(en mode find),LocksmithoPSPKIAuditet revisen la família ESC1–ESC16 i et diuen quina plantilla deixa demanar un certificat amb nom de subjecte arbitrari, qui s'hi pot inscriure i on falta l'aprovació del gestor. El que un atacant fa servir per trobar el forat, tu ho fas servir per tapar-lo abans. - 5Redueix l'exposició i mira els logs correctes. El servidor de la CA i la seva inscripció web no han de ser abastables des de tota la xarxa plana; segmenta'ls. I tingues vigilada l'emissió de certificats i els esdeveniments de replicació de directori (DCSync): una petició de certificat estranya o un DCSync des d'una cosa que no és un DC és exactament el senyal que vols veure a temps.
El que NO faríem
- ✗Desmantellar AD CS en calent per pànic. Mitja xarxa depèn d'aquests certificats (WiFi, VPN, autenticació de màquines). Arrencar-lo de cop trenca més del que arregla. Es pedaça, s'audita i s'ordena; no s'amputa a cegues.
- ✗Donar per tancat el tema amb el pedaç. El pedaç mata Certighost, no les plantilles mal configurades que fa anys que hi són. Aplicar l'actualització i no auditar la CA és canviar el pany de la porta principal deixant la finestra oberta.
- ✗Assumir que "és de Microsoft, ja estarà bé". AD CS és un component que instal·les i configures tu; la seva seguretat depèn de com vas deixar les plantilles i els permisos, no d'una casella del fabricant. La responsabilitat de la configuració és de casa.
El fons de la qüestió: el pla que emet confiança val més que qualsevol servidor
Certighost és un cas més d'un patró que veiem una vegada i una altra: el que de veritat cal protegir no és "un servidor", sinó el sistema que fabrica identitat i confiança —la CA, el controlador de domini, el proveïdor d'identitat—. Un atacant que doblega aquest pla no necessita robar-te res: s'emet a si mateix el permís. Per això el privilegi mínim (que un usuari qualsevol no pugui crear comptes de màquina), la premissa d'assumir la bretxa (vigilar com si ja fossin dins) i auditar la configuració en comptes de confiar en l'estat per defecte no són eslògans de Zero Trust: són la feina.
No tots els nostres clients fan anar AD CS, però els que tenen un directori actiu amb una CA integrada gairebé mai no l'han mirat des que es va muntar. I aquest "gairebé mai" és justament el forat pel qual s'esmunyen aquestes coses.
Fonts (verificades): mecanisme, atributs cdc/rmd, pedaç _ValidateChaseTargetIsDC, mitigació i cronologia (reportat 14-maig, pedaç 14-jul, PoC 24-jul-2026) — cybersecuritynews.com i The Hacker News; PoC original de H0j3n i Aniq Fakhrul — gist de H0j3n; família ESC1–ESC16 i auditoria amb Certipy/Locksmith/PSPKIAudit — recerca pública d'AD CS. CVSS 8,8 i absència d'explotació confirmada a CISA KEV a 24-jul-2026.
Saps què hi ha dins del teu directori actiu —i qui pot fabricar identitat allà dins?
A everyWAN auditem configuracions d'identitat i seguretat sense vendre llicències de ningú: et diem què està mal posat i què mou l'agulla. Revisem la teva postura de ciberseguretat i t'acompanyem en la consultoria per deixar-la ordenada, abans que sigui un incident.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN