Aprobar cambios de atributos AD: emparejar valores 5136

¿Qué implica aprobar cambios de atributos AD?

Una revisión para aprobar cambios de atributos AD vincula una modificación registrada de un objeto existente del directorio con una decisión autorizada de forma independiente. Su resultado es un registro de pruebas: el GUID del objeto, el atributo modificado, los valores eliminados y añadidos observados, el identificador de correlación de la operación, la cuenta solicitante, el controlador de dominio emisor, la hora del evento y las pruebas de aprobación. Un nombre de administrador conocido o un número bajo de hallazgos de postura no puede sustituir ese registro.

Utilice este procedimiento cuando una modificación del directorio necesite una explicación antes de cerrar la revisión o aprobar un cambio correctivo. Empiece con un objeto y un atributo. Conserve los eventos originales, establezca los límites de recopilación y pida al responsable autorizado de la decisión que confirme si el cambio de valor observado coincide con la solicitud. La revisión puede concluir con una aprobación respaldada por pruebas, un cambio no autorizado confirmado o una carencia de pruebas no resuelta; esos resultados requieren seguimientos diferentes.

Este artículo trata los cambios en un objeto existente. Para objetos recién aprovisionados, utilice el registro de creación que conecta whenCreated y las pruebas de creación con el aprovisionamiento aprobado. Para una comparación más amplia entre el acceso previsto y los derechos efectivos de grupo, ACL y replicación, utilice el flujo de revisión y revalidación de la deriva de acceso privilegiado. Aquí, el entregable es el registro de pruebas del cambio de atributo, en lugar de otro inventario de cuentas privilegiadas.

Cómo funciona: establecer qué puede mostrar 5136

Microsoft documenta el evento 5136 para las modificaciones de objetos del servicio de directorio. Para que se genere el evento, debe aplicarse la auditoría de éxitos de Directory Service Changes y el objeto necesita una entrada SACL coincidente que audite la escritura del atributo pertinente. La subcategoría de auditoría opera en los controladores de dominio. Algunos cambios de objetos o propiedades no se auditan debido a la configuración del esquema, por lo que habilitar la directiva por sí solo no establece una cobertura completa. Microsoft Learn: evento 5136, Audit Directory Service Changes.

Para una sustitución, Microsoft describe un evento típico de valor eliminado seguido de un evento de valor añadido. Trate ese patrón como una ayuda para la reconstrucción. No garantiza que cada revisión tenga exactamente dos registros. Un atributo puede tener varios valores, una operación puede afectar a varios atributos y los registros retenidos pueden estar incompletos. Conserve todos los eventos de valor pertinentes y explique cómo contribuyen al cambio revisado.

El campo XML OperationType distingue una adición, %%14674, de una eliminación, %%14675. AttributeValue contiene el valor implicado en ese evento. Conserve tanto el código de operación sin procesar como su significado. No interprete un valor añadido como el conjunto completo del atributo tras el cambio cuando puede representar un miembro de un atributo multivalor. Microsoft Learn: descripción de los campos del evento 5136.

OpCorrelationID relaciona las modificaciones pertenecientes a una operación LDAP. Puede abarcar más que el único atributo que se revisa. Combínelo con la identidad del objeto y del atributo, la procedencia y la hora; no es una referencia de ticket de negocio. Microsoft describe AppCorrelationID como no utilizado, con un guion como valor. Ninguno de los dos campos proporciona la decisión de aprobación de la organización.

Detección: recopilar un conjunto de pruebas delimitado

Los comandos siguientes utilizan sintaxis documentada de comandos y parámetros adaptada a esta revisión. No se han ejecutado contra un dominio real. Realice las lecturas de eventos desde un equipo Windows autorizado; utilice el módulo Active Directory para leer el objeto. Sustituya el DC, el intervalo UTC y el GUID del objeto de ejemplo por los datos reales del caso. Registre los errores de permisos y los registros no disponibles como observaciones fallidas, en lugar de búsquedas vacías satisfactorias. Las lecturas remotas de Get-WinEvent requieren acceso a través del firewall al servicio Windows Event Log; la cmdlet no depende de PowerShell remoting. Microsoft Learn: Get-WinEvent ComputerName.

Paso 1: registrar la cobertura de auditoría y retención

En cada DC pertinente para el caso, examine la subcategoría actual de auditoría del sistema. El nombre inglés siguiente requiere una instalación que reconozca ese nombre; la sintaxis documentada también acepta un GUID de subcategoría.

auditpol /get /subcategory:"Directory Service Changes" /r

La salida esperada es un informe de directiva que identifica la subcategoría y su configuración de éxito y error. Guarde la identidad del DC, la hora de recopilación, el comando y el informe devuelto. Una consulta satisfactoria establece lo que se leyó en ese momento. No demuestra que se aplicara la misma configuración cuando ocurrió la modificación histórica. La sintaxis del comando y los requisitos de permisos de lectura se documentan en Microsoft Learn: auditpol get.

Para la configuración del registro, examine el registro Security en el mismo DC:

Get-WinEvent -ListLog Security -ComputerName 'dc01.contoso.local' -ErrorAction Stop

El resultado describe el registro, incluidos su modo, tamaño máximo configurado y número de registros. Un tamaño o un recuento no demuestra que el intervalo objetivo siga siendo consultable. Compruebe los registros locales retenidos y los archivos centrales para ese intervalo, y documente la cobertura de las fuentes, las carencias de reenvío y las pruebas históricas disponibles de directiva y SACL. Microsoft Learn: Get-WinEvent.

Responda explícitamente a la primera pregunta de decisión: ¿qué SACL de escritura de atributos y qué pruebas de retención respaldan esta reconstrucción? Registre el objeto auditado o el ámbito heredado, la acción de escritura pertinente, la entidad de seguridad cubierta y la configuración de éxito. Si solo está disponible la configuración actual, marque la cobertura histórica como no demostrada. No deduzca que la ausencia de un evento histórico significa que el atributo nunca se modificó.

Paso 2: recuperar los eventos sin un límite arbitrario de pareja

Utilice un intervalo delimitado que incluya el cambio revisado. El ejemplo siguiente selecciona eventos Security por proveedor, identificador y hora:

$reviewStart = [DateTimeOffset]::Parse('2026-10-04T08:00:00Z').UtcDateTime
$reviewEnd = [DateTimeOffset]::Parse('2026-10-04T09:00:00Z').UtcDateTime
$events = Get-WinEvent -ComputerName 'dc01.contoso.local' -FilterHashtable @{
    LogName = 'Security'
    ProviderName = 'Microsoft-Windows-Security-Auditing'
    Id = 5136
    StartTime = $reviewStart
    EndTime = $reviewEnd
} -ErrorAction Stop

Estas horas son ilustrativas, no una ventana de cambio medida ni una duración de revisión prescrita. Get-WinEvent documenta estas claves de filtro y devuelve registros de eventos, por defecto con los más recientes primero. El ejemplo evita intencionadamente solicitar solo dos eventos o limitar el resultado con -MaxEvents. Conserve la consulta y su resultado antes de seleccionar el objeto y el atributo del XML del evento. Microsoft Learn: parámetros de filtro de Get-WinEvent.

Espere cero o más registros coincidentes, no un número predeterminado. Si el comando informa de que no hay eventos coincidentes, distinga ese resultado de los errores de acceso o conexión y después evalúe la cobertura de retención y generación. Busque en archivos autorizados según sea necesario; la cmdlet también documenta -Path para archivos de eventos guardados. Una lectura fallida debe permanecer visible en el registro del caso.

Conserve la exportación original de eventos y el XML de cada evento. Una captura de pantalla del valor más reciente no basta para reconstruir el cambio. En un SIEM, verifique que la ingesta preserve los campos siguientes y mantenga la identidad del evento de origen separada de la hora de ingesta y de las posibles copias duplicadas reenviadas.

Paso 3: reunir el registro del cambio de atributo

Utilice ObjectGUID para identificar el objeto y AttributeLDAPDisplayName para identificar el atributo. Registre el DN y la clase como contexto. Después recopile todos los eventos de valor candidatos que compartan el identificador de correlación de operación para ese objeto y atributo, comprobando el DC emisor, el sujeto y las horas. Si esos campos discrepan, mantenga la discrepancia para investigarla en lugar de forzar los registros a formar una sola pareja.

Estos nombres de campos de evento proceden del XML de 5136 y de las descripciones de sus campos. Los campos de aprobación son una propuesta de registro de revisión, no telemetría adicional de Windows.

Para una sustitución de un único valor con pruebas completas, el revisor debería poder describir la eliminación y la adición observadas y referenciar cada registro de origen. Para un atributo multivalor, conserve las eliminaciones y adiciones individuales como conjuntos de operaciones observadas. No invente valores que no cambiaron ni afirme que el conjunto de eventos constituye una instantánea completa del antes y el después.

Para comparar con el estado actual del directorio, Get-ADObject acepta un GUID de objeto como -Identity, atributos adicionales como -Properties y un servidor concreto como -Server. Este ejemplo utiliza el GUID del evento 5136 de muestra de Microsoft; sustitúyalo, junto con el atributo de muestra, por los identificadores revisados.

Get-ADObject -Identity '4fe80a66-5f93-4f73-b215-68678058e613' -Server 'dc01.contoso.local' -Properties userAccountControl -ErrorAction Stop

Espere el objeto localizado y la propiedad solicitada, o un error explícito de lectura o búsqueda. Conserve la hora de recopilación y el DC. El estado actual puede ayudar a validar la remediación, pero no puede recuperar un valor histórico o una aprobación ausentes. Microsoft Learn: Get-ADObject.

Verificación: hacer independiente la decisión de aprobación

Pida a la autoridad de cambio designada que haga corresponder la solicitud con este objeto, atributo y cambio de valor previsto. Registre quién está autorizado a decidir, las pruebas de aprobación y su hora, y si esas pruebas cubren la operación observada. Un operador que explica un cambio aporta pruebas útiles, pero una explicación no constituye automáticamente una aprobación independiente.

Mantenga al actor técnico y al responsable de la decisión en campos separados. Si una cuenta de automatización solicitó el cambio, registre ese sujeto sin adivinar el iniciador humano. Establezca cualquier atribución al operador mediante registros independientes. Del mismo modo, no vincule una solicitud de negocio con un evento solo porque las marcas de tiempo estén próximas o ambas descripciones mencionen «mantenimiento del directorio».

Clasifique explícitamente los casos difíciles:

Esta tabla propone resultados de revisión. No afirma que todo evento sin correspondencia sea malicioso. Responda a las preguntas de decisión restantes antes del cierre: ¿quién confirma la autorización independientemente del actor técnico y cómo se calificarán las pruebas ausentes, multivalor o solo de eliminación? Asigne a cada elemento no resuelto un responsable y la siguiente solicitud de pruebas.

Remediación: resolver la decisión y validar la cobertura (Remediation)

Conserve las pruebas históricas antes de realizar un cambio correctivo en el directorio. Para una modificación aprobada respaldada por pruebas, adjunte la decisión al registro de revisión. Para una discrepancia de aprobación o un cambio no autorizado confirmado, pida a los responsables de identidad y servicios pertinentes que evalúen la exposición y las dependencias, decidan sobre la contención o corrección y registren el estado objetivo autorizado. Evite restaurar a ciegas un valor eliminado: cambios legítimos posteriores o dependencias multivalor pueden hacer que esa acción sea incorrecta.

Si la cobertura de generación es insuficiente, los administradores autorizados deben corregir la directiva de auditoría aplicable y la SACL de escritura de atributos. Microsoft documenta la auditoría de éxitos para Directory Service Changes y la ausencia de eventos Failure en esta subcategoría. Ejecute el comando siguiente localmente en el DC seleccionado. Utiliza la sintaxis documentada auditpol /set para habilitar la auditoría de éxitos, cambia la configuración y debe formar parte de un procedimiento administrativo aprobado.

auditpol /set /subcategory:"Directory Service Changes" /success:enable

Tras un resultado satisfactorio del comando, se realiza la lectura auditpol /get anterior y se verifica por separado la SACL coincidente. El comando no configura una SACL, no demuestra la persistencia de una directiva gestionada centralmente ni recrea eventos pasados. Coordínelo con el responsable de la directiva y conserve las pruebas de configuración resultantes. Microsoft Learn: auditpol set, Audit Directory Service Changes.

Valide la cobertura futura mediante una modificación piloto aprobada en un objeto de prueba fuera de producción y un atributo adecuado. Registre la intención autorizada de valores antiguos y nuevos antes de la prueba. Compruebe que los eventos generados y retenidos contienen el objeto, el atributo y las operaciones de valor esperados, que el reenvío conserva su identidad y que la revisión puede vincularlos a la aprobación de la prueba. No se realizó ninguna prueba de dominio de ese tipo para este artículo.

Después de una corrección autorizada, repita la lectura del objeto dentro del ámbito y la revisión de eventos. Conserve el estado actual, las pruebas de la operación correctiva y la decisión independiente. Cierre solo las partes del caso respaldadas por pruebas; traslade las carencias de reconstrucción histórica con una resolución documentada.

Cómo detecta EtcSec este problema

En el commit del recopilador bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, CHANGE_MANAGEMENT_BYPASS es una heurística de postura de gravedad Medium. Su Detect() lee los usuarios LDAP recopilados. Cuenta los usuarios habilitados cuyas entradas directas memberOf contienen los nombres ingleses Domain Admins o Enterprise Admins, mediante coincidencia de subcadenas sin distinguir mayúsculas y minúsculas. Más de 10 usuarios de este tipo crea un problema. Un recuento separado incluye usuarios con al menos un SPN y adminCount=1; más de 5 crea otro problema. El segundo recuento no excluye a los usuarios deshabilitados.

Si se cumple cualquiera de las condiciones, el hallazgo devuelto tiene Count=1; de lo contrario, tiene Count=0. Uno es el indicador del hallazgo, no el número de cambios no aprobados. Los detalles incluyen los dos contadores agregados. Los umbrales son heurísticas del producto sin autoridad normativa, no requisitos de aprobación de Microsoft, ANSSI o HDS.

El proveedor LDAP suministra memberOf, servicePrincipalName y adminCount. Este detector no expande la pertenencia a grupos anidados. Los nombres de grupos privilegiados renombrados o localizados pueden impedir la coincidencia con el nombre inglés; la coincidencia de subcadenas no es una prueba estable del SID de grupo. Microsoft documenta que adminCount puede permanecer en 1 después de que una cuenta abandone un grupo protegido; por tanto, este indicador no establece el privilegio efectivo actual. Un SPN puede registrarse en una cuenta de usuario o de equipo, por lo que su mera presencia no establece el propósito operativo actual de la cuenta. Microsoft Learn: cuentas protegidas y adminCount, registro de SPN. El ámbito y los límites de recopilación también restringen las poblaciones examinadas.

Esta comprobación no lee eventos 5136, valores eliminados o añadidos, identificadores de correlación, SACL, registros de retención ni flujos de aprobación. Un hallazgo positivo puede impulsar una revisión de gestión de cambios, pero no puede demostrar un bypass, identificar esta modificación de atributo ni decidir la autorización. Un recuento de cero no puede dar por validado el registro de pruebas. Complete la reconstrucción de eventos y la decisión independiente anteriores antes de cerrar la revisión.