Escalada de privilegios Exchange WriteDacl dominio Active Directory: cómo una instalación de una década sigue entregando Domain Admin

Qué es la escalada de privilegios Exchange WriteDacl dominio Active Directory

Las malas configuraciones de escalada de privilegios Exchange WriteDacl dominio Active Directory se encuentran entre los valores por defecto más peligrosos que siguen intactos en entornos que instalaron Exchange Server on-premise en algún momento de la última década. Cuando Exchange Server 2013, 2016 o 2019 se configura con el modelo de permisos compartidos por defecto de Microsoft, el grupo de seguridad Exchange Windows Permissions recibe el derecho WriteDacl — el derecho a modificar la lista de control de acceso discrecional (DACL) — directamente sobre el objeto dominio en la raíz de Active Directory. Esa única entrada de control de acceso (ACE), a pocos eslabones de una cadena corta, basta para entregar a un atacante un acceso equivalente a Domain Admin en todo el bosque, no solo en la organización Exchange.

El grupo Exchange Trusted Subsystem —la identidad de servicio que cada servidor Exchange usa para actuar en AD en nombre de los usuarios finales a través del modelo RBAC (Role Based Access Control) de Exchange— está a su vez anidado por defecto dentro de Exchange Windows Permissions (Microsoft Learn, «Split permissions in Exchange Server»). Cualquiera que pueda añadir una cuenta a Exchange Trusted Subsystem, o que comprometa directamente un servidor Exchange, hereda el derecho WriteDacl sobre el objeto dominio.

Por qué esto no es «solo» el CVE-2019-1166

Esto no es un único CVE parcheable: la propia documentación de Microsoft sobre permisos compartidos lo presenta como un valor por defecto arquitectónico del modelo de permisos compartidos, no como una vulnerabilidad con una versión de corrección. Esa distinción importa, porque el texto de algunos catálogos sobre este hallazgo a veces se cruza erróneamente con el CVE-2019-1166 —un CVE real, pero que cubre un bypass no relacionado del NTLM Message Integrity Check (MIC) («Drop the MIC 2», descubierto por el Preempt Research Team y corregido por Microsoft en el Patch Tuesday de octubre de 2019, según el aviso de Praetorian). Ese parche, y su hermano de junio de 2019 CVE-2019-1040, reforzaron las defensas contra NTLM relay en general; ninguno de los dos tocó la ACE WriteDacl que Exchange deja en el objeto dominio. Las organizaciones que instalaron ambos sin adoptar nunca los permisos compartidos siguen expuestas hoy, y un controlador de dominio totalmente parcheado no dice nada sobre si esta ACE sigue ahí — consulte nuestro análisis más amplio del abuso de ACL y las rutas DCSync hacia Domain Admin para ver cómo estas concesiones de acceso se combinan con otras malas configuraciones de Active Directory.

Cómo funciona: de Exchange Windows Permissions a DCSync

La cadena de privilegios por defecto

La cadena desde una identidad Exchange con privilegios excesivos (o simplemente comprometida) hasta el compromiso total del dominio es corta:

1. Exchange Windows Permissions posee una ACE WriteDacl sobre el objeto dominio.
2. Exchange Trusted Subsystem es miembro de Exchange Windows Permissions por defecto.
3. Los miembros del grupo de roles RBAC Organization Management pueden modificar la pertenencia de otros grupos de seguridad de Exchange, incluido Exchange Trusted Subsystem (ADSecurity.org, «Mitigating Exchange Permission Paths to Domain Admins in Active Directory»; Trimarc Security).
4. Cualquiera en esa cadena —o cualquiera que comprometa directamente la cuenta de equipo de un servidor Exchange— puede usar el derecho WriteDacl para escribir una nueva ACE en el objeto dominio que conceda DS-Replication-Get-Changes y DS-Replication-Get-Changes-All, los dos derechos extendidos de los que depende DCSync.
5. A partir de ahí, una solicitud de replicación extrae todos los hashes de contraseñas del dominio, incluido el de krbtgt. Es el mismo abuso de derechos de replicación que tratamos en nuestra guía de auditoría de permisos ACL, DPAPI, tombstone y esquema — Exchange es simplemente la fuente más habitual de esta concesión, no la única.

# Enumeración de solo lectura: ¿sigue Exchange Windows Permissions (o un grupo anidado)
# manteniendo WriteDacl sobre el objeto dominio?
dsacls "DC=corp,DC=local" | Select-String "Exchange Windows Permissions|WRITE DAC"

La amplificación PrivExchange de 2019

En enero de 2019, el investigador Dirk-jan Mollema demostró que este valor por defecto ni siquiera requería un punto de apoyo previo en un grupo Exchange. La función PushSubscription de Exchange podía explotarse para forzar a la cuenta de equipo de un servidor Exchange a autenticarse, por HTTP, contra un endpoint controlado por el atacante. Como NTLM sobre HTTP no activa por defecto el flag de firma obligatoria, esa autenticación podía ser retransmitida a LDAP y combinada con el derecho WriteDacl del servidor para conceder al atacante privilegios DCSync —activable por cualquier usuario con buzón (dirkjanm.io, «Abusing Exchange: one API call away from Domain Admin»). Las actualizaciones acumulativas de Exchange de febrero de 2019 de Microsoft abordaron esto desde dos frentes: KB4490060 cambió el contrato de autenticación de las Push Notifications de Exchange Web Services para que las suscripciones ya no transmitieran credenciales que pudieran forzarse hacia una autenticación saliente, y KB4490059 documentó cómo reducir los permisos por defecto de Exchange sobre Active Directory a futuro —pero ni ese parche, ni los posteriores parches del bypass NTLM MIC, eliminan una ACE que ya se escribió en un objeto dominio años atrás.

Una variante habitual en el mundo real agrava esto aún más: las organizaciones que migraron sus buzones a Exchange Online con frecuencia mantienen un servidor Exchange on-premise únicamente para la gestión de atributos de AD, porque la guía híbrida de Microsoft históricamente ha desaconsejado eliminar por completo el último servidor on-premise. Ese servidor retenido, y los grupos de AD que hay detrás, siguen portando la misma concesión WriteDacl indefinidamente —así es exactamente como una instalación de una década termina entregando Domain Admin en un entorno donde ya nadie considera Exchange «dentro del alcance», mucho después de que los propios buzones se hayan movido a la nube.

Detección

La auditoría de Directory Service Access y Directory Service Changes no está activada por defecto en los controladores de dominio, e incluso cuando lo está, el Event ID 4662 solo se dispara para objetos que tienen una SACL coincidente. Ambas carencias deben resolverse antes de que cualquiera de los siguientes indicadores aparezca realmente en sus registros (Altered Security, «A primer on DCSync attack and detection»). Nuestra guía de monitorización de Active Directory sobre los Event ID que importan profundiza en los requisitos previos de política de auditoría para todos estos.

Detección basada en registros

Enumeración proactiva

Como la propia ACE puede tener años de antigüedad y ser silenciosa —no genera un evento nuevo por el mero hecho de existir—, la monitorización de registros debe combinarse con una enumeración proactiva periódica: dsacls o Get-Acl "AD:\<domain DN>" contra el objeto dominio, o una recolección de BloodHound comprobada específicamente en busca de un edge WriteDacl que aterrice en el nodo dominio. Trátelo igual que trataría la deriva del acceso privilegiado: una auditoría puntual solo demuestra que la ACE no estaba ahí el día que se comprobó, no que siga ausente después.

Remediación

Controles compensatorios inmediatos

1. Enumerar. Ejecute dsacls o Get-Acl contra el objeto dominio y compruebe si Exchange Windows Permissions / Exchange Trusted Subsystem tiene WriteDACL; contraste con una recolección de BloodHound para el mismo edge.
2. Reducir el radio de impacto inmediato si una migración completa a permisos compartidos aún no es viable: elimine Exchange Trusted Subsystem de Exchange Windows Permissions y exija un proceso controlado y registrado para cualquier adición futura a Organization Management, Exchange Windows Permissions o Exchange Trusted Subsystem (Trimarc Security).

La solución permanente

3. Adoptar el modelo de permisos compartidos de Microsoft. El split de RBAC es el valor por defecto recomendado por Microsoft; el split de Active Directory ofrece una separación completa entre la administración de Exchange y la de AD. Ambos requieren volver a ejecutar Setup con /PrepareAD /ActiveDirectorySplitPermissions:true, más /PrepareAllDomains (o un /PrepareDomain por dominio) en bosques multi-dominio (Microsoft Learn, «Split permissions in Exchange Server»). Esto es lo que realmente elimina las ACE de Exchange Windows Permissions del objeto dominio —no un parche de seguridad de Windows o Exchange.
4. Decomisionar correctamente. Si Exchange ya se migró fuera de las instalaciones o se retiró, confirme que la ACE del objeto dominio se eliminó como parte de ese proceso. La desprovisión de Exchange no elimina automática ni retroactivamente una concesión WriteDacl previa, que es exactamente cómo una instalación de una década sigue entregando Domain Admin mucho después de apagar el último servidor Exchange.
5. Verificar. Vuelva a ejecutar la enumeración del paso 1 tras la remediación y confirme que los derechos DS-Replication-Get-Changes(-All) sobre el objeto dominio están limitados a controladores de dominio y cuentas de replicación explícitamente autorizadas. Integre esta comprobación en un flujo de auditoría recurrente en lugar de una limpieza puntual, ya que reactivar los permisos compartidos o volver a añadir Exchange Trusted Subsystem a Exchange Windows Permissions restaura la ACE silenciosamente, sin ninguna señal de alerta evidente.

Cómo lo detecta EtcSec

La auditoría de Active Directory de EtcSec señala este patrón directamente mediante el control Exchange Privilege Escalation Risk (EXCHANGE_PRIV_ESC_PATH), que inspecciona la ACL del objeto dominio en busca de la concesión WriteDacl de Exchange Windows Permissions y rastrea el anidamiento de grupos hasta su origen. Se correlaciona con los controles más amplios ACL WriteDACL (ACL_WRITEDACL) y DS-Replication-Get-Changes Rights (DCSync) (ACL_DS_REPLICATION_GET_CHANGES), además del resumen general DCSync Capable (DCSYNC_CAPABLE), de modo que una ruta de ataque completa de Exchange a DCSync aparece como un único hallazgo priorizado en lugar de cuatro entradas ACL desconectadas, ya provenga de un servidor Exchange activo o de un resto de una década que nadie recordó decomisionar.