Superfície de ataque dos objetos de computador do Active Directory é o termo coletivo para os riscos de delegação, direitos de replicação e associação a grupos que as contas de máquina carregam rotineiramente — contas que o Active Directory cria automaticamente para cada máquina ingressada no domínio e que raramente são auditadas da mesma forma que as contas de usuário. Diferente das contas de usuário, as contas de computador raramente recebem atenção individual: ninguém revisa suas configurações de delegação, suas associações a grupos ou seu nível de patch da forma como revisaria um usuário privilegiado. Essa lacuna é exatamente o que várias técnicas de ataque bem estabelecidas exploram.
Este artigo aborda especificamente a superfície de ataque dos objetos de computador — distinta de Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse, que explica os próprios mecanismos de delegação, e de ACL Abuse and DCSync: The Silent Paths to Domain Admin, que cobre a escalação baseada em ACL de forma geral. Aqui o foco é mais estreito: quais objetos de computador no seu domínio carregam direitos perigosos, e por que isso é tão fácil de passar despercebido.
O que é a superfície de ataque dos objetos de computador no Active Directory?
Toda máquina Windows ingressada no domínio recebe uma conta de computador no Active Directory — um principal de segurança de pleno direito, com seu próprio SID, suas próprias credenciais Kerberos (rotacionadas automaticamente, tipicamente a cada 30 dias) e a capacidade de manter associações a grupos e direitos de delegação, assim como uma conta de usuário. Esse é o ponto central: serviços executados como SYSTEM em uma máquina ingressada no domínio se autenticam com o resto do domínio como essa conta de computador.
O risco decorre diretamente desse design. Uma conta de computador pode receber — deliberadamente ou por deriva de configuração — as mesmas categorias de direitos perigosos que uma conta de usuário pode ter: delegação que permite personificar outros usuários, direitos de replicação que possibilitam DCSync, ou associação a um grupo privilegiado. A diferença está na visibilidade: as equipes de segurança revisam rotineiramente quais usuários são Domain Admins, mas raramente perguntam quais computadores podem agir como um.
Por que os objetos de computador passam despercebidos
Os fluxos de provisionamento criam objetos de computador automaticamente, muitas vezes por meio de imaging, enrollment via Autopilot ou implantação via SCCM/Intune — sem qualquer revisão humana dos direitos do objeto resultante no momento da criação. Caminhos de ataque como os descritos em Active Directory Attack Paths to Domain Admin encadeiam exatamente esse tipo de concessão não revisada com outras configurações incorretas para chegar a Domain Admin; os objetos de computador são um elo desproporcionalmente comum nessa cadeia justamente por raramente serem objeto de um ciclo de revisão dedicado, como ocorre com contas de usuário privilegiadas.
Delegação irrestrita em um objeto de computador
Quando uma conta de computador é configurada para delegação irrestrita (o flag TRUSTED_FOR_DELEGATION do UserAccountControl), qualquer usuário que se autentique em um serviço nessa máquina tem seu Ticket Granting Ticket (TGT) completo — não apenas um ticket de serviço — armazenado em cache na memória dessa máquina. Segundo a análise amplamente citada do pesquisador de segurança Sean Metcalf sobre esse risco, isso significa que um único host com delegação irrestrita comprometido pode acumular os TGTs de todo usuário que nele se autentica, incluindo os próprios controladores de domínio quando induzidos a se conectar.
⚠️ Aviso: A documentação do BloodHound da SpecterOps observa que um atacante que compromete um host com delegação irrestrita pode combiná-lo com uma técnica de coerção de autenticação de DC (como PrinterBug ou PetitPotam) para capturar o próprio TGT de um controlador de domínio — e a partir daí solicitar tickets de serviço como qualquer usuário, incluindo Domain Admins.
Por que ainda existe
A delegação irrestrita foi o modelo de delegação original no Windows 2000 e foi substituída pela delegação restrita e pelo RBCD para casos de uso legítimos; a própria orientação da Microsoft recomenda não utilizá-la. Seu principal risco hoje é de natureza legada: servidores configurados para isso anos atrás — frequentemente para servidores de impressão, implantações antigas de aplicações web ou ferramentas administrativas ad hoc — e nunca revisados depois que a justificativa original foi esquecida.
Abuso de Resource-Based Constrained Delegation (RBCD)
A Resource-Based Constrained Delegation (RBCD) funciona de forma diferente dos modelos de delegação mais antigos: em vez de ser configurada na conta que precisa delegar, ela é configurada no próprio recurso alvo, por meio do atributo msDS-AllowedToActOnBehalfOfOtherIdentity. Quem estiver listado nesse atributo pode personificar usuários arbitrários perante esse recurso específico.
A implicação de segurança foi detalhada na pesquisa de 2019 de Elad Shamir, "Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory". A principal conclusão: qualquer principal com acesso de escrita ao atributo msDS-AllowedToActOnBehalfOfOtherIdentity de um objeto de computador pode configurar o RBCD para ele — sem precisar dos privilégios de nível domain-admin exigidos pelos modelos de delegação mais antigos. Isso inclui um principal com apenas direitos GenericAll, GenericWrite ou WriteDacl/WriteProperty sobre o objeto de computador alvo. A pesquisa de Shamir também mostrou que o S4U2Self funciona em qualquer conta com um SPN, independentemente de sua configuração TrustedToAuthForDelegation, e que a resposta da Microsoft na época foi de que isso "não é um problema que será corrigido por meio de uma atualização de segurança" — o potencial de abuso do RBCD é consequência de seu design, não um bug corrigível por patch.
Por que o RBCD é um problema de ACL, não um problema de delegação
Isso torna o abuso de RBCD fundamentalmente um problema de ACL em objetos de computador, não um problema de configuração de delegação. Uma conta de computador com uma concessão de ACL aparentemente de baixo risco, herdada de um projeto antigo ou do comportamento padrão de um instalador, pode se tornar um primitivo completo de personificação. Revisar apenas o valor de msDS-AllowedToActOnBehalfOfOtherIdentity em si não revela a exposição — o ponto de controle real é quem está autorizado a escrever nele.
Direitos de DCSync mantidos por uma conta de máquina
O DCSync abusa dos direitos estendidos DS-Replication-Get-Changes e DS-Replication-Get-Changes-All, normalmente reservados a controladores de domínio, para extrair hashes de senha de qualquer conta via o protocolo de replicação de diretório. As contas de computador de controladores de domínio detêm esses direitos legitimamente. O risco tratado aqui é diferente: uma conta de computador que não é DC e que recebeu direitos capazes de DCSync, deliberadamente ou por acidente (por exemplo, por meio de um modelo de ACL excessivamente amplo aplicado na raiz do domínio, ou direitos de replicação concedidos a uma conta de serviço de backup/monitoramento que por acaso está vinculada a uma máquina).
A documentação do BloodHound da SpecterOps descreve a aresta de DCSync como a combinação desses dois direitos em qualquer principal — usuário, grupo ou computador — e observa que ela também pode surgir indiretamente por meio de configurações incorretas de delegação restrita, sem que o objeto jamais tenha detido os direitos de replicação explicitamente.
Computadores em grupos privilegiados
Uma conta de computador adicionada a um grupo privilegiado (Domain Admins, Enterprise Admins ou um grupo Tier 0 personalizado) concede direitos equivalentes a Domain Admin a qualquer coisa em execução como SYSTEM nessa máquina — o que, na prática, significa qualquer pessoa capaz de obter execução de código nela. Esse é um perfil de exposição diferente de uma conta de usuário privilegiada: uma estação de trabalho ou servidor de aplicação geralmente é mais fácil de comprometer do que um endpoint administrativo reforçado, e seu contexto SYSTEM está disponível para muito mais caminhos de código (tarefas agendadas, serviços, contas de administrador local) do que uma única sessão interativa de usuário.
Esse é o mesmo problema estrutural abordado em Dangerous Group Nesting: Hidden Paths to Domain Admin — uma associação a grupo que parece pouco relevante isoladamente se torna perigosa assim que se rastreia quem realmente detém o controle efetivo da máquina que a possui.
Sistemas operacionais obsoletos ainda no domínio
Objetos de computador executando versões do Windows além do seu ciclo de vida de suporte — Windows XP, Windows Server 2003 ou anteriores — não recebem mais atualizações de segurança da Microsoft, inclusive para vulnerabilidades ativamente exploradas. Um controlador de domínio ou servidor membro em um sistema operacional obsoleto é um ponto fraco permanente e impossível de corrigir por patch, e, como esses sistemas costumam ser mantidos online por causa de uma aplicação legada específica, tendem a ser excluídos dos processos rotineiros de gestão de patches e vulnerabilidades em vez de serem sinalizados como a exposição de maior prioridade que de fato representam.
Esses sistemas frequentemente se sobrepõem ao padrão descrito em Stale Privileged Accounts: Hidden Risk in Active Directory: ambos são exposições que persistem exatamente porque ninguém assume a decisão de removê-las.
Detecção
| Indicador | O que verificar | Notas |
|---|---|---|
| Delegação irrestrita | Objetos de computador com TRUSTED_FOR_DELEGATION definido (bit 0x80000 de userAccountControl / ADS_UF_TRUSTED_FOR_DELEGATION) | Sinalizar toda ocorrência; isso deveria ser uma exceção explícita, não um padrão |
| Configuração de RBCD | msDS-AllowedToActOnBehalfOfOtherIdentity não vazio em objetos de computador | Cruzar com quem pode escrever nesse atributo, não apenas quem está listado nele atualmente |
| Direitos capazes de DCSync | DS-Replication-Get-Changes / DS-Replication-Get-Changes-All concedidos a principais que não são DC | Auditar na raiz do domínio e em qualquer OU onde direitos de replicação possam ter sido delegados |
| Associação a grupo privilegiado | Contas de computador em Domain Admins, Enterprise Admins ou grupos Tier 0 | Toda ocorrência justifica investigação — casos de uso legítimos são raros |
| Sistema operacional obsoleto | Atributo operatingSystem para versões além do ciclo de vida de suporte da Microsoft | Incluir explicitamente os controladores de domínio — eles não são isentos |
💡 Dica: O BloodHound (SpecterOps) mapeia delegação irrestrita, RBCD e direitos capazes de DCSync como arestas de grafo, o que torna prático enxergar essas exposições como caminhos de ataque até Domain Admin, em vez de achados isolados em objetos individuais.
Remediação
1. Marcar contas sensíveis como não delegáveis
Defina o flag "A conta é confidencial e não pode ser delegada" (Account is sensitive and cannot be delegated) em contas de alto valor, para que não possam ser capturadas nem mesmo por um host com delegação irrestrita comprometido.
2. Remover a delegação irrestrita sempre que possível
Migre os casos de uso legítimos para delegação restrita ou RBCD, que limitam a personificação a serviços alvo específicos.
3. Auditar toda configuração de RBCD — e as ACLs que permitem defini-la
Revise msDS-AllowedToActOnBehalfOfOtherIdentity em todos os objetos de computador e — mais importante — revise quem detém direitos GenericAll/GenericWrite/WriteDacl que permitiriam configurá-lo em primeiro lugar.
4. Remover direitos capazes de DCSync de principais que não são DC
Audite as concessões de DS-Replication-Get-Changes / DS-Replication-Get-Changes-All na raiz do domínio e em qualquer OU delegada.
5. Remover contas de computador de grupos privilegiados
A menos que haja um motivo específico, documentado e revisado para a associação, trate toda ocorrência como um achado a ser corrigido, não como uma configuração a ser mantida por herança.
6. Desativar ou isolar sistemas com sistema operacional obsoleto
Quando a desativação não for imediatamente possível, isole o sistema na rede e remova quaisquer direitos privilegiados ou associações a grupos que ele possua.
# Listar objetos de computador configurados para delegação irrestrita
Get-ADComputer -Filter 'TrustedForDelegation -eq $true' -Properties TrustedForDelegation, OperatingSystem
# Listar objetos de computador com configuração de RBCD definida
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' }
Como a EtcSec detecta isso
A categoria Computers da EtcSec cobre diretamente essa superfície de ataque: COMPUTER_UNCONSTRAINED_DELEGATION, COMPUTER_RBCD, COMPUTER_DCSYNC_RIGHTS e COMPUTER_IN_ADMIN_GROUP sinalizam os riscos de delegação, direitos de replicação e associação a grupos descritos acima, enquanto COMPUTER_OS_OBSOLETE_XP e COMPUTER_OS_OBSOLETE_2003 sinalizam sistemas operacionais fora do período de suporte ainda presentes no domínio.
ℹ️ Nota: A EtcSec verifica automaticamente todo objeto de computador do domínio quanto a essas condições em cada auditoria de AD, tratando identidades de máquina com o mesmo rigor que contas de usuário privilegiadas. Execute uma auditoria gratuita para ver quais objetos de computador no seu ambiente carregam esses direitos.
Referências primárias
- Elad Shamir: Wagging the Dog — Abusing Resource-Based Constrained Delegation to Attack Active Directory
- ADSecurity.org (Sean Metcalf): Active Directory Security Risk #101 — Kerberos Unconstrained Delegation
- SpecterOps BloodHound Documentation: DCSync edge
- SpecterOps BloodHound Documentation: CoerceToTGT edge
- hackndo: Resource-Based Constrained Delegation — Risks
- Microsoft Learn: Making the second hop in PowerShell Remoting (delegation background)
Explore as paginas de identidade que sustentam este tema