O Que São Caminhos de Ataque AD?
Caminhos de Ataque AD são cadeias de relações — associações a grupos, permissões de ACL, vínculos de GPO, configurações de delegação, contas vulneráveis a Kerberoasting — que conectam um atacante com poucos privilégios ao Domain Admin. Nenhuma configuração incorreta isolada precisa ser crítica por si só: o que importa é se elas podem ser encadeadas.
Adversários modernos não exploram vulnerabilidades isoladas. Eles mapeiam todo o ambiente AD como um grafo, identificam o caminho mais curto entre sua posição atual e o Domain Admin, e seguem esse caminho — um salto de cada vez. Cada salto explora uma configuração incorreta diferente: uma senha que quebraram, um caminho de aninhamento de grupos, uma ACL que conseguem abusar ou um certificado que forjaram.
Este artigo cobre as três categorias de caminho mais confiáveis: caminhos de ACL, caminhos de GPO e caminhos de Kerberoasting até o Domain Admin.
Como Funcionam os Caminhos de Ataque AD
A análise de caminhos de ataque trata o AD como um grafo direcionado:
- Nós = usuários, computadores, grupos, GPOs, OUs, domínios
- Arestas = relações que podem ser abusadas (MemberOf, GenericAll, WriteDACL, GpLink etc.)
Ferramentas como o BloodHound (open source) coletam esses dados de grafo e usam o Neo4j para encontrar os caminhos mais curtos entre dois nós quaisquer. Um atacante executando o BloodHound a partir de uma conta de usuário padrão comprometida pode visualizar todo o caminho até o Domain Admin em minutos — muitas vezes encontrando caminhos que levaram anos de configurações incorretas acumuladas para se formar.
Categorias Comuns de Caminho
| Tipo de caminho | Exemplo de cadeia |
|---|---|
| ACL até DA | Usuário A tem GenericWrite sobre o Usuário B (membro de DA) |
| GPO até DA | Usuário A tem direitos de edição de GPO em uma GPO vinculada à OU Domain Controllers |
| Kerberoasting até DA | Conta de serviço é vulnerável a Kerberoasting E é membro de DA |
| Aninhamento de grupos | Usuário A está no Grupo X, que está aninhado em Domain Admins |
| ADCS | Usuário A pode se inscrever em um template vulnerável que permite personificação de DA |
A Cadeia de Ataque
Passo 1 – Coletar Dados do Grafo AD
# A partir do Linux com credenciais válidas — collector BloodHound CE (pip install bloodhound-ce)
bloodhound-ce-python -u [email protected] -p password -ns 10.10.0.1 -d corp.local -c All --zip
# bloodhound-python (pip install bloodhound) é o ingestor legado: apenas BloodHound 4.2/4.3
# A partir do Windows
.\SharpHound.exe -c All --zipfilename corp_bloodhound.zip
Passo 2 – Encontrar os Caminhos Mais Curtos até o Domain Admin
Na interface do BloodHound ou no navegador Neo4j:
// Caminho mais curto de qualquer usuário até Domain Admins
MATCH p=shortestPath((u:User {enabled:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"}))
RETURN p ORDER BY length(p) ASC LIMIT 10
// Encontrar todos os usuários vulneráveis a Kerberoasting com caminho até DA
MATCH (u:User {hasspn:true})-[*1..]->(g:Group {name:"DOMAIN [email protected]"})
RETURN u.name, u.pwdlastset
// Encontrar caminhos de direitos de edição de GPO até DCs
MATCH p=(u:User)-[:GenericAll|GenericWrite|Owns|WriteDacl|WriteOwner*1..]->(g:GPO)-[:GPLink]->(c:OU)
WHERE c.blocksinheritance = false
RETURN p
Passo 3 – Seguir o Caminho Mais Curto
Um caminho típico do mundo real:
- O atacante compromete
jsmith(usuário padrão) via phishing jsmithtemGenericWritesobresvc_deploy(resquício de um projeto)svc_deployé vulnerável a Kerberoasting com uma senha de 3 anos- O atacante escreve um SPN em
svc_deployviaGenericWritee quebra o ticket de serviço resultante (Kerberoasting direcionado), ou escrevemsDS-KeyCredentialLinkpara Shadow Credentials —GenericWritesozinho não permite redefinir a senha, o que exigeForceChangePasswordouGenericAll svc_deployé membro do grupoIT_AdminsIT_Adminsestá aninhado dentro deDomain Admins- Comprometimento total do domínio — 3 saltos no grafo, nenhum exploit
Passo 4 – Manter Persistência
Assim que o acesso DA é obtido, o atacante estabelece persistência via Golden Ticket, novas contas backdoor ou backdoors de certificado ADCS — garantindo que sobrevivam a redefinições de senha e tentativas de remediação.
Detecção
Detectar a travessia de caminhos de ataque exige monitorar cada salto individual — nenhum log isolado revela o caminho completo.
Event IDs do Windows
| Event ID | Origem | Salto de caminho detectado |
|---|---|---|
| 4769 | DC | Kerberoasting — solicitação de TGS para SPN |
| 4662 | DC | DCSync — direitos de replicação exercidos |
| 4724 | DC | Redefinição de senha em outra conta — abuso de ForceChangePassword/GenericAll (geralmente seguido por um 4738) |
| 4728/4756 | DC | Mudança de associação a grupo — caminho de aninhamento explorado |
| 5136 | DC | GPO modificada — caminho de GPO explorado |
💡 Dica: Implemente o BloodHound em modo defensivo (BloodHound CE ou PlumHound). Execute a coleta do grafo semanalmente e alerte quando novos caminhos mais curtos até o Domain Admin surgirem que não existiam no scan anterior.
Consulta de Correlação para SIEM
O KQL apenas filtra documentos — não consegue agregar —, então a correlação em si é expressa em ES|QL:
// Detectar eventos sequenciais e rápidos de escalada de privilégio da mesma origem
FROM logs-*
| WHERE event.code IN ("4769", "4724", "4728", "5136")
AND @timestamp > NOW() - 1 hour
| STATS event_count = COUNT(*) BY winlog.event_data.SubjectUserName
| WHERE event_count > 3
Remediação
💡 Vitória Rápida: Execute o BloodHound no seu ambiente hoje. O primeiro scan quase sempre revela pelo menos um caminho até o Domain Admin a partir de uma conta não privilegiada. Comece pelo caminho mais curto e trabalhe para fora.
1. Eliminar Primeiro os Caminhos Mais Curtos
Execute o BloodHound e exporte os 10 caminhos mais curtos até o Domain Admin. Para cada caminho:
- Aresta de ACL: Remova a ACE perigosa do objeto
- Aresta de aninhamento de grupo: Remova o grupo do grupo privilegiado
- Aresta vulnerável a Kerberoasting: Rotacione a senha ou migre para gMSA
- Aresta de GPO: Remova os direitos de edição da conta não administrativa
2. Implementar Monitoramento Contínuo de Caminhos de Ataque
# Coleta semanal do BloodHound via tarefa agendada
# SharpHound é um executável nativo: passe as flags explicitamente (o splatting de hash-table só se
# vincula a cmdlets do PowerShell, não a um .exe)
.\SharpHound.exe -c All `
--outputdirectory "C:\BloodHound\Collections\" `
--zipfilename "weekly_$(Get-Date -Format yyyyMMdd).zip"
# Compare com os dados da semana anterior e alerte sobre novos caminhos DA
3. Priorizar Contas Vulneráveis a Kerberoasting no Caminho DA
# Encontrar todas as contas vulneráveis a Kerberoasting com qualquer caminho até privilégios DA
# -Filter espera uma string; krbtgt carrega um SPN mas não é kerberoastável na prática
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties MemberOf, PasswordLastSet |
Where-Object { $_.SamAccountName -ne "krbtgt" } |
Where-Object {
$_.MemberOf | Get-ADGroup | Where-Object { $_.Name -match "Admin" }
} | Select-Object SamAccountName, PasswordLastSet
# Migre essas contas para gMSA imediatamente
Como o EtcSec Detecta Isso
O EtcSec realiza análise contínua de caminhos de ataque em todo o seu grafo AD, identificando todos os caminhos de contas com poucos privilégios até o Domain Admin.
PATH_ACL_TO_DA mapeia todo caminho baseado em ACL de usuários padrão até o Domain Admin, incluindo cadeias multi-hop através de objetos intermediários.
PATH_GPO_TO_DA identifica caminhos onde direitos de edição de GPO em políticas vinculadas a OUs Tier 0 fornecem um caminho indireto para o comprometimento do Domain Controller.
PATH_KERBEROASTING_TO_DA sinaliza contas de serviço vulneráveis a Kerberoasting que possuem — direta ou transitivamente — privilégios de Domain Admin, representando o caminho de ataque de alto impacto mais comum em ambientes reais.
ℹ️ Nota: O EtcSec mapeia continuamente os caminhos de ataque em seu ambiente AD. Execute uma auditoria gratuita para ver sua superfície de ataque completa sob a perspectiva do grafo.
Prioridades de Revisão
Caminhos de Ataque AD até o Domain Admin devem ser tratados como uma exposição real dentro do seu patrimônio de Active Directory, não como uma configuração isolada. Comece definindo o perímetro de revisão: quais grupos privilegiados, contas de serviço, ACLs, vínculos de GPO, trusts, configurações de delegação, templates de certificado e estações de trabalho de administração estão envolvidos, quais fluxos de negócio dependem deles, quais privilégios eles expõem e quais exceções de emergência foram adicionadas ao longo do tempo. Essa etapa de escopo evita uma remediação superficial, porque o sintoma técnico costuma ser menor que o raio operacional de impacto. Ao documentar o caminho completo da configuração até o privilégio, a equipe pode priorizar mudanças que reduzem o risco rapidamente sem quebrar o acesso em produção. Isso também cria uma baseline defensável para validação posterior e dá à liderança uma explicação clara de por que o problema importa agora.
Controles Adjacentes a Revisar
Quando atacantes alcançam seu patrimônio de Active Directory, raramente param no primeiro ponto fraco. Em torno de Caminhos de Ataque AD até o Domain Admin, eles normalmente testam se o caminho exposto pode ser encadeado com contas privilegiadas obsoletas, aninhamento de grupos inseguro, delegação excessiva, configurações de senha fracas, caminhos de GPO graváveis e abuso de ACL herdada. Isso significa que os defensores devem revisar não apenas a fraqueza principal, mas cada dependência vizinha que transforma acesso em persistência ou escalada de privilégio. Confirme quais identidades, papéis, permissões e suposições de confiança podem ser reutilizados por um operador motivado. Se uma correção fecha apenas um objeto e deixa caminhos de privilégio adjacentes intocados, o risco efetivo muda pouco. Uma revisão disciplinada das oportunidades de encadeamento é o que transforma este tema de artigo em um exercício prático de hardening, em vez de uma verificação pontual.
Evidências e Telemetria a Coletar
Uma resposta sólida a Caminhos de Ataque AD até o Domain Admin precisa de evidências que possam ser revisadas tanto por equipes de engenharia quanto de detecção. Colete os Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, mudanças no SYSVOL e atividade de certificados ou CA, compare mudanças recentes com janelas de manutenção conhecidas e isole contas ou sistemas cujo comportamento mudou sem um motivo de negócio claro. Use essas evidências para responder três perguntas: quando o caminho arriscado surgiu, quem ainda pode usá-lo e se existe exposição semelhante em outra parte do seu patrimônio de Active Directory. Uma boa revisão de telemetria também ajuda a separar dívida técnica herdada de abuso ativo. Essa distinção importa, porque o plano de remediação para uma configuração incorreta antiga é diferente do plano para um caminho que já mostra atividade típica de atacante ou exceções de política repetidas.
Fraquezas Adjacentes que Merecem Revisão
Poucos ambientes contêm apenas Caminhos de Ataque AD até o Domain Admin isoladamente. Na prática, o mesmo segmento de tenant ou diretório costuma conter também contas privilegiadas obsoletas, aninhamento de grupos inseguro, delegação excessiva, configurações de senha fracas, caminhos de GPO graváveis e abuso de ACL herdada, e essas fraquezas vizinhas decidem se o problema é apenas incômodo ou verdadeiramente crítico. Revise owners compartilhados, permissões herdadas, exceções duplicadas e atalhos administrativos de longa duração. Verifique se a mesma equipe aprovou padrões arriscados semelhantes em vários lugares, porque decisões repetidas normalmente apontam para uma lacuna de processo em vez de um único erro técnico. Essa revisão mais ampla evita uma limpeza parcial e aumenta suas chances de remover o caminho de ataque por completo. Também melhora a prontidão para auditoria, porque o estado final fica mais fácil de explicar e de monitorar ao longo do tempo.
Leituras Relacionadas
Revise este tema junto com Abuso de ACL e DCSync: Os caminhos silenciosos até o Domain Admin, Aninhamento perigoso de grupos: caminhos ocultos até o Domain Admin, Ataques de confiança do Active Directory: do domínio filho à raiz da floresta, Configurações incorretas de GPO: como a Group Policy vira um vetor de ataque e Monitoramento do Active Directory: Event IDs de segurança que importam. Esses artigos relacionados mostram como as mesmas fraquezas de identidade costumam se encadear em uma avaliação real, em vez de aparecer como achados isolados.
- Abuso de ACL e DCSync: Os caminhos silenciosos até o Domain Admin
- Aninhamento perigoso de grupos: caminhos ocultos até o Domain Admin
- Ataques de confiança do Active Directory: do domínio filho à raiz da floresta
- Configurações incorretas de GPO: como a Group Policy vira um vetor de ataque
- Monitoramento do Active Directory: Event IDs de segurança que importam
Usar essas referências mantém a discussão de remediação focada no caminho de ataque completo, em vez de em uma única lacuna de controle.
Checklist de Validação
Antes de encerrar a revisão, execute novamente as mesmas verificações que expuseram o problema e confirme que o caminho arriscado não existe mais sob a perspectiva do atacante. Verifique as identidades, privilégios, caminhos de herança e controles compensatórios relevantes em produção, não apenas em staging ou na documentação. Registre o owner técnico, a dependência de negócio esperada e a evidência de que a nova configuração é ao mesmo tempo mais segura e operacionalmente sustentável. Essa etapa final de validação é o que mantém o artigo ancorado em como as equipes de fato reduzem o risco de identidade.
Explore as paginas de identidade que sustentam este tema

