Higiene de los Objetos de Equipo Controlador de Dominio Active Directory Esquema LAPS: Seis Brechas Que una Auditoría Real Sigue Encontrando

Higiene de los Objetos de Equipo Controlador de Dominio Active Directory Esquema LAPS: Qué Cubre Esta Auditoría

Higiene de los objetos de equipo controlador de dominio Active Directory esquema LAPS: esto es lo que una auditoría real detecta primero, y ninguna de estas condiciones es individualmente dramática: un esquema de AD que nunca se extendió para LAPS, controladores de dominio ubicados fuera de su OU, y objetos de equipo que nadie ha revisado en años. Juntas, subyacen bajo las rutas de ataque más mediáticas — Kerberoasting, DCSync, escalada de ADCS — y determinan en silencio si esos ataques llegan siquiera a ser necesarios. Un dominio donde cada objeto de equipo está al día, cada controlador de dominio está bien ubicado, y las contraseñas de administrador local se gestionan de forma centralizada es un dominio donde un atacante tiene que esforzarse para conseguir un punto de apoyo. Un dominio donde nada de eso es cierto regala atajos.

Este artículo cubre seis brechas que una auditoría real contra un entorno AD real encuentra sistemáticamente juntas, ninguna de las cuales aparece en una lista típica de "top 10 de malas configuraciones" porque ninguna es una vulnerabilidad aislada y dramática:

1. La extensión de esquema de Active Directory para LAPS nunca se aplicó — no "LAPS está desplegado pero no en todas partes", los atributos de esquema en sí no existen.
2. Controladores de dominio cuyo objeto de equipo vive fuera de la OU Domain Controllers.
3. Objetos de controlador de dominio que dejaron de replicar y nunca se limpiaron.
4. Objetos de equipo obsoletos e inactivos, sin nadie que los vigile.
5. Equipos sin BitLocker, incluidos controladores de dominio que alojan NTDS.dit.
6. Cuentas de equipo cuya contraseña de máquina dejó de rotar.

Cada una es, por separado, poco dramática. Juntas describen un entorno donde el ciclo de vida de los objetos no es responsabilidad de nadie — y esa es exactamente la condición con la que cuentan los atacantes cuando los controles más vistosos ya están cerrados.

Por Qué un Esquema LAPS No Extendido Es la Brecha Más Profunda

Local Administrator Password Solution existe en dos generaciones, y la distinción importa aquí. El LAPS de Microsoft heredado almacenaba la contraseña gestionada en el atributo ms-Mcs-AdmPwd, añadido al esquema ejecutando Update-AdmPwdADSchema como miembro de Schema Admins — vea la referencia oficial de atributos de Microsoft en MS-ADA2. Desde la actualización acumulativa de abril de 2023, Windows LAPS se distribuye como componente nativo del sistema operativo y usa un conjunto de atributos distinto y cifrado (msLAPS-Password, msLAPS-EncryptedPassword, msLAPS-PasswordExpirationTime) — vea la referencia técnica de Windows LAPS. Cualquiera de las dos generaciones requiere su propia extensión de esquema, ejecutada una sola vez (Update-LapsADSchema para los nuevos atributos), a nivel de todo el dominio, por alguien en Schema Admins.

Ese paso es fácil de saltarse porque omitirlo no produce ningún error. Las GPO se pueden vincular, el CSE de LAPS se puede desplegar en cada endpoint, y no pasará nada — no existe ningún atributo donde escribir la contraseña. Esta es una brecha distinta y más fundamental que "LAPS está configurado pero algunos equipos no están en el alcance", que es la brecha Windows LAPS No Implementado que hemos cubierto por separado. Aquí, el esquema en sí nunca se tocó, lo que significa que todas las contraseñas de administrador local del dominio están sin gestionar — habitualmente idénticas en toda una imagen de despliegue, según el análisis de despliegue de LAPS de ADSecurity.org. Una sola credencial de administrador local basada en imagen, una vez crackeada o extraída de una única estación de trabajo de bajo valor, desbloquea el movimiento lateral hacia todas las máquinas construidas a partir de esa imagen.

DC Fuera de su OU y Metadatos que Nadie Limpió

DC_NOT_IN_DC_OU parece cosmético hasta que se comprueba qué vincula realmente Microsoft a la OU Domain Controllers por defecto: la política Default Domain Controllers Policy, que establece las asignaciones de derechos de usuario específicas de los DC, la política de auditoría y las opciones de seguridad — la misma cadena de herencia de GPO que analizamos en Malas Configuraciones de GPO: Cómo la Directiva de Grupo se Convierte en un Vector de Ataque. Mover el objeto de equipo de un controlador de dominio a otra OU — incluso a una sub-OU creada por orden organizativo — rompe esa cadena de herencia, y Microsoft lleva años documentando esto como una configuración no soportada, no como una preferencia de estilo; vea el artículo de Computerworld sobre este error y la guía de seguridad de controladores de dominio de Semperis. Un DC que silenciosamente perdió su política de auditoría de referencia es un DC que genera registros de seguridad incompletos — que es exactamente el tipo de punto ciego del que depende una técnica de registro de DC fraudulento como DCShadow; cubrimos ese abuso específico en Ataque DCShadow: Registro de un Controlador de Dominio Fraudulento.

DC_INACTIVE es el problema gemelo: un objeto de equipo de DC que dejó de replicar y nunca se dio de baja formalmente. La guía de Microsoft es explícita en que un DC retirado por un fallo de hardware o una degradación forzada fallida deja metadatos huérfanos de directorio y DNS — objetos de equipo y NTDS Settings, conexiones de replicación, registros SRV/CNAME — que hay que eliminar deliberadamente mediante una limpieza de metadatos, no dejarlos en su sitio; vea Limpiar los metadatos de servidor de un controlador de dominio de Active Directory. Dejada así, esa identidad de DC obsoleta produce resultados de localización de DC inconsistentes y le da a un atacante un objeto plausible y rara vez auditado que suplantar o reutilizar. La ubicación de objetos y la salud de la replicación son la mitad de "higiene" de la seguridad de los DC; la mitad de red/servicio — cifrado LDAPS débil, Print Spooler expuesto, desfase de reloj más allá de la tolerancia de Kerberos — es una checklist distinta que publicamos en Auditoría de DC: TLS Débil en LDAPS, Spooler de Impresión, Sincronización Horaria.

Equipos Obsoletos, Sin BitLocker, y Contraseñas de Máquina que Nadie Rota

COMPUTER_STALE_INACTIVE es el equivalente, en un objeto de equipo, de una cuenta de usuario obsoleta: una máquina que no se ha autenticado en meses pero sigue siendo un principal Kerberos totalmente válido, con un SID, pertenencias a grupos y — si alguna vez alguien le concedió derechos de delegación o de escritura sobre algo sensible — una superficie de ataque que nadie vigila. Ese mismo punto ciego afecta también a las cuentas de usuario obsoletas, un problema cubierto por separado en Cuentas Obsoletas y Sobreprivilegiadas en AD. Los riesgos distintos y más profundos que se asientan sobre un objeto de equipo una vez que un atacante lo controla (delegación sin restricciones, abuso de RBCD, derechos que habilitan DCSync) se cubren por separado en Superficie de Ataque de los Objetos de Equipo en Active Directory; esta brecha trata simplemente de que esos objetos existan, sin revisión alguna.

COMPUTER_NO_BITLOCKER importa más en las máquinas que alojan los datos más valiosos en reposo. Para un controlador de dominio en concreto, eso es NTDS.dit — la base de datos que contiene el hash de contraseña de cada cuenta. La propia guía de Microsoft para el endurecimiento de controladores de dominio recomienda BitLocker respaldado por TPM en todos los volúmenes de los DC precisamente porque protege el directorio incluso si se retira un disco físico del servidor (vea la referencia Securing Domain Controllers Against Attack). Cuando BitLocker se activa con custodia de claves basada en AD, la contraseña de recuperación se deposita como objeto hijo msFVE-RecoveryInformation bajo el objeto de equipo — vea Storing BitLocker Recovery Keys in Active Directory — por lo que su ausencia es directamente consultable, no algo que haya que creerse a partir de una hoja de cálculo.

COMPUTER_PASSWORD_OLD sigue una señal más sutil. Por defecto, "Miembro de dominio: antigüedad máxima de contraseña de cuenta de equipo" es de 30 días — cada equipo unido al dominio debe rotar su propia contraseña de máquina con esa cadencia, un ajuste documentado en la referencia de directivas de seguridad de Microsoft y explicado en detalle por el tutorial de ADSecurity.org sobre la contraseña de cuenta de máquina. Una cuenta de máquina con una contraseña mucho más antigua que 30 días y que aún inicia sesión activamente suele indicar un canal seguro roto, no un sistema endurecido — y una contraseña de máquina estática le da a un atacante que compromete la cuenta mucho más tiempo para forzarla por fuerza bruta o reproducirla antes de que la rotación fuerce un reinicio.

Detección

# 1. Confirmar que la extensión de esquema LAPS existe (cualquiera de las dos generaciones)
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
    -Filter {name -eq "ms-Mcs-AdmPwd" -or name -eq "msLAPS-Password"}

# 2. Controladores de dominio cuyo objeto de equipo vive fuera de la OU de DC por defecto
Get-ADDomainController -Filter * | ForEach-Object {
    $dn = (Get-ADComputer $_.Name).DistinguishedName
    if ($dn -notmatch "OU=Domain Controllers") { "$($_.Name) -> $dn" }
}

# 3. Objetos de equipo obsoletos — sin autenticación en 90+ días
Get-ADComputer -Filter * -Properties lastLogonTimestamp |
    Where-Object { [DateTime]::FromFileTime($_.lastLogonTimestamp) -lt (Get-Date).AddDays(-90) } |
    Select-Object Name, @{N='LastLogon';E={[DateTime]::FromFileTime($_.lastLogonTimestamp)}}

# 4. Equipos sin información de recuperación de BitLocker custodiada en AD
Get-ADComputer -Filter * | ForEach-Object {
    $recovery = Get-ADObject -Filter {objectClass -eq "msFVE-RecoveryInformation"} -SearchBase $_.DistinguishedName
    if (-not $recovery) { $_.Name }
}

# 5. Contraseña de cuenta de máquina más antigua que la política de 30 días
Get-ADComputer -Filter * -Properties PasswordLastSet |
    Where-Object { $_.PasswordLastSet -lt (Get-Date).AddDays(-30) } |
    Select-Object Name, PasswordLastSet

Remediación

1. Extender el Esquema LAPS, Una Vez, a Nivel de Todo el Dominio

Ejecute Update-LapsADSchema (Windows LAPS) — o Update-AdmPwdADSchema si la organización se mantiene deliberadamente en LAPS heredado — como miembro de Schema Admins, y después delegue el permiso de escritura SELF sobre los nuevos atributos con Set-LapsADComputerSelfPermission antes de desplegar la GPO.

2. Devolver los Objetos de DC Mal Ubicados a Domain Controllers

Use Move-ADObject o ADUC para reubicar el objeto de equipo, y después confirme que la Default Domain Controllers Policy se reaplica con gpresult /r en el DC afectado.

3. Resolver o Retirar Deliberadamente los DC Inactivos

Si repadmin /showrepl muestra un fallo de replicación genuino, corríjalo. Si el DC realmente ya no existe, ejecute una limpieza de metadatos adecuada en lugar de dejar en su sitio el objeto huérfano y los registros DNS.

4. Deshabilitar y Después Eliminar los Equipos Obsoletos con un Calendario Fijo

Por ejemplo, deshabilitar a los 90 días de inactividad y eliminar a los 180 — la misma disciplina ya aplicada a las cuentas de usuario obsoletas.

5. Habilitar BitLocker con TPM y Custodia de Claves en AD

Priorice primero los controladores de dominio, mediante el ajuste de GPO "Almacenar información de recuperación de BitLocker en Active Directory Domain Services", para que msFVE-RecoveryInformation se rellene y sea auditable.

6. Dejar la Política de 30 Días de Antigüedad de Contraseña de Máquina Tal Cual

Investigue, en lugar de ignorar, cualquier máquina activa cuyo PasswordLastSet se haya desviado bastante más allá de ese límite — normalmente Test-ComputerSecureChannel -Repair arregla un canal seguro roto que está bloqueando la rotación en silencio.

Cómo Detecta Esto EtcSec

La auditoría de Active Directory de EtcSec comprueba directamente estas seis condiciones contra el dominio: COMPUTER_NO_LAPS para una extensión de esquema ausente, DC_NOT_IN_DC_OU y DC_INACTIVE para la ubicación y salud de replicación de los controladores de dominio, COMPUTER_STALE_INACTIVE para máquinas inactivas nunca revisadas, COMPUTER_NO_BITLOCKER para el cifrado de disco sin custodiar, y COMPUTER_PASSWORD_OLD para la rotación de contraseña de máquina estancada.