Puntos ciegos supervisión Active Directory: Display Specifiers, RODC, manipulación Default Domain Policy y PAM Shadow Principals

Puntos ciegos supervisión Active Directory: Display Specifiers, RODC y otros dos

Los puntos ciegos de supervisión Active Directory — display specifiers, caché de credenciales RODC, manipulación de la Default Domain Policy y PAM shadow principals — rara vez aparecen en una revisión de seguridad estándar, aunque los cuatro son mecanismos documentados por Microsoft que pueden dar a un atacante persistencia o acceso privilegiado mientras los paneles habituales (pertenencia a Domain Admins, derechos DCSync, cambios de ACL en objetos Tier 0) siguen en verde. Son puntos ciegos porque nadie apunta una SACL o una consulta hacia ellos, no porque estén ocultos.

Este artículo cubre cada uno por turno: qué es realmente el objeto o mecanismo, cómo se abusa de él o cómo deriva, qué vigilar para detectarlo, y cómo solucionarlo.

Display Specifiers: un punto de extensión de la interfaz convertido en backdoor de persistencia

El mecanismo

Los display specifiers son objetos de clase displaySpecifier, almacenados en contenedores específicos por locale bajo CN=DisplaySpecifiers,CN=Configuration,DC=<forest-root> — por ejemplo CN=user-Display,CN=409,CN=DisplaySpecifiers,CN=Configuration. Como residen en el naming context Configuration, se replican a todos los controladores de dominio del bosque. Su propósito documentado, según la referencia de programación Win32 AD de Microsoft, es totalmente legítimo: almacenan los datos detrás de las hojas de propiedades, menús contextuales, iconos y asistentes de creación en herramientas basadas en MMC como Active Directory Users and Computers (ADUC).

Los atributos que hacen esto interesante desde el punto de vista de la seguridad son adminContextMenu y adminPropertyPages (snap-ins administrativos) y sus equivalentes no administrativos contextMenu/shellContextMenu — todos documentados en la especificación de protocolo [MS-ADTS] de Microsoft y en la referencia de clase de esquema Display-Specifier. Cada uno puede registrar un objeto COM o una aplicación para ejecutarse cuando un administrador interactúa con un objeto a través de ADUC. Investigadores de seguridad de Semperis y SDM Software han documentado directamente este caso de abuso: un atacante con acceso de escritura a un display specifier puede añadir una entrada de menú contextual falsa — que parece una acción normal (por ejemplo, una opción de restablecimiento de contraseña) — que en realidad lanza un script cuando un administrador del helpdesk hace clic derecho sobre un objeto usuario.

Detección

Las modificaciones de objetos del directorio generan el Event ID 5136 de seguridad de Windows ("A directory service object was modified"), pero solo si se cumplen dos condiciones: el DC tiene habilitada la subcategoría de auditoría avanzada "Audit Directory Service Changes", y el objeto destino lleva una SACL para los atributos relevantes. Ninguna de las dos está activada por defecto para el contenedor DisplaySpecifiers — precisamente por eso existe este punto ciego. Una vez activada la auditoría, vigile los eventos 5136 donde la clase de objeto sea displaySpecifier y el atributo modificado sea adminContextMenu, adminPropertyPages, contextMenu o shellContextMenu. Vea Supervisión de seguridad AD: los Event ID que importan para la base de política de auditoría más amplia que estos controles asumen.

# Enumera todos los objetos display specifier y sus atributos de menú/hoja de propiedades
Get-ADObject -SearchBase "CN=DisplaySpecifiers,CN=Configuration,$((Get-ADRootDSE).configurationNamingContext)" `
  -Filter "objectClass -eq 'displaySpecifier'" `
  -Properties adminContextMenu, adminPropertyPages, contextMenu, shellContextMenu |
  Where-Object { $_.adminContextMenu -or $_.adminPropertyPages -or $_.contextMenu -or $_.shellContextMenu } |
  Select-Object Name, adminContextMenu, adminPropertyPages, contextMenu, shellContextMenu

Una base saludable para esta consulta es un conjunto de resultados vacío en la mayoría de los dominios — cualquier resultado merece una revisión manual del CLSID COM o de la ruta de aplicación referenciada.

Manipulación de la Default Domain Policy: cambios silenciosos en la base de seguridad del dominio

El mecanismo

La Default Domain Policy lleva un GUID conocido e independiente del bosque — {31B2F340-016D-11D2-945F-00C04FB984F9} — y aplica la base de política de cuenta, contraseña, Kerberos y bloqueo a nivel de dominio, salvo que sea sobrescrita por una GPO más específica. Como ese GUID está codificado y es predecible, y como esa GPO es lo bastante antigua como para que la mayoría de los equipos dejaran de revisarla tras el endurecimiento inicial, los cambios que se le hacen suelen pasar desapercibidos. MITRE ATT&CK cataloga la manipulación de GPO como la subtécnica T1484.001 (Domain or Tenant Policy Modification: Group Policy Modification) — los adversarios alteran GPO para debilitar los umbrales de bloqueo de cuenta, desactivar la complejidad de contraseñas, o distribuir una tarea programada/script de inicio de sesión a cada equipo que aplique la política.

Detección

Dos Event ID distintos cubren capas diferentes de un cambio de GPO, y confundirlos es un error habitual:

• Event ID 5136 ("A directory service object was modified") se dispara en el propio objeto AD groupPolicyContainer cuando la subcategoría "Audit Directory Service Changes" y una SACL en el objeto están ambas activas. Tanto la investigación de detección de Splunk como las propias guías de detección de MITRE señalan específicamente vigilar los atributos gPCFileSysPath, gPCMachineExtensionNames y versionNumber — un incremento de versión sin una solicitud de cambio SYSVOL correspondiente es en sí mismo una señal a marcar.
• Event ID 4739 ("Domain Policy was changed") se dispara cuando la política de cuenta efectiva — umbral de bloqueo, política de contraseñas, política Kerberos — cambia realmente, ya sea que ese cambio provenga de Group Policy o de Local Security Policy. Es el evento de mayor señal para saber "si la base de seguridad en sí se movió", pero no indica qué GPO o qué administrador hizo el cambio — combínelo con el 5136 para la atribución.

# Boceto de detección estilo Splunk: modificación del objeto Default Domain Policy
index=wineventlog EventCode=5136 ObjectDN="*CN=Policies,CN=System,DC=*"
| search ObjectDN="*{31B2F340-016D-11D2-945F-00C04FB984F9}*"
| table _time, SubjectUserName, AttributeLDAPDisplayName, AttributeValue, OperationType

PAM Shadow Principals: acceso admin efímero que las consultas estándar no detectan

El mecanismo

La función Privileged Access Management (PAM) de Windows Server, construida sobre Microsoft Identity Manager, concede acceso privilegiado limitado en el tiempo sin añadir nunca una cuenta a un grupo permanente como Domain Admins. La propia documentación PAM de Microsoft describe el mecanismo: un shadow principal — un objeto de clase msDS-ShadowPrincipal, creado únicamente dentro del contenedor por defecto CN=Shadow Principal Configuration bajo CN=Services en el NC Configuration de un bosque bastión — lleva un atributo msDS-ShadowPrincipalSid que lo mapea a un SID de grupo privilegiado en el bosque de producción (por ejemplo, Domain Admins). La pertenencia a ese shadow principal se concede con un tiempo de vida (TTL) mediante la función AD Expiring Links (Windows Server 2016+): el KDC limita cualquier ticket Kerberos que emite al TTL restante del enlace, de modo que el acceso realmente expira en lugar de depender de que alguien recuerde eliminarlo.

El punto ciego: los enlaces de grupo expirables se almacenan como valores ordinarios del atributo member con un indicador de TTL, pero ese TTL solo es visible para una consulta que pase explícitamente el control extendido LDAP_SERVER_LINK_TTL (OID 1.2.840.113556.1.4.2309), como documenta la investigación de DSInternals sobre el funcionamiento real de Expiring Links. Una consulta rutinaria de "quién está en este grupo" que no pase ese control ve una pertenencia de apariencia normal — sin expiración, sin indicador de límite temporal evidente — lo que significa que un administrador que escanee grupos shadow principal con herramientas de auditoría AD genéricas puede no notar que el acceso es efímero por diseño, o puede pasar por alto por completo altas de pertenencia de corta duración si el intervalo de escaneo es más largo que el TTL.

Detección

Los grupos shadow principal siguen siendo objetos de clase grupo de seguridad, por lo que las altas de pertenencia generan los mismos eventos AD estándar de pertenencia a grupo que cualquier otro grupo, según el tipo de grupo: 4728 (miembro añadido a un grupo de seguridad global), 4732 (dominio local), 4756 (universal). Filtre estos eventos específicamente para objetos dentro de CN=Shadow Principal Configuration,CN=Services,CN=<config-NC> para aislar las activaciones PAM de la administración rutinaria de grupos.

# Lista los shadow principals actuales y su SID de bosque de producción asociado
Get-ADObject -SearchBase "CN=Shadow Principal Configuration,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" `
  -Filter "objectClass -eq 'msDS-ShadowPrincipal'" `
  -Properties 'msDS-ShadowPrincipalSid', member |
  Select-Object Name, 'msDS-ShadowPrincipalSid', @{N='MemberCount';E={$_.member.Count}}

Caché de credenciales RODC, en breve

Los Read-Only Domain Controllers (RODC) se despliegan específicamente para sedes de baja confianza — oficinas remotas, ubicaciones físicamente expuestas — bajo el supuesto de que, si uno se ve comprometido, el radio de impacto se limita a las contraseñas de cuenta que tenía permitido cachear. Ese límite lo aplican dos pertenencias a grupo: el Allowed RODC Password Replication Group (vacío por defecto — un RODC no cachea nada hasta que se le permite explícitamente) y el Denied RODC Password Replication Group, correspondientes a los atributos msDS-RevealOnDemandGroup y msDS-NeverRevealGroup documentados por Microsoft. Lo que realmente se ha cacheado es visible mediante msDS-RevealedList; quién se autenticó a través del RODC está en msDS-AuthenticatedToAccountlist.

Este es el único punto ciego de este artículo donde la solución es sobre todo una cuestión de política, no una laguna de supervisión que la mayoría de los equipos desconozca — EtcSec ya ha cubierto el recorrido completo de detección y remediación para la caché privilegiada en RODC, incluidas las configuraciones erróneas exactas de la Password Replication Policy que permiten que una credencial Tier 0 acabe replicada donde nunca debería estar. Vea RODC almacenamiento en caché de credenciales privilegiadas: el controlador de dominio de solo lectura que guarda los hashes de Domain Admin para el análisis en profundidad; el resumen aquí es deliberadamente breve para no duplicarlo.

Puntos ciegos supervisión Active Directory: qué vigilar realmente

Ninguno de estos controles requiere un nuevo pipeline de registro — necesitan SACL colocadas en objetos que no las traen por defecto, y alguien que consulte atributos que los scripts estándar de comprobación de salud de AD no tocan.

Remediación

Paso a paso

1. Display specifiers. Coloque una SACL de "Write all properties" (o, más específicamente, sobre los atributos concretos de menú/hoja de propiedades) en CN=DisplaySpecifiers,CN=Configuration,DC=<forest-root> y sus hijos. Establezca ahora una línea base de los valores actuales de adminContextMenu/adminPropertyPages, ya que una backdoor comprometida podría ya estar presente.
2. Default Domain Policy. Aplique una SACL al objeto groupPolicyContainer de la Default Domain Policy y a su carpeta SYSVOL (\\<domain>\SYSVOL\<domain>\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}). Genere alertas ante cualquier par 5136/4739 que no corresponda a un ticket de cambio registrado.
3. PAM shadow principals. Si PAM/MIM no está desplegado intencionalmente, confirme que el contenedor CN=Shadow Principal Configuration está vacío y que permanece así. Si está desplegado, revise la pertenencia a shadow principals con una cadencia que tenga en cuenta TTL más cortos que su intervalo de revisión — un enlace que expiró entre dos escaneos semanales nunca aparece en ninguno de los dos a menos que compare eventos 4728/4732/4756, no solo instantáneas puntuales de pertenencia.
4. Caché de credenciales RODC. Confirme que el Allowed RODC Password Replication Group no contiene ningún principal Tier 0, directa o indirectamente mediante pertenencia a grupo anidada — vea el artículo dedicado enlazado arriba para el recorrido completo de remediación, incluidos los controles precisos de la política de replicación.
5. Envíe los cinco Event ID anteriores (5136, 4739, 4728, 4732, 4756) al SIEM que ya ingiere su base de política de auditoría de Active Directory — esto es una extensión de la auditoría existente de Account Management y Policy Change, no una nueva categoría de registro, y encaja de forma natural con los procesos existentes de supervisión de GPO y revisión de acceso privilegiado.

Cómo detecta esto EtcSec

Los detectores Advanced y Computers de EtcSec señalan automáticamente estos cuatro puntos ciegos en cada auditoría AD: DISPLAY_SPECIFIER_CHANGES detecta modificaciones recientes en objetos display specifier, DEFAULT_DOMAIN_POLICY_CHANGED señala cambios en la política de seguridad base del dominio, EPHEMERAL_ADMINS_PAM revela actividad de shadow principals PAM (incluidas pertenencias de TTL corto que un instantáneo manual pasaría por alto), y RODC_PRIVILEGED_CACHING — clasificado como Crítico — detecta credenciales Tier 0 replicadas a un RODC.