Autenticação Kerberos no Active Directory: Do Handshake AS-REQ/TGS-REQ e Anatomia do PAC à Defesa Contra Kerberoasting e Uso de gMSA
Manual Avançado de Criptografia e Hardening para SysAdmins, Red Teams e Engenheiros de Identidade
O Kerberos v5 é a espinha dorsal de autenticação do Active Directory desde o lançamento do Windows 2000. No entanto, a maioria das organizações opera o protocolo sem compreender a mecânica de seus tickets criptográficos, as extensões proprietárias da Microsoft no Privilege Attribute Certificate (PAC) e como configurações padrão legadas abrem as portas para ataques devastadores como Kerberoasting, AS-REP Roasting e Golden Tickets. Este guia disseca o protocolo na teoria e na prática, estabelecendo as diretrizes mandatórias de mitigação recomendadas pela Microsoft.
O Handshake Criptográfico: Do AS-REQ ao TGS-REQ e a função sagrada da conta `krbtgt`.
Anatomia do PAC (MS-PAC): Como grupos e privilégios são assinados e validados no KDC.
Ataques Reais Dissecados: A mecânica de exploração do Kerberoasting e Golden Tickets.
Defesa em Profundidade: Implementação de gMSA, grupo Protected Users e FAST Armoring.
—
1. O Protocolo Kerberos v5 no Active Directory: O Fluxo Criptográfico
Ao contrário do protocolo legado NTLM (que se baseia em desafio e resposta e é vulnerável a ataques de Relay e Pass-the-Hash), o Kerberos v5 opera com autenticação mútua baseada em tickets emitidos por uma entidade de confiança: o KDC (Key Distribution Center), que reside em cada Controlador de Domínio do Active Directory.
O funcionamento do protocolo é detalhado na especificação How the Kerberos Version 5 Authentication Protocol Works no Microsoft Learn.
O Passo a Passo Criptográfico:
1. AS-REQ e AS-REP (Authentication Service Exchange)
- O cliente quer provar quem ele é sem enviar a senha pela rede. Ele gera um carimbo de data/hora (timestamp) e o criptografa com a chave derivada da sua própria senha.
- O KDC decodifica o timestamp. Se a hora do cliente e do KDC estiverem alinhadas (tolerância máxima padrão de 5 minutos via W32Time), o KDC confirma a identidade do usuário.
- O KDC gera o Ticket Granting Ticket (TGT). O TGT é criptografado com a chave mestra secreta da conta
krbtgtdo domínio. O usuário não consegue ler nem alterar o conteúdo do TGT.
2. TGS-REQ e TGS-REP (Ticket-Granting Service Exchange)
- Quando o usuário deseja acessar uma pasta compartilhada (
cifs/fileserver.corp.local) ou um banco de dados (MSSQLSvc/sql01.corp.local:1433), ele não envia sua senha para o servidor de arquivos. - O cliente envia o seu TGT ao KDC informando o Service Principal Name (SPN) do destino.
- O KDC valida o TGT usando a chave
krbtgt, localiza a conta no AD que detém o SPN solicitado, cria o Ticket de Serviço (ST – Service Ticket) e o criptografa utilizando o hash da senha da conta de serviço que roda a aplicação.
3. AP-REQ e AP-REP (Application Exchange)
- O cliente entrega o Ticket de Serviço diretamente ao servidor da aplicação.
- O servidor da aplicação decodifica o ticket utilizando sua própria chave secreta. Como apenas ele e o KDC conhecem essa chave, o servidor sabe com 100% de certeza que o usuário foi legitimamente autenticado pelo domínio.
—
2. A Anatomia do Privilege Attribute Certificate (PAC)
O padrão aberto da RFC 4120 do Kerberos define apenas a identidade do usuário ([email protected]), mas não informa quais permissões ou grupos de segurança o usuário possui.
Para viabilizar o controle de acesso no ecossistema Windows, a Microsoft criou uma extensão proprietária obrigatória: o Privilege Attribute Certificate (PAC), especificado formalmente no documento MS-PAC: Privilege Attribute Certificate Data Structure no Microsoft Learn.
Por que as Duas Assinaturas Digitais são Cruciais?
O PAC contém duas assinaturas criptográficas distintas para impedir fraudes de escalação de privilégios:
1. Server Signature: Permite ao servidor de aplicação validar que o PAC recebido não foi adulterado em trânsito após ter sido emitido.
2. KDC Signature: Assinada com a chave da conta krbtgt. O servidor de aplicação pode enviar uma requisição especial de validação ao DC para verificar se o PAC foi realmente gerado pelo KDC do domínio e não forjado por um serviço comprometido.
—
3. Anatomia dos Principais Ataques ao Kerberos
O desconhecimento da física do Kerberos transforma redes corporativas em alvos triviais para invasores:
1. Kerberoasting: O Ataque Mais Comum em Ambientes Corporativos
- A Falha de Arquitetura: Qualquer usuário do domínio (mesmo um estagiário ou terceiro com acesso básico) tem permissão de solicitar um Ticket de Serviço (TGS) para qualquer SPN registrado na floresta.
- O Vetor: Se uma aplicação (como um pool do IIS ou serviço do SQL) estiver rodando sob a identidade de uma conta de usuário comum com SPN registrado (
setspn -s), o KDC entrega o Ticket de Serviço criptografado com o hash da senha desse usuário. - A Extração: O atacante extrai o ticket da memória de sua estação de trabalho (sem precisar de privilégios de administrador local) e leva o hash para uma máquina externa para quebra offline de senha via força bruta com dicionários (utilizando ferramentas como Hashcat).
- O Perigo: O Controlador de Domínio registra apenas um evento normal de concessão de ticket (
Event ID 4769), sem nenhum log de tentativa de login falha, tornando o ataque 100% invisível em auditorias superficiais.
2. Golden Ticket vs. Silver Ticket
- Golden Ticket: Ocorre quando o invasor obtém o hash NTLM ou a chave AES da conta sagrada
krbtgt(geralmente através de um dump de memória do processolsass.exeem um Controlador de Domínio comprometido). O atacante pode forjar TGTs arbitrários com qualquer nome de usuário, injetando o SID de Enterprise Admins no PAC com validade de 10 anos. - Silver Ticket: O invasor não possui a chave do
krbtgt, mas comprometeu a senha de um servidor específico. Ele forja um Ticket de Serviço (ST) direto para aquele servidor sem consultar o KDC.
—
4. Blindagem Moderna: gMSA, Protected Users e Kerberos Armoring
Para mitigar estruturalmente esses vetores de ataque, a Microsoft desenvolveu defesas profundas documentadas em Best Practices for Securing Active Directory.
1. Group Managed Service Accounts (gMSA)
A recomendação mandatória da Microsoft para serviços corporativos (IIS, tarefas agendadas, SQL Server) é a migração imediata de contas de serviço normais para gMSA, especificado em Group Managed Service Accounts Overview no Microsoft Learn:
- Ninguém sabe a senha da conta de serviço (ela é gerada pelo KDC via KDS Root Key).
- A senha possui 128 caracteres complexos e é rotacionada automaticamente a cada 30 dias pelo próprio sistema operacional.
- Mesmo que um invasor solicite um ticket Kerberoastable para o SPN da gMSA, o hash gerado é matematicamente impossível de ser quebrado por força bruta.
2. O Grupo de Segurança “Protected Users”
Introduzido no Windows Server 2012 R2 e detalhado em Protected Users Security Group:
- Qualquer conta de alto privilégio (Domain Admins, Enterprise Admins) deve ser membro do grupo global Protected Users.
- Efeitos Imediatos:
* O NTLM é desativado para essas contas: elas só autenticam via Kerberos.
* O KDC não emite tickets usando o algoritmo obsoleto e vulnerável RC4; apenas AES-128 ou AES-256.
* As credenciais não são mantidas em cache no processo lsass.exe de estações onde o administrador fizer logon, neutralizando o Mimikatz.
* O tempo de vida do TGT é reduzido para 4 horas (contra as 10 horas tradicionais).
—
5. Comandos Práticos no PowerShell para Auditoria e Hardening
Abaixo apresentamos a suíte de automação em PowerShell para auditar e blindar o ambiente contra ataques ao Kerberos:
Active Directory Domain Services
Leitura do Terminal: Na execução acima em ambiente real de laboratório, apenas a conta padrão krbtgt (com o SPN administrativo legado kadmin/changepw e status desabilitado) foi retornada. Se uma conta de usuário convencional (ex.: svc_sql ou iis_user) aparecer nesta listagem, ela é um alvo imediato para extração de tickets TGS e quebra offline de senha por força bruta.
—
## 6. Referências Técnicas Oficiais da Microsoft
Para aprofundamento adicional nos manuais de engenharia utilizados na construção desta análise:
* [Microsoft Learn: How the Kerberos Version 5 Authentication Protocol Works](https://learn.microsoft.com/en-us/windows-server/security/kerberos/how-the-kerberos-version-5-authentication-protocol-works)
* [Microsoft Learn: MS-PAC Privilege Attribute Certificate Specification](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-dc5f80ab9f1b)
* [Microsoft Learn: Group Managed Service Accounts (gMSA) Overview](https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview)
* [Microsoft Learn: Protected Users Security Group Architecture](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group)
* [Microsoft Learn: Best Practices for Securing Active Directory](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory)
* [Microsoft Learn: Kerberos Armoring (FAST) Implementation](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831747(v=ws.11))
—
Guilherme Nascimento
Especialista & FundadorEspecialista em Infraestrutura, Cloud/DevOps e Cibersegurança | +10 anos de experiência prática
Profissional com mais de uma década atuando no campo de batalha da tecnologia corporativa. Especialista em arquiteturas resilientes, automação com Docker/Kubernetes, Hardening de Active Directory, Linux avançado e observabilidade SRE. Criador do ecossistema Hora Nerd, dedicado a desmistificar a tecnologia para profissionais e estudantes.
