Rotação da Senha krbtgt, Conta de Confiança, Senha de Máquina do Controlador de Domínio: Os Três Segredos do AD que Nunca Rotacionam Sozinhos

O Active Directory parece um sistema que mantém seus próprios segredos sempre atualizados. Computadores ingressados no domínio trocam sua senha em um cronograma, trusts se renovam sozinhos em segundo plano, e ninguém nunca abre um chamado por causa disso. É exatamente essa impressão que faz da higiene de rotação da senha krbtgt, conta de confiança, senha de máquina do controlador de domínio a lacuna mais silenciosa na maioria dos ambientes AD: um desses três segredos não tem rotação automática alguma, e os outros dois só rotacionam enquanto nada está silenciosamente quebrado. Este artigo cobre o que cada mecanismo realmente faz, como verificar os três em poucos minutos, e como corrigi-los sem causar uma interrupção de autenticação em todo o domínio.

Rotação da Senha krbtgt, Conta de Confiança, Senha de Máquina do Controlador de Domínio: Quem Rotaciona o Quê

A armadilha é uma inferência perfeitamente razoável. A documentação de políticas da Microsoft afirma que "em domínios baseados em Active Directory, cada dispositivo tem uma conta e uma senha. Por padrão, os membros do domínio enviam uma troca de senha a cada 30 dias" (Domain member: Maximum machine account password age). As máquinas realmente se mantêm sozinhas, então os administradores generalizam: o diretório cuida dos seus próprios segredos.

Dois dos três acima são de fato automáticos. Mas automático aqui significa automático enquanto tudo está saudável, e o segredo mais valioso do domínio nunca foi automático, para começar.

krbtgt: A Senha que o Active Directory Nunca Muda Para Você

A conta krbtgt é onde vive o material de chaves Kerberos do domínio — todo TGT no domínio é criptografado e assinado com sua chave. A Microsoft descreve a conta exatamente nesses termos: ela "suporta armazenamento de chaves em todos os Kerberos Key Distribution Centers (KDCs)", e "[p]ara renovar as chaves Kerberos usadas na criptografia do TGT, altere periodicamente a senha da conta krbtgt" (Accounts security posture assessment). Nada no diretório realiza essa troca por você: não existe um timer do Netlogon nem uma configuração de política por trás disso, apenas um administrador executando a redefinição manualmente.

Esse é o problema inteiro. Sem rotação, o raio de impacto de uma única cópia histórica do banco de dados de contas nunca diminui, e a Microsoft explicita a consequência: "Se a senha da conta KRBTGT for comprometida, um invasor pode usar seu hash para gerar tickets de autenticação Kerberos válidos, permitindo que execute ataques Golden Ticket e obtenha acesso a qualquer recurso no domínio AD. Como o Kerberos depende da senha KRBTGT para assinar todos os tickets, monitorar de perto e alterar regularmente essa senha é essencial para mitigar o risco desses ataques." A própria baseline da Microsoft dá um número para regularmente: o Defender for Identity traz uma recomendação chamada Change password for krbtgt account, que "lista qualquer conta krbtgt no seu ambiente cuja senha foi definida pela última vez há mais de 180 dias". Quais algoritmos essas chaves usam é a outra metade da história, coberta no nosso guia sobre Kerberos RC4 fallback.

O que um invasor faz com essa chave é abordado em profundidade no nosso guia de ataque Golden Ticket — este artigo trata da higiene de rotação que faz o ticket forjado expirar em vez de viver para sempre.

Senhas de Trust: Automáticas, Mas Apenas de Um Lado

Os trusts interdomínio de fato rotacionam, e o fazem sem que ninguém precise pedir. A documentação da Microsoft sobre os mecanismos internos de trusts descreve o mecanismo: "Ambos os domínios em uma relação de trust compartilham uma senha, armazenada no objeto TDO no Active Directory. Como parte do processo de manutenção de contas, a cada trinta dias, o controlador de domínio do domínio que confia altera a senha armazenada no TDO" (How Domain and Forest Trusts Work — um documento arquivado do Windows Server 2003, ainda a descrição pública mais detalhada do processo).

Três detalhes desse documento importam operacionalmente:

• Apenas um lado conduz o processo. "Um controlador de domínio do domínio confiado nunca inicia a troca de senha; ela é sempre iniciada pelo emulador de PDC do domínio que confia."
• A senha antiga é deliberadamente mantida. Se a autenticação com a nova senha falhar, o controlador de domínio que confia "tenta autenticar usando a senha antiga", e se isso funcionar, ele "retoma o processo de troca de senha dentro de 15 minutos" — por isso os valores antigo e novo residem no TDO.
• A replicação tem um prazo rígido. "As atualizações de senha de trust precisam ser replicadas para os controladores de domínio de ambos os lados do trust dentro de 30 dias. Se a senha do trust for alterada após 30 dias e um controlador de domínio então tiver apenas a senha N-2, ele não pode usar o trust a partir do lado que confia e não pode criar um canal seguro no lado confiado."

O segredo em si não é um atributo de senha comum: a Microsoft observa que os segredos de trust "são representados por atributos especiais nas contas de trust interdomínio", trustAuthIncoming no lado confiado e trustAuthOutgoing no lado que confia, e que eles "são mantidos pelo controlador de domínio que ocupa a função FSMO (Flexible Single Master Operation) de emulador de PDC (Primary Domain Controller) no domínio que confia" (UserAccountControl property flags).

O que você pode ler é a conta de trust interdomínio associada ao TDO. Segundo o MS-ADTS, trusts cujo trustDirection é de entrada ou bidirecional têm uma conta de usuário associada no contêiner de usuários padrão, e os dois objetos são vinculados pelo nome NetBIOS do parceiro: o flatName do TDO é igual ao sAMAccountName da conta sem o $ final. O checkpoint da ANSSI Trust account passwords unchanged for more than a year lê exatamente o pwdLastSet dessa conta, e seu veredito vale a pena citar: um valor desatualizado "pode ser indicativo de relações de trust excluídas enquanto suas contas de trust correspondentes ainda estão presentes", e onde o trust ainda está ativo, "a causa da falta de renovação automática deve ser investigada".

Se você está auditando trusts de forma mais ampla, combine isso com nossos artigos sobre caminhos de ataque a trusts e auditoria de filtragem SID e autenticação seletiva.

Senhas de Máquina do Controlador de Domínio: Automáticas Até Algo Bloqueá-las

Controladores de domínio também são membros do domínio, e suas contas de computador rotacionam no mesmo cronograma do Netlogon que uma estação de trabalho. O KB 154501 da Microsoft afirma isso claramente: "A partir de computadores baseados no Windows 2000, a senha da conta de máquina muda automaticamente a cada 30 dias" (Disable machine account password changes). A política que rege o intervalo permite um "número de dias definido pelo usuário entre 1 e 999", com um padrão efetivo de 30 dias tanto em controladores de domínio quanto em servidores membros e clientes.

Um DC cuja senha de computador não muda há meses não é, portanto, uma escolha de política — é um sinal. O checkpoint da ANSSI Domain controllers with passwords unchanged for more than 45 days é inequívoco: "Alguns controladores de domínio não alteram sua senha há mais de 45 dias, indicando que seus segredos não estão sendo renovados", e "o motivo pelo qual essa alteração não ocorre corretamente deve ser investigado, pois pode ser indicativo de um comprometimento."

Os culpados usuais são locais à máquina:

• DisablePasswordChange definido como 1 em HKLM\System\CurrentControlSet\Services\Netlogon\Parameters, o que impede a máquina de sequer enviar uma troca — é esse valor que congela o próprio segredo de um controlador de domínio.
• Um valor de MaximumPasswordAge empurrado muito para longe, ou uma GPO definindo silenciosamente qualquer um dos dois valores.
• O serviço Netlogon não está em execução, ou um canal seguro já está quebrado.

Um valor de registro é frequentemente culpado aqui e não deveria ser. RefusePasswordChange definido como 1 "faz com que o controlador de domínio recuse solicitações de troca de senha apenas de estações de trabalho ou servidores membros que executam Windows NT versão 4.0 ou posterior" — ele congela as senhas de computador dos seus membros, não a do próprio DC. Verifique-o quando objetos membros pararem de rotacionar: com RefusePasswordChange, "o tráfego de replicação vai parar, mas não o tráfego de clientes", enquanto DisablePasswordChange para ambos.

O próprio aviso da Microsoft sobre desativar isso vale a pena repetir: "Se você desativar as trocas de senha da conta de máquina, existem riscos de segurança porque o canal seguro é usado para autenticação pass-through. Se alguém descobrir uma senha, poderá potencialmente realizar autenticação pass-through contra o controlador de domínio." A documentação de política acrescenta a outra metade: "Aumentar significativamente o intervalo de troca de senha (ou desativar as trocas de senha) dá a um invasor mais tempo para realizar um ataque de força bruta contra uma das contas de máquina."

O segredo de uma conta de máquina também é material de ticket de serviço para tudo que roda naquele host, o que é o mecanismo por trás de um ataque Silver Ticket — e em um controlador de domínio, anomalias em torno do objeto de computador merecem o mesmo escrutínio que uma fonte de replicação inesperada, o truque usado pelo DCShadow. Para o panorama mais amplo de identidade de máquina, veja nossa análise da superfície de ataque de objetos de computador.

Deteccao

Três consultas, executadas de uma estação de trabalho administrativa ingressada no domínio com RSAT, cobrem o trio inteiro.

1. As contas krbtgt, incluindo as específicas de cada RODC:

Get-ADUser -Filter "SamAccountName -like 'krbtgt*'" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet, Enabled

2. As contas de trust interdomínio, resolvidas a partir dos próprios TDOs:

Get-ADObject -Filter "objectClass -eq 'trustedDomain'" -Properties flatName, trustDirection |
    ForEach-Object {
        Get-ADUser -Identity ('{0}$' -f $_.flatName) -Properties PasswordLastSet -ErrorAction SilentlyContinue |
            Select-Object SamAccountName, PasswordLastSet
    }

As mesmas contas podem ser listadas diretamente através da flag INTERDOMAIN_TRUST_ACCOUNT — decimal 2048, hexadecimal 0x0800 — usando o OID de matching rule LDAP_MATCHING_RULE_BIT_AND 1.2.840.113556.1.4.803 (Search Filter Syntax):

Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=2048)" -Properties PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

3. Todo objeto de computador de controlador de domínio:

Get-ADDomainController -Filter * | ForEach-Object {
    Get-ADComputer $_.ComputerObjectDN -Properties PasswordLastSet |
        Select-Object Name, PasswordLastSet
}

Leia a saída em relação a estes limiares:

Os sinais correspondentes de log de eventos:

O evento 4742 "é gerado apenas em controladores de domínio", o que torna a coleta do lado do DC suficiente para essa verificação. Em uma máquina suspeita, nltest /sc_query:<domain> retorna ERROR_ACCESS_DENIED quando o canal seguro está quebrado (Broken trust relationship between a domain-joined device and its domain).

Remediação

🚨 Perigo: Nunca execute as duas redefinições de krbtgt uma logo após a outra. A segunda redefinição antes que a primeira tenha replicado completamente invalida tickets em todo o domínio e pode derrubar a autenticação junto com eles.

Rotacionar o krbtgt, em etapas

1. Verifique a replicação primeiro. O procedimento de duas redefinições só funciona se todo controlador de domínio já tiver visto a primeira senha nova antes que a segunda chegue, então confirme que a replicação está saudável antes de começar. O repadmin /replsummary "identifica controladores de domínio que estão falhando na replicação de entrada ou de saída, e resume os resultados em um relatório".
2. Redefina uma vez, usando o procedimento suportado em AD Forest Recovery - Reset the krbtgt password. A senha que você digita é irrelevante: "o sistema gera uma senha forte automaticamente, independentemente da senha que você especificar".
3. Espere. Microsoft: "Você deve realizar essa operação duas vezes. É necessário esperar 10 horas entre as redefinições de senha. 10 horas são os valores padrão das configurações de política Maximum lifetime for user ticket e Maximum lifetime for service ticket; portanto, caso o período de vida máxima seja alterado, o período mínimo de espera entre as redefinições deve ser maior que o valor configurado." Trate 10 horas como um piso, não como uma meta: em uma floresta grande ou com replicação lenta, deixar um dia inteiro entre as duas redefinições não custa nada.
4. Redefina uma segunda vez. Ambas as redefinições são necessárias porque "o valor de histórico de senha da conta krbtgt é 2, o que significa que ele inclui as duas senhas mais recentes" — uma única redefinição deixa a chave anterior no histórico e ainda utilizável. Microsoft: "Ao redefinir a senha duas vezes, você efetivamente limpa quaisquer senhas antigas do histórico, então não há como outro DC replicar com este DC usando uma senha antiga."
5. Coloque isso em um calendário. O Defender for Identity começa a sinalizar a conta aos 180 dias, o que torna uma rotação semestral um padrão defensável. Qualquer intervalo que você escolha, a rotação só existe se alguém for responsável por ela.

Corrigir uma senha de trust desatualizada

1. Decida se o trust ainda existe. Compare as contas de trust encontradas com os TDOs ativos. A remediação da ANSSI para contas órfãs é direta: "Algumas contas de trust podem permanecer mesmo depois que suas relações de trust foram removidas. Elas devem ser excluídas manualmente."
2. Para um trust ativo, verifique o canal seguro antes de tocar em qualquer coisa: netdom trust <TrustingDomain> /domain:<TrustedDomain> /verify — o parâmetro /verify "verifica os segredos do canal seguro de uma relação de trust específica" (netdom trust).
3. Investigue antes de redefinir. Uma senha de trust que não muda há meses significa que o emulador de PDC do domínio que confia não conseguiu concluir a troca — verifique a conectividade com o parceiro, a saúde da função de emulador de PDC e a replicação do TDO em ambos os lados, lembrando a regra N-2 acima.
4. Redefina o segredo do trust apenas em uma janela de mudança, com credenciais de ambos os lados: netdom trust <TrustingDomain> /domain:<TrustedDomain> /userd:<TrustedDomain>\admin /passwordd:* /reset. O parâmetro /reset "redefine o segredo de trust entre domínios confiados ou entre o controlador de domínio (DC) e a estação de trabalho".

Fazer um controlador de domínio voltar a rotacionar

1. Confirme que o serviço está em execução: sc.exe query netlogon.
2. Verifique os dois valores de registro do Netlogon em HKLM\System\CurrentControlSet\Services\Netlogon\Parameters — a remediação da ANSSI espera que DisablePasswordChange seja 0 ou esteja ausente e que MaximumPasswordAge seja 30, e pede para confirmar que nenhuma GPO está sobrescrevendo esses valores.
3. Verifique se a senha da máquina corresponde ao diretório: nltest /sc_verify:<NetBIOSDomainName> deve retornar 0 0x0 NERR_Success.
4. Se o DC está fora de sincronia porque foi restaurado a partir de um estado mais antigo, trate isso como um reparo de canal seguro, não como um problema de rotação — a Microsoft documenta as duas direções dessa incompatibilidade (o dispositivo mais novo que o AD, e o AD mais novo que o dispositivo).

A higiene de rotação está ao lado do restante da sua postura de credenciais — políticas fracas, senhas que nunca expiram e armazenamento em texto claro são cobertos em Active Directory password security, e as três verificações acima se encaixam diretamente em uma auditoria de segurança do Active Directory mais ampla.

Como a EtcSec Detecta Isso

Uma auditoria da EtcSec verifica os três segredos na mesma passagem. ANSSI_R28_KRBTGT_NOT_ROTATED (Crítico) lê o pwdLastSet de toda conta krbtgt e sinaliza domínios além da marca de 180 dias. ANSSI_R42_TRUST_PASSWORD_OLD (Alto) resolve cada objeto de domínio confiado para sua conta de trust interdomínio e reporta senhas que pararam de rotacionar — incluindo as contas órfãs deixadas por trusts excluídos. ANSSI_R43_DC_PASSWORD_OLD (Alto) e COMPUTER_PASSWORD_OLD comparam todo controlador de domínio e objeto de computador membro com a cadência de 30 dias do Netlogon, de modo que um canal seguro bloqueado surge como um achado em vez de um chamado de suporte seis meses depois. GOLDEN_TICKET_RISK conecta o achado do krbtgt ao que um invasor realmente faz com uma chave que nunca muda.

Referências

• Microsoft — AD Forest Recovery: Reset the krbtgt password
• Microsoft — Accounts security posture assessment (Defender for Identity)
• Microsoft — How Domain and Forest Trusts Work
• Microsoft — UserAccountControl property flags (KB 305144)
• Microsoft — Disable machine account password changes (KB 154501)
• Microsoft — Domain member: Maximum machine account password age
• Microsoft — MS-ADTS: Essential Attributes of Interdomain Trust Accounts
• Microsoft — 4742(S): A computer account was changed e 4724(S, F): An attempt was made to reset an account's password
• Microsoft (arquivado) — New-KrbtgtKeys.ps1, somente leitura desde 8 de março de 2024
• ANSSI / CERT-FR — Points de controle Active Directory (CERTFR-2020-DUR-001), coleção de checkpoints em cert.ssi.gouv.fr/uploads/ad_checklist.html — checkpoints Trust account passwords unchanged for more than a year e Domain controllers with passwords unchanged for more than 45 days