Três configurações do Active Directory que envelhecem sem ninguém olhar

Quando um relatório de pentest chega na mesa do time de infra, quase sempre tem as mesmas três coisas. Não são vulnerabilidades para corrigir com patch. São escolhas de configuração que fizeram sentido um dia e nunca foram revistas.

A boa notícia é que dá para levantar as três com o módulo do Active Directory que você já tem instalado, em uma tarde.

1. Conta de serviço com privilégio administrativo

O abuso dessa configuração é conhecido como Kerberoasting, e é o achado mais comum em auditoria de domínio.

Toda conta que roda um serviço tem um SPN, e qualquer usuário do domínio pode pedir um tíquete de serviço para ela. Isso é o Kerberos funcionando como foi projetado.

O detalhe que importa: esse tíquete é protegido por uma chave derivada da senha da conta de serviço. Quem consegue o tíquete pode tentar descobrir a senha fora do seu ambiente, sem limite de tentativa e sem gerar nenhuma falha de autenticação no seu controlador de domínio. Você não vê acontecer.

Por isso conta de serviço com senha antiga, escolhida por pessoa, e ainda por cima membro de um grupo administrativo, é o pior cenário possível. O atacante não precisa invadir nada: ele pede, sai com o tíquete e trabalha em casa.

Para levantar quem está nessa situação (as três consultas deste artigo são de leitura, não alteram nada):

Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
  -Properties ServicePrincipalName,adminCount,PasswordLastSet |
  Select-Object SamAccountName,adminCount,PasswordLastSet |
  Sort-Object PasswordLastSet

Um aviso sobre o adminCount: ele é carimbo do AdminSDHolder e não se apaga sozinho, então conta que já saiu do grupo privilegiado continua marcada com 1. Serve para levantar candidatos, não para concluir. Confirme a associação atual antes de corrigir.

A correção que resolve de verdade é migrar para gMSA, onde o próprio AD gera uma senha de 240 bytes e a rotaciona a cada 30 dias, sem ninguém digitar nada. Depende da KDS root key na floresta (Add-KdsRootKey), que leva 10 horas para propagar em produção. Onde gMSA não for possível, senha longa mesmo e, principalmente, tirar o privilégio administrativo de conta que só precisa subir um serviço.

2. Pré-autenticação desligada

Quando essa opção está marcada, a conta fica sujeita ao que se chama de AS-REP Roasting.

Por padrão, o controlador de domínio só responde depois que você prova que sabe a senha. Existe uma opção na conta que desliga essa exigência, e quando ela está marcada o DC responde a quem perguntar, devolvendo um dado protegido pela senha do usuário.

A diferença para o caso anterior é o ponto de partida: aqui não é preciso estar autenticado no domínio. Basta alcançar a rede.

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth |
  Select-Object SamAccountName,Enabled

Costumam ser poucas contas, quase sempre herança de integração com sistema antigo. Alguém desligou em uma madrugada para destravar e ninguém voltou para religar. Corrigir é barato: religue a exigência e troque a senha da conta. Raramente quebra alguma coisa.

3. Direito de replicação onde não devia

O abuso desse direito é conhecido como DCSync.

Controladores de domínio replicam credenciais entre si, senão o AD não funciona. Quem tiver as permissões de replicação no diretório consegue pedir essa réplica e receber os hashes de senha do domínio inteiro, incluindo o da conta que assina todos os tíquetes.

É o pior dos três por uma diferença de grau: os outros dois entregam uma senha por vez. Este entrega o domínio. E, quando acontece, a recuperação não é trocar uma senha, é um procedimento planejado que afeta a empresa inteira.

$dn = (Get-ADDomain).DistinguishedName
(Get-Acl "AD:$dn").Access |
  Where-Object { $_.ObjectType -in '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2',
                                   '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' } |
  Select-Object IdentityReference,ObjectType

A lista deveria ter os controladores de domínio e pouca coisa mais. Parte do que aparecer costuma ser lixo: grupo criado para uma ferramenta de backup, conta de uma migração que acabou anos atrás. Parte é legítima e precisa continuar existindo, como a conta de sincronização com a nuvem. O ponto é que essa conta legítima vale exatamente o mesmo que um administrador de domínio para quem a comprometer, e quase nunca recebe esse cuidado.

A armadilha que faz o alerta nunca disparar

Essa parte é sobre a sua detecção, não sobre o ataque, e vale para quem inspeciona tráfego Kerberos com sonda de rede. Os nomes de campo variam conforme a ferramenta; abaixo estão os da nossa, e o princípio serve para qualquer uma.

Uma forma comum de monitorar é procurar tíquete emitido com cifra fraca, já que a cifra antiga facilita a quebra offline. Subimos dois SPNs de teste, um aceitando só RC4 e outro só AES, e comparamos o que aparecia:

SPN	encryption	ticket_encryption
RC4	aes256	rc4-hmac
AES	aes256	aes256

Os dois saem aes256 na coluna do meio, porque aquele campo descreve a cifra da sessão e não a do tíquete. Quem escreveu a regra em cima dele vê a situação de risco passar classificada como criptografia forte.

O campo certo é o que descreve a cifra do tíquete, e não a da sessão. Se a sua regra aponta para o segundo, ela provavelmente nunca abriu um caso, e isso não quer dizer que nada tenha acontecido. Vale a checagem antes de confiar nela.

Do lado do log do Windows, o evento relevante é o 4769, filtrando pelo tipo de criptografia 0x17. Só que ele é dos eventos mais barulhentos do domínio, então antes de alertar convém coletar por uma semana e descobrir qual é o seu normal. Exchange, SCCM e agentes de backup vão aparecer no topo pedindo muito tíquete, e são legítimos.

E se já aconteceu antes de eu olhar?

Pergunta certa, e a resposta começa por uma constatação incômoda: com trinta dias de retenção de log, você provavelmente não consegue responder.

Um indicador que independe de log é a idade da senha da conta krbtgt:

Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object PasswordLastSet

Se ela é de anos atrás e em algum momento desse período alguém obteve o hash, o acesso construído a partir dele continua valendo hoje. Não existe expiração automática para esse problema. É por isso que rotacionar a krbtgt periodicamente entra em qualquer plano sério de higiene de AD, mesmo sem incidente conhecido.

E vale dizer o óbvio que costuma ser esquecido: ausência de evidência, com retenção curta, não é evidência de ausência.

Como tratamos isso no Guardian

Quando o instalador reconhece que a máquina é um controlador de domínio, o agente passa a coletar a postura do AD junto com o resto da telemetria. Sem script à parte, sem segunda instalação. Conta de serviço com privilégio, pré-autenticação desligada, delegação irrestrita, direito de replicação onde não devia: cada achado sai mapeado no MITRE ATT&CK e explicado em português.

Uma escolha nossa que costuma gerar pergunta: esses achados não abrem incidente de SOC. Vão para a fila de gestão de risco, com ciclo próprio, e só saem de lá quando uma nova verificação confirma a correção. Marcar como resolvido não fecha nada. Exposição e ataque em andamento têm urgências diferentes, e juntar os dois na mesma fila é a forma mais rápida de perder as duas de vista.

Se você não tem quem faça essa revisão periodicamente, é exatamente o tipo de coisa que o Guardian passa a acompanhar sozinho.

Ver como o Guardian cobre identidade em três camadas