Controles extendidos LDAP potentes: Anti-remediación y reconocimiento invisible en AD

Demostrado en un laboratorio de dos DC cloud.lab (Windows Server 2022, nivel funcional de bosque 2016). Solo en contexto de laboratorio e investigación autorizada.

Hallazgo 1 - FORCE_UPDATE: Conflictos de replicación ganadores a partir de una única escritura LDAP

La idea en lenguaje sencillo

Si ya conoces la replicación de AD a la perfección, puedes avanzar. De lo contrario, aquí tienes una analogía.

Imagina una empresa con dos archivadores idénticos en dos oficinas diferentes. Estos son los dos controladores de dominio (DCs). Para mantenerse sincronizados, cada cambio realizado en uno se copia al otro. Esa copia es la replicación.

¿Qué pasa si dos personas editan el mismo archivo al mismo tiempo en diferentes oficinas, antes de que la copia se sincronice? Los gabinetes no están de acuerdo, y AD necesita una regla para decidir quién gana:

1. Gana quien tenga el número de versión más alto. Cada campo recuerda cuántas veces ha sido modificado y ese conteo es su "versión."
2. Solo si las versiones empatan, AD mira quién editó más recientemente (marca de tiempo).
3. Si eso también empata, se desempata por el ID del gabinete.

El truco: normalmente, si “editas” un campo escribiendo de nuevo el valor exacto que ya tenía, AD se encoge de hombros, dice “nada cambió” y la versión permanece igual. FORCE_UPDATE es una bandera que dice “cuenta esto como un cambio real de todos modos.” Así que puedes escribir Bob sobre un campo que ya dice Bob seis veces, y la versión sube a 6 aunque el valor nunca cambió.

Entonces un atacante realiza un cambio malicioso en un campo que puede editar, lo golpea con FORCE_UPDATE varias veces para aumentar la versión a 6 y espera. Cuando un defensor lo corrige en el otro gabinete (cualquier otro DC), es una edición nueva y posterior, pero el primer cambio en ese campo, por lo que la versión es 1. Los gabinetes se sincronizan, AD compara 6 contra 1, y 6 gana: el valor del atacante vuelve y la corrección del defensor desaparece silenciosamente. El atacante forzó un cambio que supera a uno más nuevo y legítimo.

Dos advertencias honestas: solo funciona en campos que ya podrías editar (es persistencia, no escalada), y no es invisible. Deja un campo cuya versión saltó sin cambio de valor. La parte realmente nueva es el “precio de admisión”: el famoso ataque DCShadow hace el mismo movimiento de "mi versión gana" pero necesita poderes casi divinos de dominio (pretendiendo ser un DC); esto necesita una escritura ordinaria y permiso en un campo.

Antecedentes: Cómo AD decide quién gana

Active Directory es multi-master, lo que significa que cada DC escribible acepta cambios que se replican hacia afuera. Se puede indicar a dos DC que cambien el mismo atributo del mismo objeto antes de que la replicación los reconcilie. Para un conflicto por atributo el orden de desempate es:

1. Versión - un contador por atributo que se incrementa en cada escritura de origen.
2. Marca de tiempo - se usa solo si las versiones son iguales.
3. Server (DSA) GUID - usado solo si la versión y están empatados en la marca de tiempo.

Estos metadatos son por atributo, visibles mediante repadmin /showobjmeta o msDS-replAttributeMetaData. La propiedad crucial: una versión inferior siempre pierde frente a una versión superior, sin importar cuánto más nueva sea. Y un MODIFY que escribe el valor existente de un atributo normalmente no hace nada (AD no incrementa la versión). Normalmente no puedes aumentar la versión reescribiendo el mismo valor.

El control: LDAP_SERVER_FORCE_UPDATE (1.2.840.113556.1.4.1974)

FORCE_UPDATE es un control documentado y benigno por su encuadre: según MS-ADTS, indica al DC que procese la modificación incluso cuando de otro modo sería una operación sin efecto (“actualizar incluso si los datos nuevos son idénticos”). La biblioteca Java ldaptive incluye un ForceUpdateControl que hace exactamente esto, sin encuadre de ataque. El efecto secundario importante: debido a que la escritura forzada cuenta como una escritura originaria real, incrementa la versión por atributo sin cambio de valor. Esa es la conexión. La marca de versión se considera convencionalmente inaccesible para un cliente LDAP (por eso DCShadow la manipula a través del protocolo de replicación como un DC malicioso); FORCE_UPDATE la pone al alcance desde una MODIFICACIÓN LDAP.

La técnica

1. Seleccione un atributo objetivo que el principal ya puede escribir (un WriteProperty ACE).
2. Establezca el valor malicioso en DC-A.
3. Inflar la versión: enviar N MODIFY adicionales con el mismo valor, cada uno con FORCE_UPDATE, cada uno aumentando la versión sin ningún cambio visible.
4. Espera: Un defensor corrige el valor, naturalmente en cualquier DC al que estén conectados (DC-B). Su única corrección incrementa la versión en uno (a actual+1). Mientras el atacante haya inflado por encima de eso, el atacante aún tiene un rango superior. (En el laboratorio, el defensor llegó a la versión 1 solo porque el atributo no estaba establecido previamente; en general, el atacante solo necesita superar en versión la corrección, lo cual es gratuito.)
5. Convergencia: AD compara versiones; la versión inflada del atacante supera la corrección posterior pero menor del defensor. El valor del atacante gana en ambos DC.

El defensor ve que su cambio “no se mantiene”: lo arreglan, parece arreglado y minutos después vuelve a revertirse.

Modelo de privilegios vs DCShadow: La parte novedosa

La percepción no obvia: LDAP puede alcanzar la marca de versión por atributo. FORCE_UPDATE rompe silenciosamente la suposición de "debes hablar el protocolo de replicación como un DC" desde la superficie del cliente.

Demostración (laboratorio de dos DC)

Atacante = svc-research, un usuario de dominio simple delegado solo WP;descripción (sin derechos de replicación). Las acciones del atacante se ejecutan bajo su propia vinculación NTLM; el contexto de administrador se usa únicamente para la orquestación del laboratorio (delegación, pausa/reanudación de replicación, simulación del defensor).

      Step 1 — low-priv writer bumps the version:
  baseline:                      description  version 1
  attacker no-op FORCE_UPDATE -> description  version 2   (no value change)

Step 2 — stage and win the conflict (replication paused):
  DC01:  description='ATTACKER-OWNED'            version 6  @ 19:58:34  (attacker, FORCE_UPDATE x3)
  DC-02: description='defender-remediation-LATER' version 1 @ 19:58:36  (defender, LATER, lower version)
  => CONVERGED: DC01 = DC-02 = 'ATTACKER-OWNED'   (defender's later fix reverted)
      

El ingrediente ofensivo completo es un MODIFY con el control adjunto:

      var m = new ModifyRequest(dn, DirectoryAttributeOperation.Replace, "description", value);
m.Controls.Add(new DirectoryControl("1.2.840.113556.1.4.1974", null, true, true)); // FORCE_UPDATE, critical
connection.SendRequest(m);   // same-value write now bumps the per-attribute version
      

Impacto, alcance y limitaciones

Un primitivo anti-remediación / persistencia: hacer que un valor atacante sea terco contra la limpieza para cualquier atributo que el atacante ya pueda escribir, por ejemplo msDS-AllowedToActOnBehalfOfOtherIdentity (puerta trasera RBCD), servicePrincipalName (reafirmar un objetivo Kerberoast), scriptPath / gPLink (punto de apoyo persistente).

• Límite del alcance (probado): linked atributos (member / memberOf) no se ven afectados. Se replican mediante Linked-Value Replication con metadatos por valor; una re-adición FORCE_UPDATE sin efecto de un miembro existente tiene éxito pero no incrementa la versión del valor del enlace. Por lo tanto, la pertenencia a grupos no puede fijarse de esta manera, solo los atributos no vinculados de valor único y múltiple.
• Requiere acceso de escritura existente (no escalada), y el defensor debe corregir en un DC diferente (o preconvergencia) para que exista el conflicto.
• No sigiloso: deja un salto anormal de versión sin cambio de valor, y un valor que “vuelve” después de la remediación (harmj0y, Hunting With AD Replication Metadata, 2017).

Novedad: Una revisión previa de arte con múltiples barridos, además de una búsqueda autenticada de código nativo en GitHub (~1,000+ resultados OID) no encontró publicación de este primitivo específico. Casi todos los resultados son inertes (cabeceras SDK, enlaces de lenguaje, disectores, volcados CTF supportedControl). Los vecinos más cercanos son DCShadow (mismo efecto, DA/EA a través de un DC malicioso), LDAPAngel/RIFM (una herramienta de recuperación de bosque que envía FORCE_UPDATE, pero no de forma crítica para su propósito operativo FSMO/GC, no para inflar versiones), el benigno ForceUpdateControl de ldaptive, y la carrera de "Objetos en Conflicto" a nivel de objeto de Tenable. Ninguno usa esta técnica. La ausencia de evidencia no es prueba, pero la victoria en conflicto / la aplicación anti-remediación parece no publicada.

Hallazgo 2 - OBJECT_SECURITY DirSync: Enumerando Active Directory sin rastro de registro

La idea en lenguaje sencillo

Un usuario normal ya puede consultar la mayoría de las cosas en Active Directory: nombres, membresías de grupos, incluso las listas de permisos (ACL) en objetos que puede leer. Normalmente, esas consultas pueden ser registradas por el registro de consultas del DC. DirSync es una función de sincronización destinada a herramientas como Entra Connect para extraer cambios. Una de sus opciones, OBJECT_SECURITY, permite a un usuario común ejecutarla para leer todo lo que ya puede leer en Active Directory con sus permisos, pero debido a que utiliza la replicación en lugar de la ruta normal de búsqueda, el DC no registra nada. Son los mismos datos que un usuario ya podría recopilar, pero sin dejar rastro. Este método también proporciona un "marcador" (cookie) para volver más tarde solo por lo que cambió en AD.

El mecanismo

DirSync (LDAP_SERVER_DIRSYNC_OID, .841) tiene dos modos:

• flags=0 utiliza semánticas completas de replicación y requiere el derecho de replicación Get-Changes. Este es el camino privilegiado, adyacente a DCSync, y está registrado mediante el Evento 4662.
• OBJECT_SECURITY (bandera 0x1) es la ruta no privilegiada documentada para llamantes ordinarios: requiere ningún derecho de replicación ni cambio de permisos, solo Domain Users, y limita los resultados a los datos que el llamante ya puede leer. (Esta es la ruta que Simon Décosse, simondotsh, documentó en 2022. Mi contribución es la consecuencia validada de la detección.)

Debido a que OBJECT_SECURITY ejerce no Get-Changes right, produce no Event 4662; y debido a que DirSync utiliza la replication code path rather than the search path, produce no Event 1644. Queda completamente entre las dos fuentes de registro del host.

La cookie DirSync que devuelve también le permite reconectarse más tarde y extraer solo los cambios desde la última vez, por lo que también funciona como un monitor de cambios de bajo ruido.

Por qué es una oportunidad sigilosa

Es una oportunidad genuina para la fase de reconocimiento / enumeración:

• Sin acceso especial: Cualquier cuenta de dominio comprometida funciona. No hay derecho de replicación para solicitar, ningún cambio en schema/searchFlags, nada que por sí mismo parezca sospechoso.
• Sin huella: Recolección masiva de objetos y membresías con registro sin costo, además de una sincronización delta incorporada para monitoreo continuo.

Esto es sigiloso, no un nuevo acceso. No proporciona al atacante datos que no podría leer de otra manera. Se limita al acceso de lectura efectivo, devolviendo exactamente lo que una búsqueda LDAP ordinaria devolvería. Lo crucial es que no pasa por alto la puerta de atributo confidencial (searchFlags 0x80): un atributo confidencial se devuelve solo si el llamador tiene derecho genuino a leerlo (posee el derecho CONTROL_ACCESS). Esa omisión pertenece al otro modo DirSync, flags=0, que usa la semántica de replicación para filtrar atributos confidenciales a cualquiera con el derecho Get-Changes (tema del post complementario sobre puntos ciegos de detección). OBJECT_SECURITY tampoco puede leer secretos (no es DCSync, por lo que no hay material de contraseña). Lo que cambia es puramente la evasión: una búsqueda ordinaria de SD_FLAGS dejaría registros del Evento 1644 dondequiera que el registro de consultas LDAP esté activado; la versión DirSync de OBJECT_SECURITY no deja ninguno en ningún registro. El valor para un atacante es una colección de bajo ruido que derrota la telemetría de búsqueda LDAP en la que confían los defensores, por eso vale la pena conocerla aunque no otorgue ningún privilegio nuevo.

Detección y defensa

Ambos hallazgos comparten un tema: la obvia idea de detección no funciona, y los registros del host están más cegados de lo que los defensores suponen. Todo lo siguiente fue validado al ejecutar las técnicas en el laboratorio.

FORCE_UPDATE (Hallazgo 1)

• Primario - búsqueda de metadatos de replicación: Instantánea msDS-replAttributeMetaData (o repadmin /showobjmeta) para atributos sensibles y alerta cuando una versión por atributo aumenta mientras el hash del valor permanece sin cambios. En el laboratorio esto detectó el ataque claramente (descripción versión 28 → 29, valor sin cambios). Un segundo síntoma: un valor que reaparece después de la remediación.
• El evento 1644 no lo detecta: FORCE_UPDATE utiliza un MODIFY; el evento 1644 registra solo búsquedas, por lo que el modify no genera ningún evento 1644. Así, una regla basada en el .1974 OID en los registros de consultas nunca se activa. La detección por cable requiere PCAP/ETW, y el control requiere un signed bind (un simple/Basic bind es rechazado), limitando la visibilidad de cleartext-389.
• Endurecimiento: Minimice WriteProperty en atributos sensibles (el prerrequisito completo); remedie en el mismo DC (cuando sea posible) y verifique la versión después.

OBJECT_SECURITY DirSync (Hallazgo 2)

• Los registros del host no lo verán: No hay 4662 (sin derecho Get-Changes) ni 1644 (ruta de replicación), por lo que no hay regla de evento para escribir; este es el punto ciego.
• Lo que realmente funciona es limitado: La captura realista es network / ETW capture del control DirSync en la red (sujeto a LDAPS) más establecer una línea base del uso de DirSync y alertar sobre ello desde cualquier fuente que no sea de sincronización. Un SACL read-canary no es fiable como respaldo aquí: en pruebas, un ACE de auditoría ReadProperty no generó el Evento 4662 para una lectura ordinaria del atributo. La auditoría de lectura del host de AD no es confiable, y la lectura de la ruta de replicación de DirSync no cambia eso. (Los canarios SACL son confiables contra la actualización FORZADA write y contra los derechos de replicación DirSync/DCSync, pero no contra esta lectura sigilosa.)
• Observa también el ángulo de ADWS: Los cmdlets de PowerShell AD (Get-ADUser y similares) no hablan LDAP directamente. En cambio, pasan por Active Directory Web Services (ADWS, TCP 9389), que retransmite la consulta al DC localmente. Por eso, el Evento 1644 registra al cliente como 127.0.0.1 (el propio DC), no la dirección real del operador.
  • Por qué es importante: Cada regla 1644 debe excluir 127.0.0.1. Debido a que las búsquedas internas del DC generan ruido constante de loopback, esa misma exclusión también elimina cualquier actividad que un atacante proxy a través de ADWS. Solo la visibilidad de red/ETW ve la fuente verdadera.

Canarios SACL: qué son y dónde ayudan

Varias recomendaciones anteriores se basan en canarios SACL, así que hablemos de ellos. El descriptor de seguridad de cada objeto AD lleva dos listas de control de acceso:

• DACL: decide quién puede hacer qué (permisos)
• SACL: (System ACL) decide qué se audita

Un ACE de auditoría SACL dice “cuando se accede a este objeto o atributo, emite el Evento de Seguridad de Windows Event 4662.” Un canary es un tripwire colocado deliberadamente al estilo “honeytoken” en un objeto de alto valor que la actividad legítima rara vez toca, por lo que cualquier acceso lo activa. Debido a que se evalúa en la capa de acceso al objeto (no en la capa de control o registro), se dispara independientemente de qué control o transporte LDAP se haya usado.

Para desplegar:

• Habilite Audit Directory Service Access (Éxito) y agregue un ACE de auditoría para el acceso que le interesa en sus joyas de la corona (por ejemplo, el atributo RBCD msDS-AllowedToActOnBehalfOfOtherIdentity, miembro del grupo privilegiado member, AdminSDHolder).

La trampa: fuerte para escrituras, débil para lecturas (validado).

Estos dos hallazgos fallan en diferentes defensas, por lo que el canario ayuda de manera desigual:

• FORCE_UPDATE es un write: un SACL write-canary en el atributo objetivo que activa de forma fiable el evento 4662 en la modificación maliciosa y la búsqueda de metadatos de replicación lo detecta igualmente. (Una auditoría SACL sobre un control de access right también detecta de forma fiable los derechos de replicación DirSync/DCSync mediante el Get-Changes 4662.)
• OBJECT_SECURITY DirSync es una lectura: La auditoría de lectura del host de AD no es confiable. En mis pruebas, un ACE de auditoría ReadProperty no generó el evento 4662 ni siquiera para una lectura ordinaria del atributo. Por lo tanto, un canario SACL no detecta de manera confiable esta lectura sigilosa. En cambio, depende de la captura de red/ETW y de la establecimiento de línea base de DirSync.

La versión directa: los audit canaries son tu mejor alarma para el lado de escritura y el abuso de derechos de replicación, pero la sigilosa lectura necesita ojos en el cable.

Herramientas

He creado dos herramientas de prueba de concepto para Red Team y Blue Team para explorar y defender los controles extendidos de LDAP: LDAP Extended Controls Toolkit.

Qué hace cada herramienta

red/ — ldapctl (ofensivo)

Tres subcomandos, cada uno operacionalizando una técnica validada de control extendido. Las banderas completas, privilegios y formatos de salida están en red/README.md.

azul/ — AdLdapDefense (defensivo)

Un módulo de PowerShell con cinco funciones exportadas que cubren cuatro capacidades de detección/endurecimiento. Los parámetros y la salida de ejemplo están en blue/README.md. Requiere PowerShell 5.1+ y RSAT (ActiveDirectory), ejecutado desde una estación de trabajo de administrador que pueda acceder al DC.

Referencias

• MS-ADTS, LDAP_SERVER_FORCE_UPDATE_OID. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3c5e87db-4728-4f29-b164-01dd7d7391ea
• MS-ADTS / MS-DRSR. Resolución de conflictos de replicación (versión → marca de tiempo → DSA GUID); DirSync (LDAP_SERVER_DIRSYNC_OID) y semántica de replicación
• DCShadow, Delpy & Le Toux, BlueHat IL 2018. https://www.dcshadow.com/
• harmj0y, Caza con metadatos de replicación de Active Directory (2017). https://blog.harmj0y.net/defense/hunting-with-active-directory-replication-metadata/
• simondotsh, Comprendiendo y abusando de DirSync (2022). https://simondotsh.com/infosec/2022/07/11/dirsync.html
• Tenable, Uso de objetos conflictivos en Active Directory para obtener privilegios (2024). https://medium.com/tenable-techblog/using-conflicting-objects-in-active-directory-to-gain-privileges-243ef6a27928