O Active Directory (AD) é o coração da identidade na maioria das empresas: controla quem é cada usuário, a que recursos tem acesso e sob quais condições. Comprometer o AD é, na prática, comprometer a organização inteira. Por isso o protocolo Kerberos, base da autenticação do AD, virou um dos alvos preferidos de atacantes. Este artigo explica como o Kerberos funciona, mapeia os ataques clássicos contra o AD e detalha o hardening que separa um domínio frágil de um ambiente resiliente.
O papel do Active Directory na rede corporativa
O Active Directory Domain Services (AD DS) é o serviço de diretório da Microsoft que centraliza autenticação, autorização e gestão de objetos (usuários, grupos, computadores, políticas). Os Domain Controllers (DCs) hospedam a base de dados do diretório e processam pedidos de logon. Praticamente todo recurso interno — compartilhamentos de arquivos, servidores de aplicação, estações, e-mail on-premises — confia no AD para responder à pergunta "quem é você e o que pode fazer?".
Essa centralização é uma faca de dois gumes. Ela simplifica a operação, mas concentra risco: um atacante que obtém privilégios de administrador de domínio pode se mover lateralmente, criar contas persistentes, ler qualquer dado e desabilitar defesas. Em incidentes de ransomware, o padrão é quase sempre o mesmo — o agressor compromete uma estação, escala privilégios, domina o AD e só então dispara a criptografia em massa. Entender e proteger o AD não é uma tarefa de TI acessória; é controle de risco corporativo de primeira ordem.
Como o Kerberos funciona
Kerberos é o protocolo de autenticação padrão do AD desde o Windows 2000. Ele evita trafegar senhas pela rede usando tickets criptografados e um terceiro confiável. Os componentes centrais são:
- KDC (Key Distribution Center)
- Serviço que roda em cada Domain Controller. Divide-se em dois papéis: o Authentication Service (AS) e o Ticket-Granting Service (TGS).
- TGT (Ticket-Granting Ticket)
- Bilhete obtido no logon que prova a identidade do usuário ao KDC. É cifrado com a chave da conta krbtgt e tem validade limitada (tipicamente 10 horas).
- TGS (Ticket-Granting Service ticket, ou service ticket)
- Bilhete específico para acessar um serviço (ex.: um compartilhamento ou um SQL Server), cifrado com o hash da conta de serviço associada ao SPN.
- SPN (Service Principal Name)
- Identificador único que liga um serviço a uma conta no AD. É o que permite ao KDC saber qual chave usar para cifrar o service ticket.
O fluxo, simplificado, tem três trocas:
- AS-REQ / AS-REP: o cliente pede um TGT ao AS. Por padrão, com pré-autenticação habilitada, ele envia um timestamp cifrado com sua própria senha; o KDC valida e devolve o TGT.
- TGS-REQ / TGS-REP: de posse do TGT, o cliente solicita ao TGS um service ticket para um SPN específico. O KDC devolve um ticket cifrado com a chave da conta de serviço.
- AP-REQ / AP-REP: o cliente apresenta o service ticket diretamente ao serviço-alvo, que o valida e concede acesso — sem nunca consultar a senha do usuário.
Esse desenho elegante tem um efeito colateral perigoso: qualquer usuário autenticado pode pedir um service ticket para qualquer SPN, e esse ticket é cifrado com o hash da senha da conta de serviço. É exatamente essa propriedade que viabiliza o Kerberoasting.
Ataques clássicos contra AD e Kerberos
Os ataques abaixo aparecem mapeados na tática Credential Access do MITRE ATT&CK e são rotineiramente observados em intrusões reais. Entendê-los é pré-requisito para detectá-los.
Kerberoasting
O atacante, já autenticado como um usuário comum, solicita service tickets para contas de serviço (que possuem SPN) e extrai os tickets cifrados. Offline, faz força bruta sobre o hash até descobrir a senha da conta de serviço. Contas de serviço frequentemente têm senhas fracas e antigas, com privilégios excessivos — combustível ideal. Mapeado em T1558.003.
AS-REP Roasting
Quando uma conta tem a pré-autenticação Kerberos desabilitada, o KDC devolve no AS-REP material cifrado com o hash da senha do usuário, mesmo sem prova de identidade. O atacante coleta esse material e o quebra offline. Mapeado em T1558.004.
Pass-the-Hash (PtH)
Em vez de descobrir a senha em texto claro, o atacante reutiliza o hash NTLM capturado da memória (LSASS) para autenticar-se em outros sistemas. Não envolve Kerberos diretamente, mas é a ponte clássica para movimento lateral. Mapeado em T1550.002.
Pass-the-Ticket (PtT)
O atacante extrai tickets Kerberos válidos (TGT ou TGS) da memória e os injeta em outra sessão para se passar pela vítima. Mapeado em T1550.003.
Golden Ticket
Se o atacante obtém o hash da conta krbtgt, ele pode forjar TGTs arbitrários — para qualquer usuário, com qualquer privilégio, com validade definida por ele. É persistência de domínio quase total: enquanto a senha do krbtgt não for rotacionada duas vezes, o ticket forjado continua válido. Mapeado em T1558.001.
Silver Ticket
Variante mais cirúrgica: com o hash de uma conta de serviço específica, o atacante forja service tickets para aquele serviço, sem passar pelo KDC. Mais difícil de detectar porque não gera tráfego TGS no DC. Mapeado em T1558.002.
DCSync
Abusando do protocolo de replicação (MS-DRSR), uma conta com os direitos de replicação "Replicating Directory Changes" pode pedir ao DC que entregue os hashes de senha de qualquer conta — inclusive krbtgt e administradores. É a forma mais limpa de exfiltrar credenciais sem tocar o LSASS. Mapeado em T1003.006.
DCShadow
Técnica de evasão e persistência: o atacante registra um Domain Controller falso e injeta alterações maliciosas no diretório (ex.: adicionar SID History ou alterar ACLs) que se replicam como legítimas, contornando muitos controles de auditoria. Associado a T1207.
Mapa de ataques: técnica, MITRE ATT&CK e detecção
| Ataque | O que explora | MITRE ATT&CK | Sinal de detecção |
|---|---|---|---|
| Kerberoasting | Service tickets de contas com SPN | T1558.003 | Evento 4769 em volume, cifra RC4 (0x17) |
| AS-REP Roasting | Contas sem pré-autenticação | T1558.004 | Evento 4768 com pré-auth desabilitada |
| Pass-the-Hash | Hash NTLM reutilizado | T1550.002 | Logon 4624 tipo 3/9 com NTLM anômalo |
| Pass-the-Ticket | Tickets injetados na memória | T1550.003 | TGS sem TGT correspondente; lifetime atípico |
| Golden Ticket | Hash da conta krbtgt | T1558.001 | TGT com lifetime anômalo; krbtgt anomalia |
| Silver Ticket | Hash de conta de serviço | T1558.002 | Acesso a serviço sem 4769 no DC |
| DCSync | Direitos de replicação (MS-DRSR) | T1003.006 | Replicação a partir de host não-DC (4662) |
| DCShadow | Registro de DC falso | T1207 | Novo objeto nTDSDSA inesperado; SPN GC |
Tiering de privilégio: o modelo Tier 0/1/2
A defesa estrutural mais importante do AD é o modelo de tiering administrativo, recomendado pela Microsoft no Enterprise Access Model. A ideia é impedir que credenciais privilegiadas sejam expostas em sistemas de menor confiança.
- Tier 0
- Ativos que controlam a identidade: Domain Controllers, AD CS, contas de Domain/Enterprise Admins, sistemas de PAM. Comprometê-los = comprometer tudo.
- Tier 1
- Servidores e aplicações de negócio, dados corporativos. Administrados por contas de Tier 1, nunca com credenciais de Tier 0.
- Tier 2
- Estações de trabalho e dispositivos de usuário final, onde mora a maior parte do risco de phishing.
A regra de ouro: uma credencial de tier superior nunca deve fazer logon interativo em um sistema de tier inferior, pois seu hash/ticket ficaria exposto na memória daquele host. Estações de administração privilegiada (PAW — Privileged Access Workstations) reforçam essa separação.
Contas administrativas, LAPS e gMSA
Três controles práticos reduzem drasticamente a superfície:
- Contas administrativas dedicadas: separe a conta de uso diário da conta com privilégio. Minimize membros de Domain Admins, Enterprise Admins e Schema Admins — idealmente contas de emergência só usadas sob quebra-de-vidro.
- LAPS (Windows LAPS): randomiza e rotaciona automaticamente a senha do administrador local de cada máquina, eliminando a senha local reutilizada que viabiliza Pass-the-Hash em massa.
- gMSA (Group Managed Service Accounts): contas de serviço com senhas longas (240+ bytes) gerenciadas e rotacionadas automaticamente pelo AD. Tornam o Kerberoasting inviável na prática, pois não há senha fraca para quebrar.
Detecção: eventos do Windows e AD no SIEM
O AD gera eventos ricos que, levados a um SIEM, permitem caçar os ataques acima. Os principais identificadores:
- 4768 — Kerberos AS (TGT solicitado): monitore contas com pré-autenticação desabilitada (AS-REP Roasting) e padrões anômalos de emissão.
- 4769 — Kerberos TGS (service ticket solicitado): picos de pedidos por um único usuário para muitos SPNs, especialmente com Ticket Encryption Type 0x17 (RC4), são forte indicador de Kerberoasting.
- 4624 — Logon bem-sucedido: tipos de logon 3 (rede) e 9 (new credentials) com NTLM ajudam a flagrar Pass-the-Hash e movimento lateral.
- 4662 / 5136 — acesso a objeto do diretório: operações de replicação (DCSync) a partir de hosts que não são Domain Controllers.
- 4738 / 4670 — alterações em conta e em permissões: mudanças suspeitas em ACLs e em SID History.
Detecção eficaz não é sobre coletar tudo — é sobre correlacionar os eventos certos com contexto de identidade. Um 4769 isolado é ruído; cem 4769 do mesmo usuário em RC4 em segundos é um ataque.
Encaminhe os logs dos DCs e dos servidores Tier 0 para um SIEM com retenção adequada, ative a auditoria avançada (Advanced Audit Policy) e construa regras de correlação baseadas no MITRE ATT&CK. Soluções de detecção específicas de identidade (como Microsoft Defender for Identity) complementam o SIEM com analítica comportamental.
Hardening: fechando as portas
O endurecimento do AD combina configuração, higiene de credenciais e redução de protocolos legados. Prioridades, alinhadas a CIS Benchmarks e às orientações de segurança da Microsoft:
- Protected Users: coloque contas privilegiadas no grupo Protected Users, que bloqueia NTLM, DES, RC4 e cache de credenciais — neutralizando boa parte de PtH e roasting.
- Desabilitar RC4 (e DES): force AES nos tickets Kerberos. RC4 é o que torna o Kerberoasting rápido; sua remoção encarece muito o ataque. Faça a transição monitorando 4769 por tipo de cifra.
- MFA para acesso privilegiado: exija autenticação multifator para administradores e acessos remotos. Senha comprometida deixa de ser suficiente.
- Least privilege e revisão de SPNs: remova privilégios excessivos de contas de serviço, migre para gMSA e elimine SPNs órfãos.
- Rotação dupla do krbtgt: rotacione a senha da conta krbtgt periodicamente (duas vezes, respeitando o intervalo de replicação) — essencial para invalidar Golden Tickets pós-incidente.
- Endurecer a replicação: restrinja quem tem direitos de "Replicating Directory Changes" e monitore replicações de origens inesperadas para barrar DCSync/DCShadow.
- Higiene de credenciais: Credential Guard, restrição de logon de Tier 0, PAWs e LAPS em todas as estações e servidores.
Frameworks de referência como o NIST SP 800-63 (identidade digital) e os CIS Microsoft Windows Server / CIS Benchmarks oferecem linhas de base auditáveis. O segredo é tratar AD security como um programa contínuo, não um projeto único: o ambiente muda, novas contas surgem, e a deriva de configuração reabre portas.
Referências
- Microsoft — Best Practices for Securing Active Directory
- Microsoft — Enterprise Access Model (tiering)
- MITRE ATT&CK — Credential Access (TA0006)
- CIS Microsoft Windows Server Benchmarks
- NIST SP 800-63 — Digital Identity Guidelines
Como a Decripte protege sua identidade corporativa
Na Decripte, tratamos o Active Directory como ativo crítico de qualquer empresa — de 1 a mais de 100.000 colaboradores. Avaliamos a postura do seu domínio (tiering, contas privilegiadas, SPNs, cifras Kerberos), implementamos hardening alinhado a CIS e Microsoft, e conectamos os eventos certos (4768/4769/4624) ao monitoramento contínuo para detectar Kerberoasting, DCSync e tentativas de Golden Ticket antes que virem incidente. Cibersegurança de identidade para todos os tamanhos — do MEI ao enterprise.
Quer ver onde seu ambiente está exposto? Comece grátis pelo nosso Intelligence Center e descubra seu risco de identidade, ou conheça os planos para colocar a proteção do seu AD em piloto automático.