SPN Duplicado Active Directory, Abuso WriteSPN, Degradacion Kerberos: Dentro de CVE-2026-25177 (KerberLoss)

SPN duplicado en Active Directory, abuso de WriteSPN, degradación de Kerberos: tres problemas que la mayoría de los equipos de AD rastrean en tickets separados confluyeron en uno solo el 10 March 2026, cuando Microsoft publicó la corrección para CVE-2026-25177. Shai Laron, investigador de Semperis que la reportó, la bautizó KerberLoss. La versión corta: un principal con pocos privilegios, pero con derecho de escritura sobre un único atributo de un único objeto, podía romper Kerberos para cualquier servicio mapeado a HOST en todo el bosque — y, con un segundo giro del mismo truco, empujar en silencio a los clientes de cualquier servicio hacia NTLM.

Lo que convierte esto en un problema de detección más que de parcheo es la técnica de evasión. El SPN duplicado que rompe el servicio no es un duplicado byte a byte: solo colisiona en la capa Kerberos. Todas las herramientas a las que recurre su runbook — setspn -X, el índice de unicidad de todo el bosque, el evento de Directory Services que se dispara cuando se bloquea un duplicado — comparan cadenas por igualdad, y la igualdad es exactamente lo que el atacante evita.

¿Qué es un SPN duplicado en Active Directory?

Un Service Principal Name (SPN) es la cadena que un cliente Kerberos utiliza para pedirle al KDC un ticket para una instancia de servicio específica — cifs/fileserver.corp.local, http/intranet, MSSQLSvc/db01:1433. Vive en el atributo multivalor servicePrincipalName de la cuenta de usuario o de equipo bajo la cual se ejecuta el servicio. Cuando un cliente quiere hablar con un servicio, construye el SPN, le pide al KDC un ticket de servicio, y el KDC cifra ese ticket con la clave a largo plazo de la cuenta que posee el SPN — la misma clave cuyo compromiso permite la falsificación de Silver Ticket.

Ese diseño solo funciona si el mapeo de SPN a cuenta es una función. Microsoft lo dice explícitamente: "A menos que un servicio use la cuenta de equipo y el SPN HOST, los SPN deben ser únicos en el bosque de AD DS. En un entorno multibosque, el SPN debe ser único en todos los bosques asociados" y "Un SPN solo puede asociarse a una cuenta" (Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error).

Cuando dos cuentas reclaman el mismo SPN, el KDC no tiene base para elegir una clave. La referencia de eventos Kerberos de Microsoft documenta un código de fallo dedicado para esa condición, 0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE, descrito como "Múltiples entradas de principal en la base de datos del KDC… Este error ocurre si existen nombres de principal duplicados. Los nombres de principal únicos son fundamentales para garantizar la autenticación mutua."

Hay una segunda capa que importa aquí. Las cuentas de equipo reciben automáticamente un SPN HOST, y una lista documentada de clases de servicio recae en él. La referencia de setspn de Microsoft las enumera — cifs, http, www, wins, spooler, rpcss, dns, netlogon y unas cuarenta más — y expone la regla de precedencia sin rodeos: "Estos SPN se reconocen para las cuentas de equipo si el equipo tiene un SPN host. A menos que se coloquen explícitamente en los objetos, un SPN host puede sustituir a cualquiera de los SPN mencionados." La equivalencia en sí se expresa en el atributo sPNMappings (CN=SPN-Mappings, ID de atributo 1.2.840.113556.1.4.1347) del objeto NTDS Service, que Microsoft describe como una "lista de nombres principales de servicio (SPN) que muestra la equivalencia entre tipos de SPN."

Semperis resumió la consecuencia en una sola frase: "El algoritmo de búsqueda de SPN siempre busca primero un SPN explícito. El algoritmo busca el alias mapeado del SPN solo si no se encuentra un SPN explícito."

Un SPN explícito, en cualquier punto del bosque, tiene prioridad sobre un mapeo HOST. Esa es la palanca.

SPN Duplicado Active Directory, Abuso WriteSPN, Degradacion Kerberos: Cómo Funciona KerberLoss

Desde Windows Server 2012 R2, los controladores de dominio se niegan a crear un duplicado. La referencia de Microsoft sobre SPN and UPN uniqueness documenta el flujo: el DC consulta el índice servicePrincipalName de todo el bosque — en un Global Catalog, o localmente si el propio DC es un GC — y "si el número de entradas devueltas != 0 -> la escritura falla." Quien realiza la escritura recibe el error extendido 8647 / 0x21C7 ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (los UPN reciben 8648 / 0x21C8), y el DC escribe el evento con ID 2974, origen ActiveDirectory_DomainService, en el registro de Directory Services — un evento que nombra el valor bloqueado y enumera hasta diez objetos que ya lo poseen.

La misma referencia señala que esta comprobación también se ejecuta cuando un SPN se regenera en lugar de escribirse directamente. Cambiar dNSHostName, sAMAccountName, msDS-AdditionalDnsHostName, msDS-AdditionalSamAccountName, serverReferenceBL o userAccountControl hace que AD elimine los SPN antiguos y construya otros nuevos, y "si alguno de los nuevos valores de SPN es un duplicado, la modificación falla."

Semperis sitúa el origen del conjunto actual de tres comprobaciones — unicidad de UPN, unicidad de SPN y unicidad de alias de SPN — en el parche de Microsoft de 2021 para CVE-2021-42282. La comprobación de alias es precisamente la que KerberLoss consigue vencer.

Es un control sólido. Compara cadenas de texto.

La investigación de Semperis atacó la propia comparación. Probando 385 caracteres Unicode invisibles, Laron descubrió que solo 106 eran filtrables mediante consultas LDAP estándar; el resto se trata como espacio en blanco o, en palabras de Semperis, "son completamente ignorados por el DC." Al insertar uno de esos caracteres en una cadena SPN, el índice de unicidad deja de ver una coincidencia — "al usar un carácter invisible y no filtrable e insertarlo en la cadena, NotAdmin puede añadir con éxito el SPN en conflicto."

Las preguntas frecuentes del propio aviso de Microsoft para CVE-2026-25177 describen la misma cadena y su resultado:

MSRC la calificó con CVSS 3.1 base 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, temporal 7.7), severidad Importante, clasificada como CWE-641 (Improper Restriction of Names for Files and Other Resources), con el título Active Directory Domain Services Elevation of Privilege Vulnerability. Ni MSRC ni Semperis documentan qué hace realmente el cambio de código de marzo a nivel interno — trate la corrección como opaca y verifíquela por número de compilación del DC, no por su comportamiento.

El permiso sobre el que se sostiene todo esto no tiene nada de especial. En los objetos de equipo es la escritura validada que Microsoft llama "Validated write to service principal name" (CN=Validated-SPN, Rights-GUID f3a64788-5306-11d1-a9c5-0000f80367c1), delegable desde ADUC y mencionada explícitamente en la documentación de setspn: "También puede delegar el permiso asignando el permiso Validated write to service principal name al usuario o grupo deseado." En cualquier objeto, GenericAll, GenericWrite, o WriteProperty sobre servicePrincipalName cumplen la misma función. Es el mismo tipo de punto de apoyo por escritura de atributo que impulsa Shadow Credentials mediante msDS-KeyCredentialLink — y, según Semperis, bastaba con WriteSPN "sobre cualquier cuenta de equipo o de usuario en el bosque".

La cadena de ataque

Paso 1 — Obtener un objeto en el que se pueda escribir

El atacante necesita acceso de escritura sobre servicePrincipalName en una cuenta. Puede ser un derecho delegado de helpdesk, un grupo de service-desk obsoleto, una delegación de OU demasiado amplia — o un objeto de equipo que el propio atacante haya creado, ya que ms-DS-MachineAccountQuota permite por defecto que cualquier usuario del dominio una hasta diez equipos, y quien crea el objeto obtiene derechos de escritura sobre lo que creó.

Paso 2 — Identificar un objetivo mapeado a HOST

El objetivo es cualquier servicio que dependa del SPN HOST automático en lugar de uno explícito — recursos compartidos de archivos (cifs), IIS (http/www), impresión (spooler), y el resto de la lista documentada. Son precisamente los servicios que no tienen un SPN explícito que defienda su reclamo.

Enumere los SPN registrados de un objetivo — si cifs/SERVERB está ausente, el servicio depende del mapeo HOST y puede ser adelantado:

setspn -L SERVERB

Paso 3 — Plantar el SPN en colisión

El atacante escribe cifs/SERVERB en su propio objeto controlado, con un punto de código invisible incrustado de modo que el índice de todo el bosque vea una cadena diferente. La comprobación de unicidad pasa. No se devuelve ningún error 8647. No se escribe el evento 2974, porque desde la perspectiva del DC no se bloqueó nada.

Paso 4 — El servicio se rompe, y de forma ruidosa

Los clientes ahora solicitan cifs/SERVERB, y el KDC encuentra un SPN explícito que tiene prioridad sobre el mapeo HOST de SERVERB. Emite un ticket — sellado con la clave de la cuenta del atacante. SERVERB no puede descifrarlo y lo rechaza con 0x29 KRB_AP_ERR_MODIFIED, documentado por Microsoft como "The authentication data was encrypted with the wrong key for the intended server."

Observe lo que no ocurrió. Desde el punto de vista del KDC, la solicitud tuvo éxito: se pidió un ticket, se emitió un ticket. No hay un fallo de Kerberos del que recurrir a un fallback, y por lo tanto no hay downgrade a NTLM — solo un servicio que ha dejado de funcionar. Semperis reporta que los usuarios ven mensajes como "The specified network name is no longer available.", "The target account name is incorrect." o "Cannot find path 'path' because it does not exist.", y que el acceso se restablece en el momento en que se elimina el SPN malicioso.

Paso 5 — La misma escritura, un resultado más silencioso: NTLM

El downgrade es un uso distinto del mismo permiso. En lugar de adelantarse a un mapeo HOST, el atacante duplica un SPN que ya existe de forma explícita. Ahora el KDC encuentra dos cuentas que lo poseen, no puede elegir una clave y — en las pruebas de Semperis — devuelve KDC_ERR_S_PRINCIPAL_UNKNOWN. Ese es un fallo Kerberos genuino, que es precisamente lo que un cliente Windows necesita para hacer fallback.

Esta es la variante que debería preocupar. Según Semperis, funciona contra cualquier servicio del bosque, esté o no mapeado a HOST, y "desde la perspectiva del usuario, el acceso normal aparentemente se mantiene." Nadie abre un ticket de soporte. Mientras tanto, todo lo que se construyó bajo el supuesto de que Kerberos es la vía de autenticación — cada defensa contra relay omitida porque "somos Kerberos-only" — ahora depende de los controles contra NTLM relay en su lugar. Donde NTLM se ha deshabilitado, el mismo duplicado produce una interrupción en lugar de un downgrade.

Paso 6 — O bien: desviar la delegación de otra persona

Semperis demuestra un tercer uso, SPN-jacking, adaptado del artículo original de Elad Shamir. Un atacante que ha comprometido una cuenta configurada para delegación restringida, y que posee WriteSPN sobre una cuenta que controla, planta el SPN del servicio intermedio en esa cuenta y ejecuta el flujo S4U completo — obteniendo un ticket sellado con su propia clave. La versión de Shamir también necesitaba WriteSPN sobre la cuenta que poseía el SPN objetivo, para eliminarlo primero; KerberLoss elimina ese requisito. Si su entorno todavía ejecuta los patrones de delegación cubiertos en ataques de delegación Kerberos, esa es la vía que hay que revisar primero.

Detección

Empecemos por un hecho incómodo: los eventos que normalmente anuncian un SPN duplicado son precisamente los que esta técnica está diseñada para evitar.

El evento 5136 es donde se detecta esto. Microsoft lo documenta como generado "cada vez que se modifica un objeto de Active Directory", y contiene exactamente los campos que necesita: ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType (%%14674 Value Added, %%14675 Value Deleted) y el SubjectUserSid/SubjectUserName de quien escribió.

Dos requisitos previos, ambos fáciles de pasar por alto. Debe estar habilitada la subcategoría Audit Directory Service Changes, y el objeto necesita una SACL correspondiente: "Para generar este evento, el objeto modificado debe tener una entrada adecuada en la SACL: la auditoría de la acción 'Write' para atributos específicos." Sin la SACL, la subcategoría por sí sola no produce nada.

Cada escritura de SPN, con la identidad del principal que la realizó:

$xpath = "*[System[EventID=5136]] and *[EventData[Data[@Name='AttributeLDAPDisplayName']='servicePrincipalName']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 500 |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    [pscustomobject]@{
      Time      = $_.TimeCreated
      Actor     = ($x.Event.EventData.Data | Where-Object Name -eq 'SubjectUserName').'#text'
      Target    = ($x.Event.EventData.Data | Where-Object Name -eq 'ObjectDN').'#text'
      Operation = ($x.Event.EventData.Data | Where-Object Name -eq 'OperationType').'#text'
      Value     = ($x.Event.EventData.Data | Where-Object Name -eq 'AttributeValue').'#text'
    }
  }

-- Microsoft Sentinel: escrituras de SPN por parte de principals que no son Tier-0.
-- Los campos de atributo del evento 5136 NO están mapeados a columnas de SecurityEvent
-- (consulte la referencia de la tabla) — extráigalos del XML crudo de EventData.
SecurityEvent
| where EventID == 5136
| extend Attribute = extract(@'Name="AttributeLDAPDisplayName">([^<]*)<', 1, EventData),
         SpnValue  = extract(@'Name="AttributeValue">([^<]*)<', 1, EventData),
         ObjectDN  = extract(@'Name="ObjectDN">([^<]*)<', 1, EventData),
         Operation = extract(@'Name="OperationType">%%(\d+)<', 1, EventData)
| where Attribute =~ "servicePrincipalName"
| where Operation == "14674"               // Valor agregado
| where SubjectUserName !in ("svc_scom$", "svc_sccm$")
| project TimeGenerated, Computer, SubjectUserName, ObjectDN, SpnValue
| order by TimeGenerated desc

Busque directamente el carácter invisible

Esta es la comprobación que no depende de capturar la escritura. Cualquier SPN que contenga un punto de código fuera del ASCII imprimible es anómalo — los SPN legítimos son nombres de host, clases de servicio, puertos y nombres de instancia.

Get-ADObject -LDAPFilter '(servicePrincipalName=*)' -Properties servicePrincipalName -ResultPageSize 500 |
  ForEach-Object {
    $dn = $_.DistinguishedName
    foreach ($spn in $_.servicePrincipalName) {
      if ($spn -notmatch '^[\x20-\x7E]+$') {
        [pscustomobject]@{
          DistinguishedName = $dn
          SPN               = $spn
          CodePoints        = ($spn.ToCharArray() | ForEach-Object { '{0:X4}' -f [int]$_ }) -join ' '
        }
      }
    }
  }

Ejecute igualmente la búsqueda de duplicados a nivel de byte — captura la mala configuración habitual y al atacante poco sofisticado:

setspn -X -F -P
setspn -T * -T contoso -X

Active la telemetría de TGS que probablemente no tiene

La referencia del evento 4769 de Microsoft indica que algunos fallos "solo se reportan cuando se establece el valor de la clave de registro KdcExtraLogLevel", con 0x01: Audit SPN unknown errors. La referencia de registro del KDC documenta el valor por defecto como 2 — lo que significa que el bit 0x1 está desactivado, y los fallos KDC_ERR_S_PRINCIPAL_UNKNOWN no se escriben en el registro de Security en un DC por defecto. El fallo exacto que produce un SPN duplicado es, por defecto, invisible.

En cada DC, mantenga el registro por defecto de PKINIT (0x2) y añada la auditoría de SPN desconocido (0x1) — es decir, 3:

$k = 'HKLM:\SYSTEM\CurrentControlSet\Services\Kdc'
New-Item -Path $k -Force | Out-Null
Set-ItemProperty -Path $k -Name 'KdcExtraLogLevel' -Value 3 -Type DWord
Get-ItemProperty -Path $k -Name 'KdcExtraLogLevel'

Espere volumen, y establezca una línea base durante una semana antes de generar alertas. Microsoft advierte que los fallos 0x20 (tickets caducados) son ruido habitual; los fallos de SPN desconocido son más raros, pero no inexistentes en un bosque saludable.

Remediación

1. Aplique el parche a los controladores de dominio. La corrección se distribuye en la actualización de seguridad de marzo de 2026 — el rollup mensual en Server 2012 y 2012 R2. MSRC enumera lo siguiente por SKU de servidor:

Cuando MSRC enumera dos paquetes para un SKU — Server 2022 y Server 2025 —, el segundo es el paquete de hotpatch (KB5078737 y KB5078736), que se aplica únicamente a instalaciones con hotpatch habilitado. Confirme cuál corresponde a su build exacto antes de desplegar. La vulnerabilidad se corrige en el DC, no en los servidores miembro — una flota totalmente parcheada con un solo DC sin parchear sigue procesando escrituras a través de la ruta sin corregir.

2. Averigüe quién puede escribir SPN. Este es el permiso que todo el ataque necesita, y en la mayoría de los bosques nadie lo ha enumerado nunca. La siguiente consulta reporta los principals no administrativos que poseen Validated-SPN, escritura directa sobre el atributo servicePrincipalName, o escritura genérica sobre cualquier objeto de equipo.

$validatedSpn = [guid]'f3a64788-5306-11d1-a9c5-0000f80367c1'
$schemaNC     = (Get-ADRootDSE).schemaNamingContext
$spnAttrGuid  = [guid](Get-ADObject -SearchBase $schemaNC `
                  -LDAPFilter '(lDAPDisplayName=servicePrincipalName)' `
                  -Properties schemaIDGUID).schemaIDGUID

Get-ADComputer -Filter * -ResultPageSize 500 | ForEach-Object {
  $dn = $_.DistinguishedName
  (Get-Acl "AD:$dn").Access |
    Where-Object {
      $_.AccessControlType -eq 'Allow' -and
      ($_.ObjectType -eq $validatedSpn -or $_.ObjectType -eq $spnAttrGuid -or
       $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite')
    } |
    Where-Object { $_.IdentityReference -notmatch 'SYSTEM|Domain Admins|Enterprise Admins|Administrators' } |
    ForEach-Object {
      [pscustomobject]@{ Object = $dn; Principal = $_.IdentityReference; Rights = $_.ActiveDirectoryRights }
    }
}

Elimine lo que no esté justificado. Preste especial atención a las delegaciones otorgadas a grupos amplios (Authenticated Users, Domain Users, grupos de helpdesk heredados) y a los principals que posean derechos sobre objetos de equipo de Tier 0.

3. Reduzca el conjunto de objetos controlables por un atacante. Establezca ms-DS-MachineAccountQuota en 0 y conceda la unión de equipos mediante un grupo delegado en su lugar. Esto no corrige CVE-2026-25177, pero elimina la vía más fácil para que un usuario ordinario obtenga un objeto que controle por completo.

4. Haga que el downgrade no aterrice en ningún sitio. Que Kerberos falle es un problema de resiliencia; que Kerberos falle hacia NTLM es un problema de seguridad. Exija la firma SMB, aplique la firma LDAP y el channel binding, y empiece a restringir NTLM donde pueda — la vía de auditoría se cubre en ataques de NTLM relay, y el problema hermano de degradación de cifrado en fallback de Kerberos a RC4.

5. Instrumente y luego verifique. Habilite Audit Directory Service Changes, añada una SACL que audite las escrituras sobre servicePrincipalName en sus OU de equipos y de cuentas de servicio, establezca KdcExtraLogLevel en 3, y programe el barrido de SPN no ASCII anterior como una tarea recurrente. Después confirme que el pipeline funciona de extremo a extremo escribiendo un SPN inofensivo en un objeto de prueba y comprobando que el evento 5136 llega a su SIEM — una política de auditoría que no produce eventos es indistinguible de un bosque sin ataques.

6. Revise el fallo vecino. La misma investigación de Semperis reveló CVE-2026-27912 (ResetNightmare), un problema de userPrincipalName y de Kerberos Change Password corregido el 14 April 2026. Si recién ahora está aplicando el parche de marzo, también está recién aplicando el de abril. Ambos están documentados en el artículo de Semperis.

Cómo lo detecta EtcSec

La auditoría de Active Directory de EtcSec se corresponde directamente con las condiciones previas que necesita este ataque, de modo que usted puede responder a "¿estamos expuestos?" sin tener que escribir usted mismo las consultas anteriores.

WRITESPN_ABUSE enumera los principals que poseen acceso de escritura sobre servicePrincipalName — el único permiso que CVE-2026-25177 convierte en una denegación de servicio a escala de todo el bosque. DUPLICATE_SPN y COMPUTER_DUPLICATE_SPN sacan a la luz valores de SPN reclamados por más de un objeto, los duplicados byte a byte que rompen Kerberos, ya sea que un atacante los haya colocado o que lo haya hecho una migración. COMPUTER_WITH_SPNS inventaría qué objetos de equipo llevan SPN explícitos, que es la forma de distinguir un servicio que defiende su propio nombre de uno que depende del mapeo HOST y que, por tanto, puede ser adelantado. DELEGATION_UNKNOWN_TARGET señala configuraciones de delegación restringida que apuntan a SPN que no se resuelven limpiamente — la condición que necesita el SPN-jacking.

Juntas, estas cuatro comprobaciones reconstruyen la superficie de ataque: quién puede escribir, qué ya está en colisión, qué servicios dependen de HOST, y hacia dónde apunta una delegación que no debería. Para la revisión más amplia en la que esto encaja, consulte cómo auditar la seguridad de Active Directory, y para el problema clásico de exposición de SPN, detección y prevención de Kerberoasting.

Fuentes

• Microsoft Security Response Center — CVE-2026-25177, Active Directory Domain Services Elevation of Privilege Vulnerability (CVSS 3.1 8.8, CWE-641, publicado el 10 March 2026)
• Semperis — Identity Crisis: Novel Vulnerabilities Leading to Kerberos Downgrade, DoS, and Full Domain Takeover, Shai Laron, 5 August 2026
• Microsoft Learn — SPN and UPN uniqueness (evento 2974, errores 8647/8648)
• Microsoft Learn — Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error
• Microsoft Learn — setspn (clases de servicio mapeadas a HOST, -X, -F, delegación de Validated-SPN)
• Microsoft Learn — Validated-SPN validated write (Rights-GUID f3a64788-5306-11d1-a9c5-0000f80367c1)
• Microsoft Learn — SPN-Mappings attribute
• Microsoft Learn — 5136(S) A directory service object was modified
• Microsoft Learn — 4769(S, F) A Kerberos service ticket was requested (tabla de códigos de fallo)
• Microsoft Learn — Registry entries about Kerberos protocol and KDC (KdcExtraLogLevel, valor por defecto 2)
• Microsoft Learn — Azure Monitor Logs reference: SecurityEvent (lista de columnas detrás de la consulta de Sentinel)
• Semperis — SPN-jacking: An Edge Case in WriteSPN Abuse, Elad Shamir