Abuso de ACL em objetos de computador: revisar a DACL no AD

O que é o abuso de ACL em objetos de computador no Active Directory?

As revisões de abuso de ACL em objetos de computador no Active Directory procuram determinar quem pode alterar o objeto de diretório de uma identidade de máquina. GenericAll, WriteDACL e WriteOwner podem expor caminhos para delegação restrita baseada em recursos (RBCD), credenciais de chave não autorizadas ou redefinição da senha da máquina. Encontrar uma permissão perigosa comprova uma exposição; demonstrar sua exploração exige evidências de alteração e autenticação.

A introdução à superfície de ataque dos objetos de computador já explica o caminho de ACL para RBCD, juntamente com delegação, direitos de replicação e associação a grupos privilegiados. Este guia transforma essa base em uma revisão operacional: inspecionar a DACL e o proprietário, distinguir três caminhos de abuso, coletar evidências de alterações no diretório e corrigir tanto o caminho de permissão quanto qualquer configuração não autorizada.

A revisão trata de direitos sobre um objeto de computador. Uma conta de máquina com privilégios em outro local representa uma relação diferente. Registre o DN e o GUID do objeto controlado, o principal que recebe a permissão, seu escopo e a finalidade administrativa prevista antes de decidir o que remover.

Como funciona: revisar a DACL e o proprietário

Uma lista de controle de acesso discricionário (DACL) contém entradas de controle de acesso (ACEs). Cada entrada identifica um principal e direitos; entradas específicas de objeto podem restringir a propriedade, o direito estendido ou a classe de objeto que herda a permissão. Ler apenas o nome de permissão exibido ignora esse escopo. A enumeração de direitos de acesso do AD da Microsoft define esses campos e os direitos WriteDACL e WriteOwner.

GenericAll não é apenas um bit bruto a procurar. O mapeamento de direitos de acesso de MS-ADTS converte direitos genéricos em direitos específicos quando um descritor de segurança é armazenado. Uma auditoria que procura apenas 0x10000000 pode deixar passar o controle total mapeado. Interprete os direitos resultantes juntamente com o tipo de ACE, o escopo da propriedade e a herança.

A propriedade exige sua própria verificação. A Microsoft documenta o bloqueio de direitos implícitos do proprietário em objetos de computador, com condições de sistema operacional e BlockOwnerImplicitRights. Não presuma que tornar-se proprietário sempre oferece um caminho irrestrito para gravar a DACL. Verifique os direitos efetivos na configuração real do DC. Da mesma forma, remover uma ACE evidente de controle total não comprova a correção se permanecer um proprietário inesperado ou outra permissão aplicável.

Por que os objetos de computador precisam de uma revisão específica de ACL

Um inventário de delegação responde quais máquinas aceitam atualmente identidades delegadas. Uma revisão de ACL pergunta quem poderia mudar essa resposta amanhã. Portanto, um atributo RBCD vazio não encerra um achado sobre um principal capaz de gravá-lo. A mesma distinção se aplica às credenciais de chave: inventarie os valores armazenados e a capacidade de acrescentá-los.

Comece pelo contexto de negócio, em vez de uma proibição geral de administração. Um serviço de implantação pode precisar de direitos específicos de provisionamento; isso não demonstra a necessidade de controle total permanente sobre todos os objetos de servidor. Peça ao responsável que identifique a operação, os objetos afetados, o principal aprovado e a data de expiração ou revisão. Compare essa necessidade com a ACE real.

Permissões diretas e herdadas exigem correções diferentes. Se uma permissão indesejada se origina em uma OU superior, alterar um único computador deixa outros destinatários expostos. Rastreie a origem da herança e inspecione o escopo da classe de objeto antes de alterá-la. Mantenha envolvidos os responsáveis administrativos pela OU e suas cargas de trabalho, para que a delegação substituta suporte a tarefa legítima.

A cadeia de ataque: três caminhos a partir do controle do objeto

1. Configuração de RBCD

Um invasor com acesso efetivo de gravação a msDS-AllowedToActOnBehalfOfOtherIdentity pode tentar inserir uma identidade de serviço controlada na configuração de delegação do recurso. WriteDACL pode ser uma etapa anterior que concede a permissão de gravação necessária. A referência de esquema da Microsoft descreve esse atributo como a verificação de acesso para agir em nome de outras identidades em serviços executados como a conta.

A visão geral da delegação restrita da Microsoft explica a autorização do lado do recurso e a troca de tíquetes de serviço S4U2Proxy. A consequência é o acesso por serviços elegíveis no recurso de destino, sujeito ao ambiente e à autorização do serviço. Não é uma garantia automática de privilégios de Administrador local ou Domain Admin. Revise os serviços de destino e os privilégios da identidade representada para avaliar o impacto.

2. Shadow Credentials

Uma chave pública não autorizada em msDS-KeyCredentialLink pode criar um caminho separado de autenticação baseada em chave quando o ambiente suporta o fluxo de confiança de chave correspondente e o invasor possui sua chave privada. MS-PKCA Key Trust exige que implementações apoiadas no AD confirmem a mesma chave pública no atributo da conta.

Distinga o acesso amplo de gravação de atributos das gravações validadas. Estas impõem verificações adicionais além do esquema do atributo. A especificação de gravação validada para computadores exige SELF, o direito de gravação validada correspondente e restrições específicas do blob para acrescentar um valor, incluindo a ausência de um valor existente. Essas condições não significam que qualquer terceiro com uma gravação validada possa instalar uma chave.

A autenticação por chave pública de dispositivos ingressados no domínio também explica o provisionamento legítimo de chaves de computador. Um atributo preenchido é um dado para triagem, não um veredito de comprometimento. O guia de Shadow Credentials desenvolve essa distinção e explica por que uma limpeza limitada à senha pode deixar um caminho de chave não autorizado em funcionamento.

3. Redefinição da senha da máquina

O controle total pode incluir o direito estendido Reset Password. A entrada de esquema Reset Password da Microsoft lista explicitamente Computer entre as classes aplicáveis. Uma redefinição não autorizada pode dar ao invasor controle da credencial baseada em senha da conta, com impacto dependente dos privilégios dessa conta e dos caminhos de autenticação disponíveis.

Ela também pode interromper a relação de confiança da máquina. A orientação de solução de problemas do canal seguro da Microsoft descreve divergências de senha entre o dispositivo e o AD. Trate uma redefinição sem explicação como um incidente de identidade e uma preocupação de disponibilidade. Coordene a recuperação com o responsável pelo sistema; uma alteração unilateral da senha no diretório não é um experimento diagnóstico seguro.

Enumeração: um comando de leitura, depois revisão dos direitos efetivos

Em um sistema Windows administrativo com dsacls disponível, abra um prompt de comando elevado ou uma sessão PowerShell elevada e substitua o DN de computador verificado neste único comando de leitura:

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /A

A referência de dsacls da Microsoft documenta a exibição de ACL e /A para informações de proprietário e auditoria. Use uma conta autorizada a ler a DACL, o proprietário e as informações de auditoria; o acesso comum READ_CONTROL exclui a SACL. Este exemplo não foi executado em um ambiente AD.

Resolva cada principal inesperado para uma identidade atual. Registre permissões herdadas versus explícitas, grupos aplicáveis, escopo das propriedades e proprietário. Confirme as permissões efetivas com as ferramentas de segurança do diretório, em vez de tratar cada entrada de permissão como um ataque independente e imediatamente utilizável. Investigue identidades não resolvidas e explique as exceções administrativas aprovadas no registro da revisão.

Priorize servidores sensíveis e as OUs que delegam controle sobre eles, depois amplie a revisão para todos os objetos de computador. Salve o estado anterior para que uma alteração posterior possa ser avaliada com base no mesmo objeto e escopo de permissão.

Detecção: Event ID 5136 e KQL

A referência da Microsoft para Event ID 5136 confirma a auditoria de modificações de objetos de diretório. Habilite a auditoria de sucesso de Audit Directory Service Changes nos DCs e entradas SACL adequadas de auditoria de gravação nos objetos ou atributos monitorados. A Microsoft observa que configurações de esquema podem suprimir a auditoria de alguns objetos e propriedades; portanto, valide a cobertura real. Retenha os campos de correlação de ator, objeto, atributo e operação. A exclusão e a inclusão de valores podem fazer parte de uma única modificação; não as conte como incidentes separados.

A KQL a seguir é uma consulta inicial não executada para um workspace que recebe eventos de Segurança dos DCs em WindowsEvent. Ela pressupõe propriedades nomeadas dentro de EventData. O esquema da tabela WindowsEvent da Microsoft define esse campo como dinâmico e informa que falhas de análise preenchem RawEventData em seu lugar. Inspecione registros representativos antes de confiar nesse mapeamento.

WindowsEvent
| where TimeGenerated > ago(7d)
| where Channel == "Security" and EventID == 5136
| extend ObjectClass = tostring(EventData.ObjectClass),
         ObjectDN = tostring(EventData.ObjectDN),
         AttributeName = tostring(EventData.AttributeLDAPDisplayName),
         ActorSID = tostring(EventData.SubjectUserSid),
         ActorName = tostring(EventData.SubjectUserName),
         Operation = tostring(EventData.OperationType),
         OperationCorrelation = tostring(EventData.OpCorrelationID)
| where ObjectClass =~ "computer"
| where AttributeName in~ ("msDS-AllowedToActOnBehalfOfOtherIdentity",
                          "msDS-KeyCredentialLink", "nTSecurityDescriptor")
| project TimeGenerated, Computer, ObjectDN, AttributeName,
          ActorSID, ActorName, Operation, OperationCorrelation
| order by TimeGenerated desc

Verifique separadamente registros 5136 com EventData vazio ou estruturado de outra forma; caso contrário, lacunas de análise ficam invisíveis. Adapte a consulta se o conector usar SecurityEvent ou outra tabela. Valide a cobertura de SACL e a visibilidade das alterações do descritor de segurança com uma alteração administrativa controlada antes de fazer afirmações sobre cobertura. A consulta encontra modificações candidatas, não prova de abuso.

Para o caminho de redefinição, complemente a revisão de alterações no diretório com Event ID 4742 em Audit Computer Account Management. Seu campo Password Last Set pode refletir uma redefinição manual ou a rotação normal da senha da máquina. A Microsoft também documenta que alterações de DACL podem produzir campos vazios de atributos alterados. Portanto, uma lista de campos vazia não comprova que nada relevante mudou.

Faça a triagem em relação às alterações aprovadas de implantação, registro e delegação. Preserve a configuração anterior quando disponível, identifique a conta que iniciou a operação e verifique a atividade subsequente da máquina afetada. Eleve a prioridade quando um ator não aprovado altera um servidor sensível, um proprietário muda inesperadamente ou uma alteração de permissão precede uma inclusão de delegação ou chave. Dados de auditoria ausentes exigem uma investigação da coleta; não podem comprovar ausência de exploração.

Correção (Remediation): remover o caminho de permissão e recuperar a identidade

Etapa 1: preservar evidências e restringir a delegação

Capture a DACL, o proprietário, a origem da herança e os valores de atributos relevantes antes de alterá-los. Remova permissões não autorizadas de controle total, gravação da DACL e propriedade. Substitua o acesso de provisionamento necessário por direitos limitados à operação documentada e à classe de objeto. Corrija uma permissão herdada em sua origem e revise os demais computadores afetados.

Se for confirmado que um principal específico não precisa de nenhuma ACE restante neste objeto, dsacls /R oferece uma operação documentada de remoção:

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /R "EXAMPLE\RetiredProvisioning"

/R remove todas as ACEs desse principal; não é uma limpeza seletiva de controle total. Para um principal que mantém direitos legítimos, edite a ACE problemática específica. Confirme depois o proprietário e os direitos efetivos resultantes. Este exemplo baseado na documentação não foi executado.

Etapa 2: remover delegação e chaves não autorizadas

Concilie os delegados RBCD com a lista aprovada pelo responsável pelo recurso. Set-ADComputer expõe PrincipalsAllowedToDelegateToAccount; use o conjunto pretendido e verificado, preservando dependências legítimas de aplicações. Remover um delegado não autorizado sem corrigir a permissão de quem grava deixa a configuração aberta à recriação.

Para uma chave não autorizada confirmada, o mesmo cmdlet permite remover um valor exato de atributo LDAP:

Set-ADComputer -Identity "APP01" -Remove @{ 'msDS-KeyCredentialLink' = $ConfirmedUnauthorizedValue }

$ConfirmedUnauthorizedValue deve conter o valor exato preservado e revisado. Este é um exemplo de sintaxe baseado na documentação, não uma recuperação executada. Preserve as chaves de dispositivo aprovadas, documente como cada valor restante foi validado e teste a autenticação legítima após a limpeza.

Etapa 3: restaurar a confiança e verificar o encerramento

Se as credenciais da máquina foram comprometidas, coordene sua recuperação com o responsável pelo dispositivo e investigue acessos subsequentes. Em um membro do domínio, o cmdlet de canal seguro da Microsoft oferece este comando de verificação:

Test-ComputerSecureChannel -Verbose

Execute-o localmente em PowerShell aberto com Executar como administrador no membro do domínio afetado. Este comando de verificação baseado na documentação não foi executado. A Microsoft alerta que ele produz erros falsos positivos em controladores de domínio; nesses casos, siga procedimentos específicos para DCs. Um canal seguro funcional verifica essa relação, não a remoção de todo valor de diretório controlado pelo invasor.

Encerre o achado somente após revisar as permissões e o proprietário resultantes, conciliar delegação e chaves, verificar a operação prevista dos serviços e confirmar que o monitoramento recebe as alterações esperadas. Atribua um responsável e uma data de revisão a cada exceção mantida.

Como o EtcSec detecta isso

A implementação de etc-collector oferece duas visões de catálogo desta revisão de permissões de objetos de computador:

• COMPUTER_ACL_GENERICALL inspeciona ACEs de concessão em objetos de computador em busca de GenericAll bruto ou controle total mapeado do AD, excluindo principais administrativos internos. Correlaciona os DNs dos computadores quando o inventário está disponível e usa uma heurística de localização menos precisa quando ele está ausente.
• COMPUTER_ACL_ABUSE relata computadores com o sinalizador DangerousACL. O mecanismo de auditoria deriva esse sinalizador de permissões concedidas de GenericAll, WriteDACL ou WriteOwner em objetos de computador, excluindo o próprio objeto e os principais privilegiados esperados.

Trate essas visões como um único controle editorial com sobreposição: uma visão específica de controle total e uma visão agregada de direitos perigosos. Seus filtros de principais diferem; portanto, não prometa conjuntos idênticos de achados nem some suas contagens em um total de exposições independentes. Ambas relatam exposição de configuração; nenhuma comprova que RBCD, uma chave indevida ou uma redefinição de senha foi explorada com sucesso. Use os objetos afetados para iniciar a revisão da DACL e correlacione com evidências de alteração.