Revisar equipo AD whenChanged: procedencia de deshabilitación

¿Qué es una revisión whenChanged de un equipo AD deshabilitado?

Una revisión whenChanged de un equipo AD deshabilitado parte de una cuenta de equipo actualmente deshabilitada y una marca de tiempo antigua de modificación del directorio. Pregunta si la cuenta debe permanecer en Active Directory, quién es responsable de esa decisión y qué pruebas respaldan su retirada. La marca de tiempo ayuda a priorizar la investigación; no establece cuándo se deshabilitó la cuenta.

Esta distinción importa cuando una lista de limpieza se convierte en una cola de eliminación. Una cuenta deshabilitada puede pertenecer a una estación de trabajo retirada, una máquina aislada temporalmente, una identidad de servicio o una infraestructura pendiente de un procedimiento de retirada de servicio independiente. Un hallazgo de auditoría no aporta ninguna de esas decisiones de negocio. Mantenga como pruebas separadas el estado actual de la cuenta, la procedencia de su deshabilitación y la aprobación de su retirada.

La revisión descrita aquí sigue el hallazgo COMPUTER_DISABLED_NOT_DELETED de etc-collector. No introduce un calendario universal de eliminación ni establece un ataque a partir de una marca de tiempo antigua. El resultado es una decisión documentada para un objeto identificado: conservarlo con un motivo del que alguien se responsabilice, investigar las pruebas que faltan o retirarlo mediante un procedimiento aprobado tras resolver sus dependencias.

Funcionamiento: la última modificación no acredita la procedencia de la deshabilitación

La referencia del atributo whenChanged de Microsoft define el valor como la fecha del último cambio del objeto. El sistema lo actualiza cada vez que el objeto cambia. El valor no se replica, por lo que debe registrar qué controlador de dominio proporcionó la observación y cuándo lo leyó.

Establecer el estado deshabilitado cambia el objeto, pero el valor actual de whenChanged no identifica esa operación. Una modificación posterior puede sustituir la marca de tiempo anterior aunque la cuenta siga deshabilitada. Por tanto, leer un valor reciente no establece una deshabilitación reciente; leer un valor antiguo no aporta su autor, motivo ni aprobación. Trate el atributo como una observación de modificación del DC elegido, en lugar de un campo dedicado a la fecha de deshabilitación.

Mantenga estas distinciones en el registro de revisión:

Nuestra guía de higiene de objetos de equipo de Active Directory ofrece el contexto más amplio del ciclo de vida, incluidos controladores de dominio, LAPS y objetos de equipo obsoletos. Sus frecuencias ilustrativas de limpieza no prueban una fecha de deshabilitación ni se adoptan como umbrales para esta revisión. Una observación del último inicio de sesión o de la contraseña de máquina respondería a otra pregunta; ninguna sustituye aquí las pruebas de deshabilitación de la cuenta.

Detección: establecer el estado actual e investigar la transición

Paso 1: leer el objeto exacto desde un DC especificado

Utilice el módulo ActiveDirectory en una estación de administración autorizada. La referencia de Get-ADComputer de Microsoft documenta -Identity, -Properties y -Server. Solicite explícitamente los atributos LDAP y especifique un servidor de directorio en lugar de depender de una selección implícita:

$computer = Get-ADComputer -Identity 'PC01' -Server 'dc01.contoso.com' -Properties whenChanged,userAccountControl,objectClass -ErrorAction Stop
$computer | Select-Object DistinguishedName,ObjectGUID,SID,Enabled,whenChanged,userAccountControl,objectClass

La proyección utiliza la sintaxis documentada de Select-Object de Microsoft. Conserve la identidad del equipo, el DC elegido, la hora de lectura y el resultado de la recopilación junto a los campos mostrados. Una consulta fallida constituye una prueba incompleta. Un atributo no disponible no es un resultado negativo fiable solo porque el proceso de recopilación haya devuelto un objeto.

El analizador LDAP revisado obtiene Disabled del bit ACCOUNTDISABLE, 0x0002, de userAccountControl en el directorio. La propiedad Enabled mostrada y el atributo sin procesar proporcionan observaciones del estado actual que deben conciliarse. No registran cuánto tiempo lleva deshabilitada la cuenta. Si la lectura actual contradice la auditoría, investigue la hora de recopilación, la identidad de destino y las observaciones de los DC antes de actuar sobre el hallazgo anterior.

Paso 2: utilizar el evento 4742 solo cuando sus pruebas sean aplicables

Microsoft documenta el evento 4742, cambio de una cuenta de equipo, en la subcategoría Audit Computer Account Management. Se genera en los controladores de dominio. Revise los registros Security de los DC pertinentes o sus copias recopiladas, con una configuración de auditoría y retención suficientes para cubrir la transición sospechada.

En un SIEM, limite la investigación al evento 4742 y al TargetSid de la cuenta modificada. Examine el evento sin procesar, no solo un resumen normalizado. Conserve la hora del evento, el DC emisor, el identificador del registro, la identidad de destino, la identidad del sujeto, OldUacValue, NewUacValue y la información modificada de control de cuenta. Compare cualquier transición de deshabilitación alegada con el registro aprobado de cambio o incidente y con la lectura actual del directorio. La mera coincidencia del nombre de cuenta aporta un contexto menos sólido que el SID de destino verificado.

La documentación indica explícitamente que algunos cambios no generan el evento 4742. Otros eventos pueden contener guiones en todos los atributos modificados mostrados, dejando sin identificar el atributo cambiado. Por tanto, una entrada 4742 para el objeto no prueba automáticamente su deshabilitación. Podría documentar otro cambio de cuenta, y una búsqueda en los registros podría no cubrir el DC o el período pertinentes.

Los campos UAC antiguo y nuevo de 4742 utilizan la implementación SAM de los indicadores de cuenta, cuyas definiciones difieren de las de userAccountControl LDAP. No aplique la máscara LDAP 0x0002 a esos campos del evento para afirmar una transición de deshabilitación. Interprete la transición registrada usando las definiciones de indicadores de cuenta documentadas para el evento y conserve los valores sin procesar para su revisión.

Paso 3: correlacionar las pruebas con la responsabilidad

Pregunte al responsable si la máquina sigue siendo necesaria, está aislada temporalmente, se ha sustituido o se ha retirado formalmente del servicio. Vincule la respuesta a la identidad exacta del directorio. Conserve por separado el motivo de deshabilitación, las pruebas disponibles de la transición y la decisión de retirada. Cuando falten pruebas históricas, describa esa carencia directamente en lugar de construir una fecha a partir de la última modificación del objeto.

Un cambio sin explicación que afecte a una identidad crítica requiere investigación antes de la limpieza del ciclo de vida. Por el contrario, una decisión de conservación aprobada puede ser legítima aunque el detector siga señalando el objeto. Registre quién volverá a revisar esa decisión y qué condición justificaría la retirada. Eliminar el hallazgo no constituye en sí mismo una necesidad de negocio de borrar la cuenta.

Remediación: validar las dependencias antes de una eliminación aprobada (Remediation)

Paso 1: clasificar el objeto y resolver las incógnitas

Confirme la clase del objeto y su función operativa antes de elegir un procedimiento de retirada. El detector no excluye explícitamente controladores de dominio ni cuentas de servicio administradas de grupo. Un controlador de dominio necesita su procedimiento adecuado de retirada de servicio; una identidad de servicio necesita que se comprueben sus dependencias de servicio. Un ejemplo genérico de eliminación de una estación de trabajo no autoriza a aplicar la misma acción a todos los objetos devueltos por el recopilador.

Concilie el estado actual de la cuenta, la respuesta del responsable y los registros de retirada de servicio. Mantenga en espera los casos sin resolver, con una siguiente acción asignada a un responsable. Este proceso no establece un nuevo plazo genérico de antigüedad: el tiempo transcurrido no puede acreditar que hayan terminado las necesidades de servicios, registros o recuperación.

Paso 2: inventariar los hijos y las dependencias de recuperación

Lea los hijos inmediatos del objeto de equipo verificado mediante los parámetros de búsqueda documentados de Get-ADObject de Microsoft. Este ejemplo utiliza el $computer devuelto anteriormente y solicita identificadores y clases de objeto, en lugar de secretos de recuperación:

Get-ADObject -LDAPFilter '(objectClass=*)' -SearchBase $computer.DistinguishedName -SearchScope OneLevel -Server 'dc01.contoso.com' -ErrorAction Stop |
    Select-Object DistinguishedName,ObjectGUID,ObjectClass

OneLevel busca solo hijos inmediatos. Si un hijo tiene sus propios descendientes o el inventario está incompleto, investigue esa estructura y su propósito antes de continuar. Un resultado vacío con visibilidad sin verificar no prueba que no existan objetos dependientes. Registre los fallos de acceso y la incertidumbre sobre el alcance como puntos del inventario sin resolver.

Incluya la información de recuperación de BitLocker en la revisión de dependencias. Nuestra guía de verificación de recuperación BitLocker en AD: hacer coincidir el registro del directorio con el protector actual del volumen explica por qué un objeto de recuperación debe corresponder al protector de recuperación realmente presente en el volumen. Su mera presencia no acredita una recuperación utilizable, y su fecha no establece cuándo se deshabilitó la cuenta de equipo.

Acuerde cómo seguirán disponibles la información de recuperación necesaria y los demás datos hijos conforme al proceso aprobado de recuperación y retención de la organización antes de eliminar el equipo. Mantenga los secretos fuera de los tickets de limpieza y los registros del SIEM. Registre la decisión sobre las dependencias y su responsable, en lugar de copiar contraseñas de recuperación en las pruebas. Se trata de una comprobación de dependencias de la retirada; la guía enlazada proporciona el procedimiento independiente de verificación del volumen y del protector.

Paso 3: previsualizar y realizar solo la eliminación aprobada de un único objeto

Una vez completadas las comprobaciones de responsabilidad, retirada de servicio, dependencias y recuperación, utilice la sintaxis de Remove-ADComputer de Microsoft para el objeto verificado. La documentación admite identidad GUID, servidor explícito y -WhatIf. La siguiente previsualización no ejecuta la eliminación:

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -WhatIf

Compare el destino y la previsualización con el registro de retirada aprobado. Una previsualización no verifica que la máquina no se utilice, que se conserven los datos de recuperación ni que la acción haya sido aprobada. Vuelva a leer el objeto actual antes de la operación autorizada si las pruebas pueden haber cambiado.

Solo después de esa validación, el comando para un único objeto mantiene una solicitud explícita de confirmación:

Remove-ADComputer -Identity $computer.ObjectGUID -Server 'dc01.contoso.com' -Confirm

Si los hijos, la protección u otro error impiden la eliminación, deténgase y resuelva la causa específica mediante el procedimiento aprobado. No convierta un fallo en una eliminación recursiva del equipo y sus descendientes. Conserve el resultado real del comando; intentar una operación no demuestra que se haya eliminado la cuenta.

Paso 4: cerrar la revisión con pruebas

Registre la decisión final, el aprobador, las decisiones sobre dependencias y el resultado de la operación. Verifique el resultado en el directorio mediante una lectura autorizada de la identidad exacta en el DC registrado, conservando cualquier error y su significado. Confirme que la información de recuperación necesaria sigue disponible mediante el proceso acordado. Para un objeto conservado, documente el motivo de conservación y la investigación pendiente en lugar de declarar completada la remediación.

Cómo detecta EtcSec este caso

En el commit revisado del recopilador 20268a321609c193b79c5da6764f3f56950449cb, COMPUTER_DISABLED_NOT_DELETED es un hallazgo de gravedad Low. Su Detect() examina los equipos recopilados e incluye un objeto únicamente cuando Disabled es true, WhenChanged no es cero y WhenChanged.Before(Now.AddDate(0, 0, -30)) es true. La comparación es estricta: se excluye una marca de tiempo igual al umbral.

El umbral resta 30 días naturales al Now de la auditoría. Es una referencia de higiene operativa de etc-collector, no una fecha límite de eliminación exigida por Microsoft u otra norma identificada. Una modificación posterior del objeto adelanta whenChanged y puede posponer esta señal mientras la cuenta sigue deshabilitada.

En el proveedor LDAP revisado, un whenChanged ausente o inválido se convierte en un tiempo cero, que este detector omite. Un userAccountControl ausente o sintácticamente inválido se convierte en cero, por lo que el analizador no marca ese objeto como deshabilitado. El filtro de equipo predeterminado es (objectClass=computer). Aunque el analizador puede identificar una clase gMSA, este Detect() no excluye explícitamente controladores de dominio ni gMSA.

El detector no establece la fecha de deshabilitación, el responsable, la aprobación de retirada de servicio, los objetos hijos, las dependencias de recuperación ni un historial de eventos que la respalde. Un hallazgo positivo abre la revisión de pruebas descrita anteriormente. Un recuento cero no puede cerrar esas preguntas independientes, especialmente cuando la recopilación o la disponibilidad de atributos son inciertas.