Filtrado SID Active Directory: autenticación selectiva, detección y remediación de confianzas

Filtrado SID Active Directory: checklist de auditoría de la autenticación selectiva en confianzas

Una auditoría del filtrado SID Active Directory y de la autenticación selectiva en las confianzas responde a una sola pregunta: si el dominio o el bosque al otro lado de una confianza está comprometido, ¿hasta dónde puede avanzar un atacante dentro del suyo? Una confianza no es un simple interruptor on/off — es un Trusted Domain Object (TDO) que porta varios atributos de seguridad independientes, y cada uno puede desviarse silenciosamente de una configuración segura por defecto a lo largo de la vida de la confianza. Esta checklist cubre los tres ajustes más importantes, los comandos exactos para verificarlos, y cómo corregir cada hallazgo sin romper la autenticación de los usuarios legítimos. Es una pieza más de una revisión más amplia — vea Auditar la seguridad de Active Directory: qué revisar primero y cómo demostrar la remediación para ver dónde encajan las confianzas en el alcance completo.

Tres ajustes hacen la mayor parte del trabajo:

• El filtrado SID (cuarentena) — impide que un dominio de confianza comprometido inyecte un historial SID falsificado para reclamar pertenencia a un grupo privilegiado en su lado.
• La autenticación selectiva — restringe qué cuentas del dominio/bosque de confianza pueden autenticarse en qué recursos de su lado, en lugar de confiar en toda la población.
• El cifrado de la confianza — indica si el tráfico Kerberos que atraviesa la confianza todavía puede caer a RC4, o si es exclusivamente AES.

Dónde viven realmente estos ajustes

Cada atributo de confianza vive en el bitmask trustAttributes del TDO. Según el campo TrustAttributes documentado para el evento de seguridad de Windows 4716, los bits más importantes para esta auditoría son 0x4 (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN — filtrado SID activo), 0x8 (TRUST_ATTRIBUTE_FOREST_TRANSITIVE — confianza transitiva entre bosques) y 0x40 (TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL — relaja el filtrado de una confianza de bosque hacia las reglas de una confianza externa). La autenticación selectiva y los tipos de cifrado Kerberos soportados por la confianza se almacenan por separado, en el atributo msDS-SupportedEncryptionTypes de la cuenta de confianza interdominio. Ninguno de estos tres ajustes depende de los otros — una confianza puede tener el filtrado SID activado y aun así permitir cifrado solo RC4 o autenticación a nivel de todo el bosque, así que cada uno necesita su propia verificación.

Filtrado SID: verificar que la cuarentena está realmente activa

El filtrado SID está activado por defecto tanto en confianzas externas como en confianzas de bosque — está explícitamente desactivado para las confianzas intra-bosque (padre/hijo), donde se espera y se confía en el historial SID. El hallazgo TRUST_SID_FILTERING_DISABLED se dispara cuando la cuarentena ha sido desactivada en una confianza entre bosques o externa, lo que casi siempre es resultado de un proyecto de migración que la desactivó para preservar el historial SID y nunca la volvió a activar.

Verificar el estado de la cuarentena

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

SIDFilteringQuarantined = $False en una confianza externa o de bosque significa que el historial SID proveniente del otro lado se acepta sin filtrado — un administrador comprometido en el dominio de confianza puede falsificar una entrada de historial SID reclamando pertenencia a Domain Admins (o Enterprise Admins) y entrar directamente a través de la confianza. netdom lee y establece el mismo atributo:

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

Corregirlo sin romper una migración

Autenticación selectiva: restringir quién puede autenticarse

La autenticación selectiva se configura en el lado saliente de una confianza externa o de bosque y restringe la autenticación únicamente a las cuentas del lado de confianza a las que se les ha otorgado explícitamente el derecho extendido Allowed to Authenticate sobre los objetos de equipo específicos que necesitan alcanzar. Sin ella, cualquier usuario autenticado del dominio o bosque de confianza puede intentar autenticarse contra cualquier recurso del lado que confía — Kerberos seguirá aplicando las ACL a nivel de objeto, pero la superficie de ataque para ataques de credenciales, enumeración de recursos y movimiento lateral es dramáticamente mayor.

El hallazgo TRUST_EXTERNAL_NO_SELECTIVE_AUTH señala confianzas externas que operan sin ella — las confianzas externas se configuran con frecuencia para una única integración de línea de negocio (un dominio socio, una filial adquirida aún no fusionada) y se dejan con autenticación a nivel de todo el bosque porque nadie delimitó los otorgamientos de "Allowed to Authenticate" durante la configuración.

Verificar el estado de la autenticación selectiva

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

Un valor $False en una confianza externa o una confianza de bosque unidireccional significa que la confianza está completamente abierta a todas las cuentas del lado de confianza. Compare esto con la necesidad real del negocio — si solo tres cuentas de servicio de un dominio socio necesitan alcanzar un único servidor de archivos, la autenticación selectiva más tres otorgamientos de "Allowed to Authenticate" reemplazan "todo el dominio socio puede alcanzar todo" por una lista de permitidos nombrada y auditable.

Cifrado de la confianza: RC4 frente a AES en la red

El atributo msDS-SupportedEncryptionTypes de la cuenta de confianza interdominio determina qué tipos de cifrado Kerberos se negocian para los tickets que atraviesan la confianza, usando el mismo bitmask documentado por Microsoft para los tipos de cifrado de cuenta: 0x4 = solo RC4, 0x18 = solo AES128 + AES256, 0x1C = RC4 más ambas fuerzas de AES. Un valor 0 (indefinido) cae a RC4_HMAC_MD5. Para una imagen más amplia de dónde el fallback a RC4 sigue apareciendo fuera de las confianzas, vea Fallback a Kerberos RC4 en Active Directory.

Verificar los tipos de cifrado de la confianza

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

• TRUST_RC4_ONLY se dispara cuando el atributo resuelve a 0x4 — todo ticket de servicio que atraviesa la confianza usa RC4, el tipo de cifrado detrás de CVE-2022-37966 y de la clase de ataque Kerberoasting. Microsoft ha declarado que planea desactivar RC4 como tipo de cifrado soportado asumido por defecto en los controladores de dominio para finales del Q2 de 2026, así que una confianza solo-RC4 es también un problema de compatibilidad futura, no solo una brecha de hardening.
• TRUST_AES_DISABLED se dispara cuando los bits AES (0x8/0x10) están totalmente ausentes del atributo — la confianza nunca se configuró para AES y depende de lo que resuelva el valor por defecto a nivel de dominio.

Detección

Detección por registros de eventos

Para la imagen completa de qué ID de eventos de seguridad de Windows priorizar más allá de las confianzas, vea Monitoreo de Active Directory: los ID de eventos de seguridad que importan.

Verificaciones de postura con PowerShell

# Verificación de postura de un solo paso en todas las confianzas
Get-ADTrust -Filter * | Select-Object Name, Direction, ForestTransitive, `
    SIDFilteringQuarantined, SelectiveAuthentication

# Forzar una solicitud de ticket a través de la confianza y leer el tipo de cifrado negociado
klist get HOST/dc01.trusted.example.com

Un resultado de klist que muestra RC4-HMAC cuando esperaba AES256-CTS-HMAC-SHA1-96 confirma que la confianza todavía negocia RC4 en la práctica, no solo en la configuración.

Remediación del filtrado SID Active Directory y la autenticación selectiva

Hardening paso a paso

1. Reactivar el filtrado SID en cada confianza externa y de bosque que no esté en plena migración: netdom trust TrustingDomain /domain:TrustedDomain /quarantine:Yes.
2. Delimitar la autenticación selectiva en confianzas externas y de bosque unidireccionales: activarla en el lado saliente, y luego otorgar Allowed to Authenticate únicamente sobre los objetos de equipo específicos que las cuentas del lado de confianza realmente necesitan — no sobre toda la OU.
3. Migrar las confianzas a solo AES: establecer msDS-SupportedEncryptionTypes a 0x18 en la cuenta de confianza interdominio, y aplicar la GPO Network security: Configure encryption types allowed for Kerberos para restringir a AES128/AES256 a nivel de dominio antes de desactivar RC4 a nivel de confianza, para evitar romper a los miembros heredados que aún solo soportan RC4.
4. Reverificar tras la ventana de cambio: volver a ejecutar la verificación Get-ADTrust y confirmar que el ID de evento 4716 registró la modificación esperada, y luego vigilar 4768/4769 durante unos días para confirmar que no haya fallos de autenticación inesperados desde dispositivos que aún necesitaban RC4.

Modo de fallo común que hay que probar

Correspondencia de cumplimiento

El hardening de confianzas también se corresponde con la guía francesa de la ANSSI sobre seguridad de Active Directory (ANSSI-PA-099, sección 3.2.3.1), útil si su auditoría necesita vincularse a un marco con nombre en lugar de solo buenas prácticas internas: R24 ("Durcir la configuración des relations d'approbation AD sortantes extraforêt") cubre la reactivación del filtrado SID — retirando TREAT_AS_EXTERNAL y añadiendo QUARANTINED_DOMAIN — en confianzas salientes de bosque y externas, y R25+ ("Utiliser des relations d'approbation sortantes avec authentification sélective") cubre la delimitación de la autenticación selectiva en esas mismas confianzas. Una confianza que falle tanto R24 como R25+ a la vez debe tratarse como el hallazgo de mayor prioridad de la auditoría, ya que no cuenta con ninguna de las dos capas de control de acceso que trata este artículo. La guía de la ANSSI no publica una recomendación específica para confianzas sobre cifrado RC4/AES, así que trate la verificación de cifrado anterior como una medida de hardening independiente. Trate R24/R25+ como una forma de comunicar la severidad a auditores y partes interesadas que ya trabajan con el marco de la ANSSI, no como un reemplazo de las verificaciones subyacentes Get-ADTrust y msDS-SupportedEncryptionTypes de arriba.

Cómo lo detecta EtcSec

Las verificaciones de Trusts de EtcSec leen directamente el bitmask trustAttributes del TDO y el atributo msDS-SupportedEncryptionTypes de la cuenta de confianza interdominio, señalando TRUST_SID_FILTERING_DISABLED y TRUST_AES_DISABLED/TRUST_RC4_ONLY de la misma forma que lo hacen Get-ADTrust y Get-ADObject arriba, más TRUST_EXTERNAL_NO_SELECTIVE_AUTH para las confianzas externas que carecen del flag de autenticación selectiva. Los hallazgos enlazan de vuelta al objeto de confianza específico y su dirección, para que la remediación apunte exactamente al comando netdom o PowerShell necesario — sin cruzar manualmente AD Domains and Trusts contra una hoja de cálculo. Si la deriva de confianzas sigue reapareciendo entre auditorías, Flujo de auditoría recurrente de AD explica cómo detectarla de forma continua en lugar de una vez al año.