Ataques de Confianca do Active Directory: Do Dominio Filho a Raiz

O que São os Ataques de Confiança do Active Directory?

Os ataques de confiança do Active Directory exploram os caminhos de autenticação e autorização que permitem que um domínio ou floresta acesse recursos em outro. As relações de confiança (trusts) são parte normal do AD DS. Trusts pai-filho dentro de uma floresta, trusts externos, trusts de atalho e trusts de floresta existem para atender requisitos reais de acesso. O risco é que um trust também amplia o perímetro de segurança que os defensores precisam entender.

Um trust não significa automaticamente comprometimento. O risco prático depende do tipo de trust, da direção, da transitividade, do comportamento do SID filtering, da selective authentication, do tiering administrativo e do nível de comprometimento no domínio de origem. Mas, em uma floresta multi-domínio, o comprometimento de um domínio filho pode se tornar um incidente em nível de floresta se o atacante conseguir abusar de caminhos de confiança Kerberos, SIDs privilegiadas ou acesso administrativo que atravesse essa fronteira.

Uma boa revisão começa com três perguntas:

• quais trusts existem e quem são seus donos
• quais trusts ainda têm um requisito de negócio atual
• se cada trust limita a autorização entre domínios ao escopo pretendido

Como Funcionam os Trusts do Active Directory

A Microsoft documenta que o AD DS usa relações de confiança de domínio e de floresta para fornecer autenticação entre domínios e florestas. Antes que o acesso através de um trust seja possível, o Windows calcula um caminho de confiança entre o controlador de domínio do recurso e um controlador de domínio no domínio da conta solicitante.

Trusts podem ser unidirecionais ou bidirecionais. Também podem ser transitivos ou não transitivos. Em uma floresta AD DS on-premises, novos domínios filhos criam automaticamente relações de confiança bidirecionais e transitivas com o domínio pai. Essa transitividade permite que as solicitações de autenticação sigam os caminhos de confiança pela árvore de domínios, desde que as permissões autorizem o acesso.

Esse comportamento é útil, mas significa que os defensores não devem tratar um domínio filho como um diretório de baixa consequência. Se um domínio filho for mal administrado, tiver confiança excessiva ou for comprometido no nível do controlador de domínio, a floresta inteira precisa ser revisada como um sistema de segurança conectado.

Onde o SID Filtering Entra

Os tickets Kerberos incluem dados de autorização, entre eles as SIDs usadas para decisões de acesso. O SID History existe para cenários de migração em que uma conta precisa manter o acesso a recursos que ainda referenciam uma SID antiga. A documentação da Microsoft sobre DsAddSidHistory observa que adicionar SIDs ao atributo sIDHistory de um principal de segurança é uma operação sensível para a segurança, e que, se um domínio de recursos confiar no domínio de conta de uma SID roubada ou não autorizada, o usuário não autorizado pode obter acesso indevido aos recursos dessa SID.

O SID filtering foi projetado para reduzir esse risco nas fronteiras de confiança. A especificação PAC da Microsoft descreve o comportamento do SID filtering nas fronteiras de confiança, incluindo trusts entre florestas e trusts externos. O comportamento exato depende da fronteira de confiança e da categoria da SID, por isso é importante não reduzir o tema a uma única flag sem entender o tipo de trust.

Para trusts externos, os administradores costumam revisar o estado de quarentena ou de SID filtering. Para trusts de floresta, a selective authentication e as configurações do trust de floresta também podem importar. Para trusts pai-filho dentro da mesma floresta, a questão maior costuma ser arquitetural: todos os domínios fazem parte do mesmo tecido de confiança da floresta, então o comprometimento de um domínio pode ter consequências além do domínio local.

Limites de Escopo e Pré-requisitos

Isto não é uma afirmação de que todo trust do AD é explorável. O abuso de trust de alto impacto normalmente exige um pré-requisito forte, como:

• comprometimento de um controlador de domínio ou segredo equivalente em nível de domínio no domínio de origem
• capacidade de forjar ou manipular dados de autorização Kerberos
• um caminho de confiança que aceite o contexto de autorização resultante
• recursos-alvo que autorizam o acesso com base em SIDs privilegiadas ou grupos entre domínios
• separação fraca entre tiers administrativos entre domínios

É por isso que a revisão de trusts deve estar vinculada às premissas de resposta a incidentes. Se o segredo krbtgt de um domínio filho ou seus controladores de domínio forem comprometidos, não trate o incidente como isolado até que os caminhos de confiança, as sessões privilegiadas e a autorização entre domínios tenham sido revisados.

Padrões Comuns de Abuso de Trust

Do Domínio Filho ao Pai ou à Raiz da Floresta

O cenário clássico de escalada começa com o comprometimento de um domínio filho. Se o atacante controlar o domínio de origem em profundidade suficiente, ele pode tentar forjar material Kerberos que carregue dados de autorização privilegiados em direção a um recurso pai ou raiz da floresta. Se isso funciona depende do comportamento e da filtragem do trust, mas a lição defensiva é clara: domínios filhos exigem proteção de nível Tier 0 quando fazem parte da mesma floresta.

Trusts Externos Obsoletos

Trusts externos antigos são comuns após migrações, integrações com parceiros, aquisições ou projetos temporários. Um trust obsoleto ainda pode permitir caminhos de autenticação que ninguém possui ativamente. Mesmo com o SID filtering habilitado, um trust desnecessário continua sendo uma superfície de ataque desnecessária.

Ownership Fraco do Trust

Um trust sem dono se torna difícil de alterar porque ninguém pode aprovar sua remoção. Isso leva a exceções permanentes. Todo trust remanescente deveria ter um dono de aplicação, um dono de negócio, uma direção de autenticação, usuários esperados e uma data de revisão.

Administração Privilegiada Entre Fronteiras

Trusts se tornam mais perigosos quando administradores usam credenciais privilegiadas entre domínios ou florestas. Uma sessão privilegiada em um domínio com governança mais fraca pode expor credenciais ou tokens que permitem movimento para um domínio mais sensível. O hardening de trusts e o hardening de acesso privilegiado precisam ser revisados juntos.

Detecção

Nenhum evento único do Windows prova um ataque de trust. A detecção exige inventário de trusts, revisão de eventos Kerberos, contexto de logon privilegiado e monitoramento de mudanças.

Fontes de Eventos e Logs do Windows

Os dados de eventos precisam de contexto. Um evento 4769 entre domínios pode ser normal para uma aplicação. Um logon administrativo entre domínios vindo de uma conta inesperada, após um incidente no domínio filho, é algo muito diferente.

Revisão do Inventário de Trusts

Faça o inventário de todos os trusts e classifique-os:

Get-ADTrust -Filter * |
  Select-Object Name, TrustType, TrustDirection, ForestTransitive, SelectiveAuthentication, SIDFilteringQuarantined

Use o resultado para triagem. SIDFilteringQuarantined = False não é automaticamente prova de comprometimento ou má configuração, mas deveria ter um dono e uma justificativa. Se ninguém conseguir explicar por que o trust precisa de suas configurações atuais, ele pertence à fila de limpeza.

Remediação

O trust mais seguro é aquele que não existe mais porque a dependência de negócio terminou. Reforce os trusts remanescentes de acordo com seu tipo e propósito.

1. Remova Trusts Obsoletos

Revise primeiro trusts antigos de parceiros, migração, teste e aquisição. Se um trust não tem dono, não tem dependência de aplicação ativa e não tem requisito de acesso recente, remova-o pelo processo normal de mudança.

2. Revise o SID Filtering e a Quarentena

Para trusts externos onde for compatível, habilite quarentena ou SID filtering e valide os workflows dependentes. O comando netdom trust da Microsoft suporta a opção /Quarantine para gerenciamento de trusts, e a documentação do comando observa que No aceita qualquer SID. Essa configuração não deveria ficar entregue ao acaso histórico.

3. Use Selective Authentication Onde For Apropriado

Para trusts de floresta, a selective authentication pode limitar quais usuários da floresta confiada podem se autenticar em recursos específicos. Não substitui boas ACLs ou boa higiene de acesso privilegiado, mas reduz o alcance amplo de autenticação.

4. Trate Domínios Filhos como de Alta Consequência

Não presuma que um domínio filho é uma zona administrativa de baixo risco. Proteja os controladores de domínio, grupos privilegiados, o tratamento do krbtgt e as workstations administrativas do domínio filho com a mesma seriedade que a raiz da floresta, quando os caminhos de confiança permitem acesso entre domínios.

5. Reduza Sessões Privilegiadas Entre Fronteiras

Não use rotineiramente contas privilegiadas da raiz da floresta ou do domínio pai em domínios filhos menos confiáveis. Se os administradores precisarem atravessar a fronteira, use contas dedicadas, workstations administrativas controladas e logging que torne a sessão visível.

O que Não Alterar às Cegas

Não habilite nem remova controles de trust sem testar o fluxo de autenticação dependente. SID filtering, quarentena e selective authentication podem quebrar padrões de acesso legados, workflows de migração ou aplicações construídas em torno de um amplo acesso entre domínios. Esse risco de compatibilidade não é motivo para deixar o trust inseguro; é motivo para documentar a dependência, testar em uma janela controlada e substituir o trust amplo por acesso explícito sempre que possível. Se o negócio não puder remover um trust arriscado imediatamente, a exceção deveria incluir um dono, uma data de expiração, um plano de monitoramento e controles compensatórios de acesso privilegiado.

Validação Após o Hardening de Trusts

Depois de uma mudança de trust, valide tanto a segurança quanto a função de negócio:

• execute novamente o inventário de trusts e registre direção, tipo, transitividade, selective authentication e o estado do SID filtering
• confirme que as equipes de aplicação testaram novamente os workflows que dependem do trust
• verifique se trusts antigos de migração ou de parceiros foram removidos, e não apenas documentados
• revise a atividade Kerberos e de logon através do trust após a mudança
• verifique se usuários privilegiados ainda se autenticam através da fronteira
• documente exceções com dono, data de expiração e controles compensatórios

Uma revisão de trust só é bem-sucedida quando os trusts remanescentes são intencionais, têm dono, são monitorados e estão restritos ao acesso que o negócio ainda precisa.

Como o EtcSec Detecta Isso

O EtcSec audita as relações de confiança e destaca caminhos de trust que aumentam a chance de escalada entre domínios.

Os achados relacionados a trusts são mais úteis quando correlacionados com o caminho de ataque ao redor: se um domínio filho já tem higiene administrativa fraca, se um trust externo obsoleto ainda existe, e se identidades de alto valor ou direitos delegados estão em ambos os lados da fronteira.

Leituras Relacionadas

Revise a exposição de trusts junto com Caminhos de Ataque AD: Ma Configuracoes em Cadeia, Aninhamento Perigoso de Grupos AD: Caminhos para Domain Admin, Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin, Ataques Delegacao Kerberos: Nao Restrita a RBCD e Ataque Golden Ticket — Deteccao & Remediacao. O abuso de trust normalmente é um multiplicador de caminho, não uma má configuração isolada.

Referências Primárias

• Como funcionam as relações de confiança para florestas no Active Directory
• MS-PAC: SID Filtering e Claims Transformation
• Uso do DsAddSidHistory: implicações de segurança do sIDHistory
• Comando netdom trust
• Protegendo controladores de domínio contra ataques
• Planejando para o comprometimento no Active Directory