ResetNightmare CVE-2026-27912, Kerberos Troca de Senha, Active Directory: Escrever Seu Próprio userPrincipalName É Suficiente Para Redefinir um Domain Admin

O Que É o ResetNightmare CVE-2026-27912 Kerberos Troca de Senha Active Directory

ResetNightmare CVE-2026-27912 Kerberos Troca de Senha Active Directory: esse nome designa uma única falha, e ela é o caminho mais curto, num domínio, entre acesso de escrita numa conta descartável e uma senha de Domain Admin redefinida. O atacante nunca descobre a senha antiga da vítima, nunca faz relay de uma credencial e nunca quebra um hash. Ele simplesmente define uma nova senha numa conta sobre a qual nunca lhe foi delegado nenhum direito.

A falha foi encontrada pelo pesquisador da Semperis Shai Laron e publicada na pesquisa Identity Crisis da empresa, junto com uma segunda vulnerabilidade, separada, que a mesma pesquisa chama de KerberLoss (CVE-2026-25177). A descrição do National Vulnerability Database é sucinta: "Improper authorization in Windows Kerberos allows an authorized attacker to elevate privileges over an adjacent network."

Essa frase esconde a parte interessante. A "autorização inadequada" não é uma verificação de ACL ausente num objeto. É uma verificação de identidade que existe, funciona corretamente e simplesmente nunca é alcançada, porque o protocolo abusado toma um atalho que passa exatamente pelo ponto onde essa verificação está.

Como Funciona, e Por Que a Ausência do TGS-REQ Importa

O Kerberos não tem apenas uma forma de nomear um principal, e o Active Directory rotineiramente usa duas. NT-PRINCIPAL nomeia uma conta pelo seu sAMAccountName. NT-ENTERPRISE a nomeia pelo seu userPrincipalName, o UPN. Um cliente pode colocar qualquer uma das duas formas numa AS-REQ, e o KDC a resolve para uma conta e emite um ticket.

Ataques que abusam dessa ambiguidade não são novos. Em novembro de 2021, a cadeia noPac, CVE-2021-42278 e CVE-2021-42287, permitia que um atacante renomeasse uma conta que controlava, de forma que um ticket emitido para uma identidade pudesse ser resgatado como outra. A correção da Microsoft para o CVE-2021-42287, a KB5008380, lançada em 9 de novembro de 2021, adicionou "novas informações sobre o solicitante original aos PACs dos Kerberos Ticket-Granting Tickets (TGT)", o buffer PAC Requestor. O KDC o utiliza, nas palavras da própria Microsoft, ao "gerar um ticket de serviço Kerberos", para verificar que "a conta que solicitou o TGT é a mesma conta referenciada no ticket de serviço".

Leia isso com atenção, porque o ResetNightmare vive exatamente na brecha que essa correção deixa. O SID do PAC Requestor é validado quando um ticket de serviço é gerado, durante a troca TGS-REQ.

O protocolo de troca de senha do Kerberos não tem TGS-REQ nenhuma.

Definido na RFC 3244 e servido na porta 464, o fluxo kpasswd, a troca de senha, é deliberadamente curto. Um cliente obtém um TGT e vai então diretamente para uma AP-REQ contra o serviço de troca de senha. Não há troca de concessão de ticket intermediária, porque o cliente não está solicitando acesso a um serviço no sentido usual. Ele está apenas apresentando prova de sua própria identidade para trocar uma senha. A Semperis descreve o fluxo como indo diretamente da solicitação do TGT para uma AP-REQ, "sem uma TGS-REQ pelo meio".

Ao pular a TGS-REQ, pula-se junto a validação do PAC Requestor. Nada mais nesse caminho volta a derivar o SID do solicitante a partir do ticket. Assim, um TGT emitido porque um nome NT-ENTERPRISE por acaso resolveu para o próprio objeto do atacante é aceito pelo kpasswd como autoridade sobre qualquer conta para a qual esse nome resolva agora.

O resultado se agrava da mesma forma que sempre acontece com vínculos de identidade quebrados. O atacante define uma senha que ele conhece, numa conta que não é sua, e todo logon subsequente como essa conta é inteiramente legítimo. Compare com shadow credentials, em que o atacante adiciona uma chave em vez de uma senha: mesmo resultado, atributo diferente, e ambos derrubam a suposição de que "o atacante ainda precisa quebrar alguma coisa", suposição sobre a qual boa parte da modelagem de caminhos de ataque do Active Directory ainda se apoia. Os dois também se combinam: a Semperis credita a Andrea Pierini a observação de que o ResetNightmare "também pode ser combinado com a técnica Shadow Credentials, permitindo um caminho de ataque mais furtivo ao abusar de contas de computador com permissão de escrita".

A Cadeia de Ataque

A Semperis publica a cadeia passo a passo. O ponto de virada é o mesmo que fez o noPac funcionar: o nome carregado no ticket é resolvido duas vezes, e o atacante muda para onde ele resolve entre uma e outra. A ordem abaixo não é cosmética: o UPN precisa ser retirado antes da troca de senha, não depois, ou o atacante só redefine a própria senha.

Passo 1 — Apontar o UPN de uma conta controlada para a vítima

O atacante escreve o sAMAccountName da vítima no userPrincipalName de uma conta que já controla, ou de uma que acabou de criar.

Set-ADUser -Identity 'controlledUser' -UserPrincipalName 'da-admin'

Passo 2 — Solicitar um TGT para kadmin/changepw pelo nome enterprise

O atacante solicita um TGT restrito ao SPN kadmin/changepw, usando o tipo de nome NT-ENTERPRISE, fornecendo o nome de usuário da vítima e a senha da conta controlada. Esse SPN pertence ao krbtgt, então, como coloca a Semperis, "um ticket para kadmin/changepw é apenas um TGT com o SPN (sname) alterado". O KDC resolve o nome enterprise através do UPN recém-escrito, encontra o objeto do atacante e retorna um ticket que carrega o nome da vítima, mas o SID do atacante em PAC_REQUESTOR_SID.

Passo 3 — Retirar o UPN, antes de tocar na senha

Este é o passo cuja posição decide se a cadeia sequer escala. O atacante agora altera ou limpa o UPN da conta controlada, "deixando nenhum usuário com o UPN que aparece no ticket". Executar a troca de senha enquanto o UPN ainda está definido faz o nome enterprise continuar resolvendo para o próprio objeto do atacante: a Semperis é explícita ao dizer que fazer isso "redefinirá a senha do UPNUser" e nada mais.

Passo 4 — Conduzir o protocolo de troca de senha

O TGT já emitido é usado para construir uma solicitação de troca de senha via Kerberos, diretamente numa AP-REQ na porta 464. Nenhuma TGS-REQ é emitida, então o SID do PAC Requestor nunca é verificado, e a nova senha cai sobre a vítima real. A Semperis registra o contraste com precisão: reutilizar esse mesmo ticket numa TGS-REQ após a alteração do UPN "resultará num erro KDC_ERR_TGT_REVOKED, devido ao patch do PAC_REQUESTOR_SID, que bloqueia a impersonação. No entanto, ao usar esse ticket para construir a solicitação de troca de senha, a troca de senha funciona."

Passo 5 — Autenticar-se como a vítima

Um novo TGT é solicitado para a conta real da vítima, usando a senha que o atacante acabou de definir, e sem o tipo de nome NT-ENTERPRISE. Ele volta com o tipo de nome NT-PRINCIPAL, o que é a prova de que o ticket pertence ao verdadeiro titular do sAMAccountName. A partir daqui, o atacante detém uma identidade normal, totalmente válida.

A prova de conceito pública embrulha tudo isso numa única função PowerShell. Ela exige o módulo ActiveDirectory e uma cópia do Rubeus, e seu uso publicado é uma única chamada:

Invoke-ResetNightmare -TargetAccount "victim" -TargetNewPassword "NewP@ssw0rd!" -UPNUser "controlledUser" -UPNUserPassword "ControlledP@ss!"

Quem Realmente Consegue Executar Isso, e Quem Não Consegue

É aqui que boa parte da cobertura secundária exagera a falha, por isso vale a pena citar a pesquisa diretamente. A Semperis afirma que a vulnerabilidade "permite uma tomada completa do domínio por um atacante que tenha permissões genéricas de escrita sobre qualquer objeto de usuário ou computador no domínio, ou que consiga criar objetos de usuário ou computador no domínio (excluindo a MachineAccountQuota)".

Duas cláusulas dessa frase merecem destaque, porque juntas definem a barreira real:

• Escrita genérica sobre qualquer objeto de usuário ou computador. Não sobre a vítima. O atacante precisa de acesso de escrita a um objeto que possa apontar para a vítima, o que na maioria dos domínios é uma concessão bem mais comum do que acesso de escrita a uma conta Tier 0.
• Excluindo a MachineAccountQuota. Este é o limite que separa o ResetNightmare do noPac. A capacidade padrão de um usuário autenticado de ingressar dez máquinas no domínio não é suficiente aqui, então "qualquer usuário de domínio por padrão" é o resumo errado para essa CVE.

O próprio FAQ da Microsoft fixa a outra metade da barreira, o vetor de ataque adjacente (AV:A): a exploração "exige que um atacante esteja no mesmo domínio Active Directory restrito que o sistema-alvo". No momento da publicação, o MSRC também registrou a falha como não divulgada publicamente, não explorada, e com avaliação "Exploitation Less Likely" — avaliação feita em abril de 2026, antes da publicação e da prova de conceito existirem.

Há mais uma precondição. A Semperis observa que "o único outro requisito é que a senha do usuário-alvo precise estar suficientemente envelhecida", e observa que o Minimum password age padrão na Default Domain Policy é de 1 dia, então uma conta de administrador real quase sempre vai satisfazer essa condição.

Detecção

O indicador primário apontado pela pesquisa é o Event ID 5136, "um objeto do serviço de diretório foi modificado", filtrado para adições de um userPrincipalName que coincide com o sAMAccountName de uma conta existente. É uma assinatura precisa e de baixo ruído: num domínio saudável, um prefixo de UPN essencialmente nunca deveria colidir com o logon name de um objeto diferente.

No lado da senha, espere 4723 em vez de 4724. A Semperis separa as duas operações de protocolo diretamente, observando que a Microsoft usa os termos "change password" e "set password" "para diferenciar entre um usuário trocando a própria senha e um administrador definindo a senha de um usuário". O ResetNightmare aciona a operação de troca — o que também explica por que a idade mínima de senha do alvo é uma precondição — então o controlador de domínio registra o 4723, "houve uma tentativa de troca de senha de uma conta". O evento 4724 cobre o caminho de redefinição que um administrador ou uma conta de helpdesk delegada percorre. Vale a pena monitorá-lo por si só, mas não é o artefato que essa CVE deixa.

A mesma colisão pode ser caçada retroativamente no estado do diretório, o que vale a pena fazer uma vez mesmo que a auditoria estivesse desligada:

# Todo prefixo de UPN que colide com o sAMAccountName de um objeto diferente
$sam = @{}
Get-ADObject -LDAPFilter '(|(objectClass=user)(objectClass=computer))' -Properties sAMAccountName |
    ForEach-Object { if ($_.sAMAccountName) { $sam[$_.sAMAccountName] = $_.DistinguishedName } }

Get-ADUser -Filter 'userPrincipalName -like "*"' -Properties userPrincipalName |
    Where-Object {
        $prefix = ($_.UserPrincipalName -split '@')[0]
        $sam.ContainsKey($prefix) -and $sam[$prefix] -ne $_.DistinguishedName
    } | Select-Object SamAccountName, UserPrincipalName, DistinguishedName

Remediation

1. Comprove o patch, não presuma. A Semperis é explícita ao afirmar que "a melhor prevenção para essas vulnerabilidades é aplicar o patch em todos os DCs". Um único DC sem patch, ou há muito tempo offline, mantém o domínio explorável, então enumere os números de build em vez de confiar num dashboard de compliance.

Get-ADDomainController -Filter * | Select-Object HostName, OperatingSystem,
    @{n='Build';e={ (Get-CimInstance Win32_OperatingSystem -ComputerName $_.HostName).Version }}

2. Remova a delegação de redefinição de senha fora do Tier 0. A segunda recomendação da pesquisa é que "as organizações devem se ater ao princípio do menor privilégio e monitorar adições anormais de permissões não padrão". O direito certo para auditar é o User-Force-Change-Password, documentado pela Microsoft com o nome de exibição "Reset Password" e o Rights-GUID 00299570-246d-11d0-a768-00aa006e0529.

$resetPwd = [guid]'00299570-246d-11d0-a768-00aa006e0529'
Get-ADUser -Filter * -SearchBase (Get-ADDomain).DistinguishedName | ForEach-Object {
    $dn = $_.DistinguishedName
    (Get-Acl "AD:$dn").Access |
        Where-Object { $_.ObjectType -eq $resetPwd -and $_.AccessControlType -eq 'Allow' } |
        Select-Object @{n='Target';e={$dn}}, IdentityReference, ActiveDirectoryRights
}

3. Restrinja quem pode criar contas. Como o ataque funciona para um atacante que consegue criar objetos de usuário ou computador fora da MachineAccountQuota, revise os direitos delegados de Create Child nas OUs. Delegações concedidas anos atrás para um helpdesk ou uma ferramenta de deployment costumam ser o achado típico aqui, e pertencem à mesma classe de concessão obsoleta coberta na auditoria de ACEs perigosas e SIDs órfãos.

4. Ative a auditoria que torna visível o passo 1 da cadeia. Ative Audit Directory Service Changes e configure SACLs para que escritas de userPrincipalName em objetos de usuário e computador gerem o evento 5136.

5. Não presuma nada sobre a janela de exposição. O patch é de abril de 2026 e a PoC já é pública agora. Se algum DC ficou para trás, trate trocas de senha privilegiadas nesse intervalo como suspeitas: revise eventos 4723 contra alvos Tier 0, com o 4724 ao lado para o caminho de redefinição delegada, e confirme que cada um corresponde a um chamado real de helpdesk. A checklist mais ampla em auditar a segurança do Active Directory e a revisão de Tier 0 em contas privilegiadas, Protected Users e delegação se aplicam diretamente aqui.

A Semperis não indica nenhuma mitigação além de aplicar patch e menor privilégio, e vale deixar esse limite claro. A associação ao Protected Users, em particular, não deve ser vista como proteção contra esse ataque: as proteções que a Microsoft documenta para o grupo bloqueiam NTLM, proíbem DES e RC4 na pré-autenticação Kerberos, vedam delegação constrangida e não constrangida e limitam o tempo de vida do TGT — e nenhuma delas é o que falha aqui. A falha está em como o KDC vincula uma identidade durante a troca de senha, o que também explica por que medidas de hardening voltadas ao roubo de tickets, como a limpeza de delegação Kerberos ou a rotação da senha do krbtgt, são úteis por outros motivos, mas irrelevantes para o CVE-2026-27912.

Como a EtcSec Detecta Isso

O ResetNightmare é um problema que se corrige de uma vez com o patch, mas seu pré-requisito é um problema de permissões que sobrevive a qualquer CVE isolada. A EtcSec audita exatamente essa superfície.

ACL_USER_FORCE_CHANGE_PASSWORD e ACL_FORCECHANGEPASSWORD enumeram todo principal que detém o direito estendido Reset Password, e ACL_GENERICALL revela as concessões de escrita genérica que permitem, em primeiro lugar, que um atacante reescreva o userPrincipalName de outro objeto.

Para equipes que trabalham com uma baseline de compliance, ANSSI_R12_1_FORCE_PWD_RESET_PRIVS sinaliza User-Force-Change-Password concedido fora de contas de sistema, e ANSSI_R12_2_USER_RESTRICTIONS_PRIVS faz o mesmo para User-Account-Restrictions. Ambos mapeiam a pergunta "quem pode agir sobre esta conta", que o CVE-2026-27912 transforma em comprometimento total do domínio. Controladores de domínio mais antigos elevam ainda mais os riscos, o que também torna relevante o fim do suporte do Windows Server 2016.

Fontes

• MSRC — CVE-2026-27912, Windows Kerberos Elevation of Privilege Vulnerability
• NVD — CVE-2026-27912
• Semperis — Identity Crisis: novel vulnerabilities leading to Kerberos downgrade, DoS and full domain takeover
• Semperis-Community/ResetNightmare (proof of concept)
• Microsoft — KB5008380 authentication updates (CVE-2021-42287)
• Microsoft — User-Force-Change-Password extended right
• Microsoft — Event 4723, an attempt was made to change an account's password
• Microsoft — Event 4724, an attempt was made to reset an account's password
• Microsoft — Protected Users security group
• Microsoft — Minimum password age