ACL de objetos de equipo en Active Directory: revisión de DACL

¿Qué es el abuso de las ACL de objetos de equipo en Active Directory?

Las revisiones del abuso de las ACL de objetos de equipo en Active Directory buscan determinar quién puede cambiar el objeto de directorio de una identidad de máquina. GenericAll, WriteDACL y WriteOwner pueden abrir vías hacia la delegación restringida basada en recursos (RBCD), credenciales de clave no autorizadas o un restablecimiento de la contraseña de máquina. Encontrar una concesión peligrosa demuestra una exposición; probar su explotación exige evidencias de cambios y de autenticación.

La introducción a la superficie de ataque de los objetos de equipo ya explica la vía de ACL hacia RBCD, junto con la delegación, los derechos de replicación y la pertenencia a grupos privilegiados. Esta guía lleva esa base a una revisión operativa: inspeccionar la DACL y el propietario, distinguir tres vías de abuso, recopilar evidencias de cambios en el directorio y corregir tanto la vía de permisos como cualquier configuración no autorizada.

La revisión trata los derechos sobre un objeto de equipo. Una cuenta de máquina que posee privilegios en otros lugares constituye una relación distinta. Registre el DN y el GUID del objeto controlado, el principal que recibe la concesión, su alcance y la finalidad administrativa prevista antes de decidir qué eliminar.

Cómo funciona: revisar la DACL y el propietario

Una lista de control de acceso discrecional (DACL) contiene entradas de control de acceso (ACE). Cada entrada identifica un principal y unos derechos; las entradas específicas de objeto pueden limitar la propiedad, el derecho extendido o la clase de objeto que hereda. Leer únicamente el nombre de un permiso mostrado en pantalla pasa por alto ese alcance. La enumeración de derechos de acceso AD de Microsoft define estos campos y los derechos WriteDACL y WriteOwner.

GenericAll no es simplemente un bit sin procesar que se deba buscar. El mapeo de derechos de acceso MS-ADTS convierte los derechos genéricos en derechos específicos al almacenar un descriptor de seguridad. Una auditoría que solo busque 0x10000000 puede pasar por alto el control total resultante del mapeo. Interprete los derechos resultantes junto con el tipo de ACE, el alcance de las propiedades y la herencia.

La propiedad necesita su propia comprobación. Microsoft documenta el bloqueo de los derechos implícitos del propietario en objetos de equipo, con condiciones relativas al sistema operativo y a BlockOwnerImplicitRights. No suponga que convertirse en propietario siempre proporciona una vía de escritura sin restricciones sobre la DACL. Verifique los derechos efectivos en la configuración real del DC. Del mismo modo, eliminar una ACE evidente de control total no demuestra que la situación esté saneada si persiste un propietario inesperado u otra concesión aplicable.

Por qué los objetos de equipo necesitan una revisión específica de ACL

Un inventario de delegación responde qué máquinas aceptan actualmente identidades delegadas. Una revisión de ACL pregunta quién podría cambiar esa respuesta mañana. Por tanto, un atributo RBCD vacío no cierra un hallazgo sobre un principal que puede escribir en él. La misma distinción se aplica a las credenciales de clave: inventaríe los valores almacenados y la capacidad de añadirlos.

Empiece por el contexto de negocio en lugar de prohibir toda administración. Un servicio de despliegue puede necesitar derechos concretos de aprovisionamiento; eso no demuestra la necesidad de un control total permanente sobre cada objeto de servidor. Pida al responsable que identifique la operación, los objetos afectados, el principal aprobado y la fecha de caducidad o revisión. Compare ese requisito con la ACE real.

Los permisos directos y heredados requieren correcciones distintas. Si una concesión no deseada se origina en una OU superior, cambiar un equipo deja expuestos a los demás destinatarios. Localice el origen de la herencia e inspeccione el alcance por clase de objeto antes de modificarlo. Involucre a los responsables administrativos de la OU y sus cargas de trabajo para que la delegación de sustitución permita la tarea legítima.

La cadena de ataque: tres vías desde el control del objeto

1. Configuración RBCD

Un atacante con acceso efectivo de escritura a msDS-AllowedToActOnBehalfOfOtherIdentity puede intentar insertar una identidad de servicio que controla en la configuración de delegación del recurso. WriteDACL puede ser una fase anterior que concede el permiso de escritura necesario. La referencia de esquema de Microsoft describe este atributo como la comprobación de acceso para actuar en nombre de otras identidades en servicios que se ejecutan con la cuenta.

La descripción general de la delegación restringida de Microsoft explica la autorización del lado del recurso y el intercambio de tickets de servicio S4U2Proxy. La consecuencia es el acceso mediante servicios elegibles en el recurso de destino, sujeto al entorno y a la autorización del servicio. No garantiza automáticamente privilegios de administrador local o Domain Admin. Revise los servicios de destino y los privilegios de la identidad suplantada para evaluar el impacto.

2. Credenciales fantasma

Una clave pública no autorizada en msDS-KeyCredentialLink puede crear una vía independiente de autenticación basada en claves cuando el entorno admite el flujo de confianza de claves pertinente y el atacante posee su clave privada. MS-PKCA Key Trust exige que las implementaciones respaldadas por AD confirmen la misma clave pública en el atributo de la cuenta.

Distinga el acceso amplio de escritura de atributos de las escrituras validadas. Estas últimas imponen comprobaciones adicionales más allá del esquema del atributo. La especificación de escrituras validadas para equipos exige SELF, el derecho de escritura validada pertinente y restricciones específicas del blob para añadir un valor, incluida la ausencia de un valor existente. Estas condiciones no significan que cualquier tercero con una escritura validada pueda instalar una clave.

La autenticación por clave pública de dispositivos unidos al dominio también explica el aprovisionamiento legítimo de claves de equipo. Un atributo con valores es una entrada para el triaje, no un veredicto de compromiso. La guía de credenciales fantasma desarrolla esta distinción y explica por qué una limpieza limitada a la contraseña puede dejar intacta una vía de clave no autorizada.

3. Restablecimiento de la contraseña de máquina

El control total puede incluir el derecho extendido Reset Password. La entrada de esquema Reset Password de Microsoft enumera explícitamente Computer entre las clases aplicables. Un restablecimiento no autorizado puede dar a un atacante control de la credencial basada en contraseña de la cuenta, con un impacto que depende de los privilegios de esa cuenta y de las vías de autenticación disponibles.

También puede interrumpir la relación de confianza de la máquina. La guía de Microsoft para solucionar problemas del canal seguro describe discrepancias de contraseña entre el dispositivo y AD. Trate un restablecimiento inexplicado como un incidente de identidad y un problema de disponibilidad. Coordine la recuperación con el responsable del sistema; un cambio unilateral de contraseña en el directorio no es una prueba de diagnóstico segura.

Enumeración: un comando de lectura y después revisión de derechos efectivos

En un sistema Windows de administración con dsacls disponible, abra un símbolo del sistema elevado o una sesión de PowerShell y sustituya el DN del equipo verificado en este único comando de lectura:

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /A

La referencia de dsacls de Microsoft documenta la visualización de ACL y /A para la información de propietario y auditoría. Utilice una cuenta autorizada para leer la DACL, el propietario y la información de auditoría; el acceso ordinario READ_CONTROL excluye la SACL. Este ejemplo no se ejecutó en un entorno AD.

Resuelva cada principal inesperado a una identidad actual. Registre las concesiones heredadas frente a las explícitas, los grupos aplicables, el alcance de propiedades y el propietario. Confirme los permisos efectivos mediante las herramientas de seguridad del directorio en lugar de tratar cada entrada de permiso como un ataque independiente e inmediatamente utilizable. Investigue las identidades no resueltas y explique las excepciones administrativas aprobadas en el registro de revisión.

Priorice los servidores sensibles y las OU que delegan el control sobre ellos; después amplíe la revisión a todos los objetos de equipo. Guarde el estado anterior para evaluar un cambio posterior sobre el mismo objeto y alcance de permisos.

Detección: Event ID 5136 y KQL

La referencia del Event ID 5136 de Microsoft confirma la auditoría de modificaciones de objetos de directorio. Habilite la auditoría de éxitos de Audit Directory Service Changes en los DC y las entradas SACL apropiadas de auditoría de escritura en los objetos o atributos supervisados. Microsoft señala que los ajustes del esquema pueden suprimir la auditoría de algunos objetos y propiedades, por lo que debe validar la cobertura real. Conserve los campos de correlación del actor, objeto, atributo y operación. La eliminación y la adición de valores pueden formar parte de una sola modificación; no las cuente como incidentes separados.

El siguiente KQL es una consulta inicial no ejecutada para un área de trabajo que recibe eventos Security de los DC en WindowsEvent. Presupone propiedades con nombre dentro de EventData. El esquema de la tabla WindowsEvent de Microsoft define ese campo como dinámico e indica que los fallos de análisis rellenan RawEventData en su lugar. Inspeccione registros representativos antes de confiar en este mapeo.

WindowsEvent
| where TimeGenerated > ago(7d)
| where Channel == "Security" and EventID == 5136
| extend ObjectClass = tostring(EventData.ObjectClass),
         ObjectDN = tostring(EventData.ObjectDN),
         AttributeName = tostring(EventData.AttributeLDAPDisplayName),
         ActorSID = tostring(EventData.SubjectUserSid),
         ActorName = tostring(EventData.SubjectUserName),
         Operation = tostring(EventData.OperationType),
         OperationCorrelation = tostring(EventData.OpCorrelationID)
| where ObjectClass =~ "computer"
| where AttributeName in~ ("msDS-AllowedToActOnBehalfOfOtherIdentity",
                          "msDS-KeyCredentialLink", "nTSecurityDescriptor")
| project TimeGenerated, Computer, ObjectDN, AttributeName,
          ActorSID, ActorName, Operation, OperationCorrelation
| order by TimeGenerated desc

Compruebe por separado los registros 5136 con EventData vacío o con una estructura distinta; de lo contrario, las lagunas de análisis quedan invisibles. Adapte la consulta si el conector utiliza SecurityEvent u otra tabla. Valide la cobertura SACL y la visibilidad de los cambios del descriptor de seguridad mediante un cambio administrativo controlado antes de afirmar que existe cobertura. La consulta encuentra modificaciones candidatas, no pruebas de abuso.

Para la vía de restablecimiento, complemente la revisión de cambios del directorio con el Event ID 4742, bajo Audit Computer Account Management. Su campo Password Last Set puede reflejar un restablecimiento manual o una rotación ordinaria de la contraseña de máquina. Microsoft también documenta cambios de DACL que generan campos vacíos de atributos modificados. Por tanto, una lista de campos vacía no demuestra que no haya cambiado nada relevante.

Realice el triaje comparando con los cambios aprobados de despliegue, inscripción y delegación. Conserve la configuración anterior cuando esté disponible, identifique la cuenta iniciadora y compruebe la actividad posterior de la máquina afectada. Aumente la prioridad cuando un actor no aprobado modifique un servidor sensible, un propietario cambie de forma inesperada o un cambio de permisos preceda a una adición de delegación o clave. La ausencia de datos de auditoría requiere investigar la recopilación; no permite establecer la ausencia de explotación.

Corrección (Remediation): eliminar la vía de permisos y recuperar la identidad

Paso 1: conservar las evidencias y limitar la delegación

Capture la DACL, el propietario, el origen de la herencia y los valores de atributos relevantes antes de cambiarlos. Elimine las concesiones no autorizadas de control total, escritura de DACL y toma de posesión. Sustituya el acceso de aprovisionamiento necesario por derechos limitados a la operación y clase de objeto documentadas. Corrija una concesión heredada en su origen y revise los demás equipos afectados.

Si se confirma que un principal concreto no necesita ninguna ACE restante en este objeto, dsacls /R ofrece una operación de eliminación documentada:

dsacls "CN=APP01,OU=Servers,DC=example,DC=com" /R "EXAMPLE\RetiredProvisioning"

/R elimina todas las ACE de ese principal; no es una limpieza selectiva del control total. Para un principal que conserve derechos legítimos, edite la ACE concreta problemática. Confirme después el propietario y los derechos efectivos resultantes. Este ejemplo basado en la documentación no se ejecutó.

Paso 2: eliminar la delegación y las claves no autorizadas

Concilie los delegados RBCD con la lista aprobada del responsable del recurso. Set-ADComputer expone PrincipalsAllowedToDelegateToAccount; utilice el conjunto previsto y verificado, preservando las dependencias legítimas de las aplicaciones. Eliminar un delegado no autorizado sin corregir el permiso de quien escribe deja abierta la posibilidad de recrear la configuración.

Para una clave confirmada como no autorizada, el mismo cmdlet permite eliminar un valor exacto de atributo LDAP:

Set-ADComputer -Identity "APP01" -Remove @{ 'msDS-KeyCredentialLink' = $ConfirmedUnauthorizedValue }

$ConfirmedUnauthorizedValue debe contener el valor exacto conservado y revisado. Es un ejemplo de sintaxis basado en la documentación, no una recuperación ejecutada. Preserve las claves de dispositivo aprobadas, documente cómo se validó cada valor restante y pruebe la autenticación legítima después de la limpieza.

Paso 3: restaurar la confianza y verificar el cierre

Si las credenciales de máquina se vieron comprometidas, coordine su recuperación con el responsable del dispositivo e investigue los accesos posteriores. En un miembro del dominio, el cmdlet de canal seguro de Microsoft ofrece este comando de verificación:

Test-ComputerSecureChannel -Verbose

Ejecútelo localmente en PowerShell abierto con Ejecutar como administrador en el miembro del dominio afectado. Este comando de verificación basado en la documentación no se ejecutó. Microsoft advierte que produce errores falsos positivos en controladores de dominio; siga allí los procedimientos específicos de los DC. Un canal seguro operativo verifica esa relación, no la eliminación de todos los valores de directorio controlados por un atacante.

Cierre el hallazgo solo después de revisar los permisos y el propietario resultantes, conciliar la delegación y las claves, comprobar el funcionamiento previsto del servicio y confirmar que la supervisión recibe los cambios esperados. Asigne un responsable y una fecha de revisión a cada excepción conservada.

Cómo detecta EtcSec este problema

La implementación de etc-collector ofrece dos vistas del catálogo para esta revisión de permisos de objetos de equipo:

• COMPUTER_ACL_GENERICALL inspecciona las ACE de concesión en objetos de equipo en busca de GenericAll sin procesar o control total AD resultante del mapeo, excluyendo los principales administrativos integrados. Asocia los DN de los equipos cuando el inventario está disponible y utiliza una heurística de ubicación menos precisa cuando no lo está.
• COMPUTER_ACL_ABUSE informa de los equipos que llevan el indicador DangerousACL. El motor de auditoría deriva ese indicador de las concesiones permitidas GenericAll, WriteDACL o WriteOwner sobre objetos de equipo, excluyendo la propia cuenta y los principales privilegiados esperados.

Trátelas como un único control editorial con solapamiento: una vista específica del control total y una vista agregada de derechos peligrosos. Sus filtros de principales difieren, por lo que no debe prometer conjuntos de hallazgos idénticos ni sumar sus recuentos en un total de exposiciones independientes. Ambas informan de una exposición de configuración; ninguna demuestra que se haya abusado con éxito de RBCD, de una clave maliciosa o de un restablecimiento de contraseña. Utilice sus objetos afectados para iniciar la revisión de DACL y correlacionar con evidencias de cambios.