Auditoria Trust Active Directory Filtragem SID Autenticação Seletiva: Detecção e Remediação

Checklist de Auditoria Trust Active Directory Filtragem SID Autenticação Seletiva

Uma auditoria trust Active Directory filtragem SID autenticação seletiva responde a uma pergunta: se o domínio ou floresta do outro lado de um trust for comprometido, até onde um atacante consegue avançar no seu ambiente? Um trust não é um simples interruptor liga/desliga — é um Trusted Domain Object (TDO) que carrega vários atributos de segurança independentes, e cada um deles pode se afastar silenciosamente de um padrão seguro ao longo da vida do trust. Esta checklist cobre as três configurações mais importantes, os comandos exatos para verificá-las e como corrigir cada achado sem quebrar a autenticação de usuários legítimos. Ela é pensada como parte de uma revisão mais ampla — veja Como Auditar a Segurança do Active Directory: O Que Revisar Primeiro e Como Comprovar a Remediação para entender onde os trusts se encaixam no escopo completo.

Três configurações concentram a maior parte do trabalho:

• Filtragem de SID (quarentena) — impede que um domínio confiável comprometido injete SID history forjado para reivindicar associação a grupos privilegiados no seu lado.
• Autenticação seletiva — restringe quais contas no domínio/floresta confiável podem se autenticar em quais recursos do seu lado, em vez de confiar em toda a população.
• Criptografia do trust — se o tráfego Kerberos através do trust ainda pode recorrer a RC4, ou é exclusivamente AES.

Onde as Configurações Realmente Ficam

Todo atributo de trust vive na bitmask trustAttributes do TDO. Segundo o campo TrustAttributes documentado para o evento de segurança do Windows 4716, os bits mais importantes para esta auditoria são 0x4 (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN — filtragem de SID ativa), 0x8 (TRUST_ATTRIBUTE_FOREST_TRANSITIVE — trust cross-forest) e 0x40 (TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL — relaxa a filtragem de forest trust para as regras de external trust). A autenticação seletiva e os tipos de criptografia Kerberos suportados pelo trust ficam armazenados separadamente, no atributo msDS-SupportedEncryptionTypes da conta de trust interdomínio. Nenhuma dessas três configurações depende das outras — um trust pode ter a filtragem de SID ativada e mesmo assim permitir criptografia somente RC4 ou autenticação em toda a floresta, então cada uma precisa da sua própria verificação.

Filtragem de SID: Verificando se a Quarentena Está Realmente Ativa

A filtragem de SID vem habilitada por padrão tanto em trusts externos quanto em trusts de floresta — ela é explicitamente desabilitada em trusts intra-floresta (pai/filho), onde SID history é esperado e confiável. A lacuna do catálogo TRUST_SID_FILTERING_DISABLED é disparada quando a quarentena foi desativada em um trust inter-floresta ou externo, quase sempre resultado de um projeto de migração que a desligou para preservar SID history e nunca a religou.

Verificando o Estado da Quarentena

Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SIDFilteringForestAware, SelectiveAuthentication

SIDFilteringQuarantined = $False em um trust externo ou de floresta significa que o SID history do outro lado é aceito sem filtragem — um administrador comprometido no domínio confiável pode forjar uma entrada de SID history reivindicando associação aos Domain Admins (ou Enterprise Admins) e entrar diretamente pelo trust. O netdom lê e define o mesmo atributo:

netdom trust TrustingDomain /domain:TrustedDomain /quarantine
netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes

Corrigindo Sem Quebrar uma Migração

Autenticação Seletiva: Restringindo Quem Pode se Autenticar

A autenticação seletiva é configurada no lado de saída de um trust externo ou de floresta e restringe a autenticação apenas às contas do lado confiável às quais foi concedido explicitamente o direito estendido Allowed to Authenticate nos objetos de computador específicos que precisam alcançar. Sem ela, qualquer usuário autenticado no domínio ou floresta confiável pode tentar se autenticar em qualquer recurso do lado que confia — o Kerberos ainda vai impor as ACLs em nível de objeto, mas a superfície de ataque para ataques de credenciais, enumeração de recursos e movimento lateral fica dramaticamente maior.

A lacuna TRUST_EXTERNAL_NO_SELECTIVE_AUTH sinaliza trusts externos rodando sem ela — trusts externos costumam ser criados para uma única integração de linha de negócio (um domínio parceiro, uma subsidiária adquirida ainda não fundida) e ficam com autenticação em toda a floresta porque ninguém delimitou as concessões de "Allowed to Authenticate" na configuração.

Verificando o Estado da Autenticação Seletiva

Get-ADTrust -Filter * | Select-Object Name, Direction, SelectiveAuthentication

Um valor $False em um trust externo ou de floresta unidirecional significa que o trust está totalmente aberto a qualquer conta do lado confiável. Compare isso com a real necessidade de negócio — se apenas três contas de serviço de um domínio parceiro precisam alcançar um servidor de arquivos, autenticação seletiva mais três concessões de "Allowed to Authenticate" substitui "todo o domínio parceiro pode alcançar tudo" por uma lista de permissões nomeada e auditável.

Criptografia do Trust: RC4 vs. AES na Rede

O atributo msDS-SupportedEncryptionTypes da conta de trust interdomínio determina quais tipos de criptografia Kerberos são negociados para tickets cross-trust, usando a mesma bitmask que a Microsoft documenta para tipos de criptografia de conta: 0x4 = somente RC4, 0x18 = somente AES128 + AES256, 0x1C = RC4 mais ambas as forças de AES. Um valor 0 (indefinido) recai para RC4_HMAC_MD5. Para o panorama mais amplo de onde o fallback de RC4 ainda aparece fora dos trusts, veja Fallback de Kerberos RC4 no Active Directory.

Verificando os Tipos de Criptografia do Trust

$trustDN = (Get-ADTrust -Filter {Name -eq "trusted.example.com"}).DistinguishedName
Get-ADObject $trustDN -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

• TRUST_RC4_ONLY é disparado quando o atributo resolve para 0x4 — todo ticket de serviço que atravessa o trust usa RC4, o tipo de criptografia por trás da CVE-2022-37966 e da classe de ataque Kerberoasting. A Microsoft afirmou que planeja desativar RC4 como tipo de criptografia suportado assumido por padrão para controladores de domínio até o fim do Q2 de 2026, então um trust somente RC4 também é um problema de compatibilidade futura, não apenas uma lacuna de hardening.
• TRUST_AES_DISABLED é disparado quando os bits de AES (0x8/0x10) estão completamente ausentes do atributo — o trust nunca foi configurado para AES e depende do que o padrão em nível de domínio resolver.

Detecção

Detecção por Log de Eventos

Para o panorama completo de quais Event IDs de Segurança do Windows priorizar além dos trusts, veja Monitoramento do Active Directory: Event IDs de Segurança que Importam.

Verificações de Postura via PowerShell

# Verificação única de postura em todos os trusts
Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

# Forçar uma solicitação de ticket através do trust e ler o tipo de criptografia negociado
klist get HOST/dc01.trusted.example.com

Um resultado de klist mostrando RC4-HMAC onde se esperava AES256-CTS-HMAC-SHA1-96 confirma que o trust ainda está negociando RC4 na prática, não apenas na configuração.

Remediação

Hardening Passo a Passo

1. Reative a filtragem de SID em todo trust externo e de floresta que não esteja em meio a uma migração: netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes.
2. Delimite a autenticação seletiva em trusts externos e de floresta unidirecionais: habilite no lado de saída, depois conceda Allowed to Authenticate apenas nos objetos de computador específicos que as contas do lado confiável realmente precisam acessar — não na OU inteira.
3. Migre os trusts para somente AES: defina msDS-SupportedEncryptionTypes como 0x18 na conta de trust interdomínio, e aplique a GPO Network security: Configure encryption types allowed for Kerberos para restringir a AES128/AES256 em todo o domínio antes de desativar o RC4 no nível do trust, evitando quebrar membros legados que ainda só suportam RC4.
4. Reverifique após a janela de mudança: execute novamente a verificação Get-ADTrust e confirme que o Event ID 4716 registrou a modificação esperada, depois observe os eventos 4768/4769 por alguns dias para confirmar que não há falhas de autenticação inesperadas vindas de dispositivos que ainda precisavam de RC4.

Modo de Falha Comum a Testar

Mapeamento de Conformidade

O hardening de trusts também se relaciona com a orientação estabelecida da ANSSI francesa para Active Directory (ANSSI-PA-099, seção 3.2.3.1), útil se a sua auditoria precisar se vincular a um framework nomeado em vez de apenas boas práticas internas: R24 ("Durcir la configuration des relations d'approbation AD sortantes extraforêt") cobre a reativação da filtragem de SID — removendo TREAT_AS_EXTERNAL e adicionando QUARANTINED_DOMAIN — em trusts de floresta e externos de saída, e R25+ ("Utiliser des relations d'approbation sortantes avec authentification sélective") cobre a delimitação da autenticação seletiva nesses mesmos trusts. Um trust que falha em R24 e R25+ ao mesmo tempo deve ser tratado como o achado de maior prioridade na auditoria, já que não possui nenhuma das duas camadas de controle de acesso abordadas neste artigo. O guia da ANSSI não publica uma recomendação específica de trust para criptografia RC4/AES, portanto trate a verificação de criptografia acima como uma medida de hardening independente. Trate R24/R25+ como uma forma de comunicar a severidade a auditores e stakeholders que já trabalham com o framework da ANSSI, não como substituto das verificações subjacentes de Get-ADTrust e msDS-SupportedEncryptionTypes acima.

Como a EtcSec Detecta Isso

As verificações de Trusts da EtcSec leem diretamente a bitmask trustAttributes do TDO e o atributo msDS-SupportedEncryptionTypes da conta de trust interdomínio, sinalizando TRUST_SID_FILTERING_DISABLED e TRUST_AES_DISABLED/TRUST_RC4_ONLY da mesma forma que Get-ADTrust e Get-ADObject fazem acima, além de TRUST_EXTERNAL_NO_SELECTIVE_AUTH para trusts externos sem a flag de autenticação seletiva. Os achados apontam de volta para o objeto de trust específico e sua direção, de modo que a remediação vai direto ao comando netdom ou PowerShell necessário — sem cruzamento manual entre AD Domains and Trusts e uma planilha. Se o desvio de trusts continuar se repetindo entre auditorias, Workflow de Auditoria Recorrente do AD mostra como detectar isso continuamente em vez de apenas uma vez por ano.