SPN Duplicado Active Directory, Abuso WriteSPN, Downgrade Kerberos: Por Dentro da CVE-2026-25177 (KerberLoss)

SPN duplicado Active Directory, abuso WriteSPN, downgrade Kerberos — três problemas que a maioria das equipes de AD acompanha em três tickets separados colidiram em um único em 10 de março de 2026, quando a Microsoft lançou a correção para a CVE-2026-25177. O pesquisador da Semperis Shai Laron, que a reportou, batizou-a de KerberLoss. Resumindo: um principal com privilégios baixos que detivesse o direito de escrever um único atributo em um único objeto podia quebrar o Kerberos para qualquer serviço mapeado por HOST na floresta — e, com um segundo giro do mesmo truque, empurrar silenciosamente os clientes de qualquer serviço para NTLM.

O que torna isto um problema de detecção em vez de um problema de patch é a técnica de bypass. O SPN duplicado que quebra o serviço não é um duplicado byte a byte. Ele apenas colide na camada Kerberos. Toda ferramenta que o seu runbook usa — setspn -X, o índice de unicidade de toda a floresta, o evento do Directory Services disparado quando um duplicado é bloqueado — compara strings por igualdade, e é exatamente essa igualdade que o atacante contorna.

O Que É um SPN Duplicado no Active Directory

Um Service Principal Name é a string que um cliente Kerberos usa para pedir ao KDC um ticket para uma instância específica de serviço — cifs/fileserver.corp.local, http/intranet, MSSQLSvc/db01:1433. Ele reside no atributo multivalorado servicePrincipalName da conta de usuário ou computador sob a qual o serviço é executado. Quando um cliente quer falar com um serviço, ele constrói o SPN, pede ao KDC um ticket de serviço, e o KDC cifra esse ticket com a chave de longo prazo da conta que detém o SPN — a mesma chave cuja comprometimento habilita a falsificação de Silver Ticket.

Esse design só funciona se o mapeamento de SPN para conta for uma função. A Microsoft é explícita: "A menos que um serviço use a conta de computador e o SPN HOST, os SPNs devem ser únicos na floresta do AD DS. Em um ambiente com múltiplas florestas, o SPN deve ser único em todas as florestas associadas" e "Um SPN só pode estar associado a uma conta" (Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error).

Quando duas contas reivindicam o mesmo SPN, o KDC não tem base para escolher uma chave. A referência da Microsoft sobre eventos Kerberos documenta um código de falha dedicado para essa condição, 0x8 KDC_ERR_PRINCIPAL_NOT_UNIQUE, descrito como "Múltiplas entradas de principal no banco de dados do KDC… Este erro ocorre quando existem nomes de principal duplicados. Nomes de principal únicos são cruciais para garantir a autenticação mútua."

Há uma segunda camada importante aqui. Contas de computador recebem automaticamente um SPN HOST, e uma lista documentada de classes de serviço recorre a ele por padrão. A referência setspn da Microsoft as lista — cifs, http, www, wins, spooler, rpcss, dns, netlogon e cerca de quarenta outras — e declara a regra de precedência claramente: "Esses SPNs são reconhecidos para contas de computador se o computador tiver um SPN host. A menos que sejam colocados explicitamente em objetos, um SPN host pode substituir qualquer um dos SPNs mencionados." A equivalência em si é expressa no atributo sPNMappings (CN=SPN-Mappings, ID de atributo 1.2.840.113556.1.4.1347) do objeto NTDS Service, que a Microsoft descreve como contendo "uma lista de Service Principal Names (SPN) que mostra a equivalência entre tipos de SPN."

A Semperis resumiu a consequência em uma frase: "O algoritmo de busca de SPN sempre procura primeiro por um SPN explícito. O algoritmo só procura pelo alias mapeado do SPN se um SPN explícito não for encontrado."

Um SPN explícito, em qualquer lugar da floresta, tem precedência sobre um mapeamento HOST. Essa é a alavanca.

SPN Duplicado Active Directory, Abuso WriteSPN, Downgrade Kerberos: Como Funciona o KerberLoss

Desde o Windows Server 2012 R2, os controladores de domínio recusam-se a criar um duplicado. A referência da Microsoft SPN and UPN uniqueness documenta o fluxo: o DC consulta o índice servicePrincipalName de toda a floresta — em um Global Catalog, ou localmente se o DC for ele próprio um GC — e "Se o número de entradas retornadas != 0 -> a escrita falha." O chamador recebe o erro estendido 8647 / 0x21C7 ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (UPNs recebem 8648 / 0x21C8), e o DC grava o evento ID 2974, fonte ActiveDirectory_DomainService, no log Directory Services — um evento que nomeia o valor bloqueado e lista até dez objetos que já o detêm.

A mesma referência observa que essa verificação também roda quando um SPN é regenerado em vez de escrito diretamente. Alterar dNSHostName, sAMAccountName, msDS-AdditionalDnsHostName, msDS-AdditionalSamAccountName, serverReferenceBL ou userAccountControl faz com que o AD apague os SPNs antigos e construa novos, e "Se algum dos novos valores de SPN for um duplicado, falhamos a modificação."

A Semperis data o conjunto atual de três verificações — unicidade de UPN, unicidade de SPN e unicidade de alias de SPN — do patch de 2021 da Microsoft para a CVE-2021-42282. A verificação de alias é exatamente a que o KerberLoss derrota.

É um controle sólido. Ele compara strings.

A pesquisa da Semperis atacou a própria comparação. Testando 385 caracteres Unicode invisíveis, Laron descobriu que apenas 106 eram filtráveis via consultas LDAP padrão; o restante ou é tratado como espaço em branco ou, nas palavras da Semperis, "completamente ignorado pelo DC." Ao inserir um desses caracteres em uma string de SPN, o índice de unicidade deixa de ver uma correspondência — "usando um caractere invisível e não filtrável inserido na string, NotAdmin consegue adicionar o SPN conflitante com sucesso."

O próprio FAQ do aviso da Microsoft para a CVE-2026-25177 descreve a mesma cadeia e seu resultado:

O MSRC avaliou-a em 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), severidade Important, classificada como CWE-641 (Improper Restriction of Names for Files and Other Resources), com o título Active Directory Domain Services Elevation of Privilege Vulnerability. Nem o MSRC nem a Semperis documentam o que a mudança de código de março realmente faz internamente — trate a correção como opaca e verifique-a pelo número de build do DC, não pelo comportamento.

A permissão sobre a qual tudo isso se apoia é banal. Em objetos de computador, é o direito de escrita validada que a Microsoft chama de "Validated write to service principal name" (CN=Validated-SPN, Rights-GUID f3a64788-5306-11d1-a9c5-0000f80367c1), delegável no ADUC e mencionado explicitamente na documentação do setspn: "Você também pode delegar essa permissão atribuindo a permissão Validated write to service principal name ao usuário ou grupo desejado." Em qualquer objeto, GenericAll, GenericWrite ou WriteProperty sobre servicePrincipalName cumpre a mesma função. Essa é a mesma classe de ponto de apoio por escrita de atributo que alimenta Shadow Credentials via msDS-KeyCredentialLink — e, segundo a Semperis, WriteSPN "em qualquer conta de computador ou usuário na floresta" já era suficiente.

A Cadeia de Ataque

Passo 1 — Obter um objeto com permissão de escrita

O atacante precisa de acesso de escrita a servicePrincipalName em uma conta. Isso pode ser um direito delegado de helpdesk, um grupo de service desk obsoleto, uma delegação de OU excessivamente ampla — ou um objeto de computador que o próprio atacante criou, já que ms-DS-MachineAccountQuota permite por padrão que qualquer usuário do domínio ingresse dez computadores e o criador obtém direitos de escrita sobre o que criou.

Passo 2 — Identificar um alvo mapeado por HOST

O alvo é qualquer serviço que dependa do SPN HOST automático em vez de um SPN explícito — compartilhamentos de arquivos (cifs), IIS (http/www), impressão (spooler) e o restante da lista documentada. Esses são exatamente os serviços que não têm nenhum SPN explícito para defender sua reivindicação.

Listar os SPNs registrados de um alvo — se cifs/SERVERB estiver ausente, o serviço está apoiado no mapeamento HOST e pode ser preemptado:

setspn -L SERVERB

Passo 3 — Plantar o SPN em colisão

O atacante escreve cifs/SERVERB em seu próprio objeto controlado, com um ponto de código invisível embutido, de modo que o índice de toda a floresta veja uma string diferente. A verificação de unicidade passa. Nenhum erro 8647 é retornado. Nenhum evento 2974 é escrito, porque, do ponto de vista do DC, nada foi bloqueado.

Passo 4 — O serviço quebra, ruidosamente

Os clientes agora solicitam cifs/SERVERB, e o KDC encontra um SPN explícito que tem precedência sobre o mapeamento HOST de SERVERB. Ele emite um ticket — selado com a chave da conta do atacante. SERVERB não consegue decifrá-lo e o rejeita com 0x29 KRB_AP_ERR_MODIFIED, documentado pela Microsoft como "Os dados de autenticação foram cifrados com a chave errada para o servidor pretendido."

Note o que não aconteceu. Do ponto de vista do KDC, a solicitação teve sucesso: um ticket foi pedido, um ticket foi emitido. Não há falha Kerberos da qual recuar e, portanto, nenhum fallback para NTLM — apenas um serviço que parou de funcionar. A Semperis relata usuários vendo "The specified network name is no longer available.", "The target account name is incorrect." ou "Cannot find path 'path' because it does not exist.", com o acesso restaurado assim que o SPN malicioso é removido.

Passo 5 — A mesma escrita, um resultado mais silencioso: NTLM

O downgrade é um uso diferente da mesma permissão. Em vez de preemptar um mapeamento HOST, o atacante duplica um SPN que já existe explicitamente. Agora o KDC encontra duas contas que o detêm, não consegue escolher uma chave e — nos testes da Semperis — retorna KDC_ERR_S_PRINCIPAL_UNKNOWN. Essa é uma falha Kerberos genuína, exatamente o que um cliente Windows precisa para fazer o fallback.

Essa é a variante que preocupa. Segundo a Semperis, funciona contra qualquer serviço na floresta, mapeado por HOST ou não, e "do ponto de vista do usuário, o acesso normal aparentemente é mantido." Ninguém abre um chamado. Enquanto isso, tudo que foi construído sobre a suposição de que Kerberos é o caminho de autenticação — toda defesa contra relay ignorada porque "somos Kerberos-only" — agora depende dos controles de relay NTLM em vez disso. Onde o NTLM foi desabilitado, o mesmo duplicado produz uma indisponibilidade em vez de um downgrade.

Passo 6 — Ou: desviar a delegação de outra pessoa

A Semperis demonstra um terceiro uso, SPN-jacking, adaptado do artigo original de Elad Shamir. Um atacante que comprometeu uma conta configurada para delegação restrita, e detém WriteSPN sobre uma conta que controla, planta o SPN do serviço intermediário nessa conta e executa o fluxo S4U completo — coletando um ticket selado com sua própria chave. A versão de Shamir também exigia WriteSPN na conta que detinha o SPN alvo, para removê-lo primeiro; o KerberLoss elimina esse requisito. Se seu ambiente ainda usa os padrões de delegação cobertos em ataques de delegação Kerberos, esse é o caminho a revisar primeiro.

Detecção

Comecemos por um fato incômodo: os eventos que normalmente denunciam um SPN duplicado são exatamente os que essa técnica foi desenhada para evitar.

O evento 5136 é onde isso é capturado. A Microsoft documenta que ele é gerado "toda vez que um objeto do Active Directory é modificado", e carrega exatamente os campos de que você precisa: ObjectDN, ObjectClass, AttributeLDAPDisplayName, AttributeValue, OperationType (%%14674 valor adicionado, %%14675 valor removido) e o SubjectUserSid/SubjectUserName de quem escreveu.

Dois pré-requisitos, ambos fáceis de errar. A subcategoria Audit Directory Service Changes precisa estar habilitada, e o objeto precisa de uma SACL correspondente: "Para gerar este evento, o objeto modificado deve ter uma entrada apropriada na SACL: a auditoria da ação 'Write' para atributos específicos." Sem a SACL, a subcategoria sozinha não produz nada.

Toda escrita de SPN, com a identidade do principal que a fez:

$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: escritas de SPN por principais que não são Tier 0.
-- Os campos de atributo do 5136 NAO estao mapeados para colunas do SecurityEvent
-- (veja a referencia da tabela) — extraia-os do XML bruto do 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 adicionado
| where SubjectUserName !in ("svc_scom$", "svc_sccm$")
| project TimeGenerated, Computer, SubjectUserName, ObjectDN, SpnValue
| order by TimeGenerated desc

Caçar diretamente o caractere invisível

Esta é a verificação que não depende de capturar a escrita. Qualquer SPN contendo um ponto de código fora do ASCII imprimível é anômalo — SPNs legítimos são hostnames, classes de serviço, portas e nomes de instância.

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 ' '
        }
      }
    }
  }

Execute a busca de duplicatas em nível de byte de qualquer forma — ela captura a má configuração comum e o atacante pouco sofisticado:

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

Ativar a telemetria de TGS que provavelmente você não tem

A referência da Microsoft para o evento 4769 afirma que algumas falhas "só são reportadas se você definir o valor da chave de registro KdcExtraLogLevel", com 0x01: Audit SPN unknown errors. A referência de registro do KDC documenta o valor padrão como 2 — o que significa que o bit 0x1 está desligado, e falhas KDC_ERR_S_PRINCIPAL_UNKNOWN não são gravadas no log Security em um DC padrão. A falha exata que um SPN duplicado produz é, por padrão, invisível.

Em todo DC, mantenha o logging padrão de PKINIT (0x2) e adicione a auditoria SPN-unknown (0x1) — o que dá 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 volume, e estabeleça uma linha de base por uma semana antes de alertar. A Microsoft avisa que falhas 0x20 (tickets expirados) são ruído de fundo rotineiro; falhas SPN-unknown são mais raras, mas não zero em uma floresta saudável.

Remediação

1. Corrigir os controladores de domínio. A correção vem na atualização de segurança de março de 2026 — o rollup mensal para Server 2012 e 2012 R2. O MSRC lista o seguinte por SKU de servidor:

Onde o MSRC lista dois pacotes para um SKU — Server 2022 e Server 2025 — o segundo é o pacote hotpatch (KB5078737 e KB5078736), que se aplica apenas a instalações habilitadas para hotpatch. Confirme qual se aplica ao seu build exato antes de implantar. A vulnerabilidade é corrigida no DC, não nos servidores membros — uma frota totalmente corrigida com um único DC não corrigido ainda processa escritas pelo caminho não corrigido.

2. Descobrir quem pode escrever SPNs. Essa é a permissão de que todo o ataque precisa, e na maioria das florestas ninguém jamais a enumerou. A consulta abaixo reporta principais não administrativos que detêm Validated-SPN, escrita direta no atributo servicePrincipalName, ou escrita genérica sobre qualquer objeto de computador.

$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 }
    }
}

Remova o que não for justificado. Preste atenção especial a delegações concedidas a grupos amplos (Authenticated Users, Domain Users, grupos de helpdesk legados) e a principais que detêm direitos sobre objetos de computador Tier 0.

3. Reduzir o conjunto de objetos controláveis por um atacante. Defina ms-DS-MachineAccountQuota como 0 e conceda o ingresso de máquinas por meio de um grupo delegado. Isso não corrige a CVE-2026-25177, mas remove a forma mais fácil de um usuário comum obter um objeto que controla totalmente.

4. Fazer o downgrade não pousar em lugar nenhum. O Kerberos falhar é um problema de resiliência; o Kerberos falhar para dentro do NTLM é um problema de segurança. Exija assinatura SMB, imponha assinatura LDAP e channel binding, e comece a restringir o NTLM onde puder — o caminho de auditoria está coberto em ataques de relay NTLM, e o irmão de downgrade de criptografia deste problema em fallback do Kerberos RC4.

5. Instrumentar, depois verificar. Habilite Audit Directory Service Changes, adicione uma SACL auditando escritas em servicePrincipalName em suas OUs de computadores e contas de serviço, defina KdcExtraLogLevel como 3, e agende a varredura de SPNs não ASCII acima como uma tarefa recorrente. Depois confirme que o pipeline funciona de ponta a ponta escrevendo um SPN inofensivo em um objeto de teste e verificando se o 5136 chega ao seu SIEM — uma política de auditoria que não produz eventos é indistinguível de uma floresta sem ataques.

6. Revisar a falha vizinha. A mesma pesquisa da Semperis divulgou a CVE-2026-27912 (ResetNightmare), um problema de userPrincipalName e Kerberos Change Password corrigido em 14 de abril de 2026. Se você só está aplicando março agora, também só está aplicando abril agora. Ambos estão documentados no artigo da Semperis.

Como a EtcSec Detecta Isso

O audit de Active Directory da EtcSec mapeia diretamente as pré-condições de que este ataque precisa, para que você possa responder "estamos expostos" sem precisar escrever as consultas acima você mesmo.

WRITESPN_ABUSE enumera os principais que detêm acesso de escrita a servicePrincipalName — a única permissão que a CVE-2026-25177 transforma em uma negação de serviço para toda a floresta. DUPLICATE_SPN e COMPUTER_DUPLICATE_SPN revelam valores de SPN reivindicados por mais de um objeto, os duplicados byte a byte que quebram o Kerberos, seja um atacante que os colocou ali ou uma migração. COMPUTER_WITH_SPNS inventaria quais objetos de computador carregam SPNs explícitos, o que permite distinguir um serviço que defende seu próprio nome de um que depende do mapeamento HOST e, portanto, pode ser preemptado. DELEGATION_UNKNOWN_TARGET sinaliza configurações de delegação restrita que apontam para SPNs que não se resolvem de forma limpa — a condição de que o SPN-jacking precisa.

Juntas, essas quatro verificações reconstroem a superfície de ataque: quem pode escrever, o que já está em colisão, quais serviços dependem de HOST e para onde a delegação aponta quando não deveria. Para a revisão mais ampla em que isto se encaixa, veja como auditar a segurança do Active Directory, e para o problema clássico de exposição de SPN, detecção e prevenção de Kerberoasting.

Fontes

• Microsoft Security Response Center — CVE-2026-25177, Active Directory Domain Services Elevation of Privilege Vulnerability (CVSS 3.1 8.8, CWE-641, lançada em 10 de março de 2026)
• Semperis — Identity Crisis: Novel Vulnerabilities Leading to Kerberos Downgrade, DoS, and Full Domain Takeover, Shai Laron, 5 de agosto de 2026
• Microsoft Learn — SPN and UPN uniqueness (evento 2974, erros 8647/8648)
• Microsoft Learn — Kerberos Generates KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE Error
• Microsoft Learn — setspn (classes de serviço mapeadas por HOST, -X, -F, delegação 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 (tabela de códigos de falha)
• Microsoft Learn — Registry entries about Kerberos protocol and KDC (KdcExtraLogLevel, valor padrão 2)
• Microsoft Learn — Azure Monitor Logs reference: SecurityEvent (lista de colunas por trás da consulta Sentinel)
• Semperis — SPN-jacking: An Edge Case in WriteSPN Abuse, Elad Shamir