Cuentas Obsoletas y Sobreprivilegiadas: El Riesgo Oculto en Active Directory

Las cuentas obsoletas y sobreprivilegiadas no son solo ruido de higiene del directorio. En Active Directory, una cuenta inactiva que todavía pertenece a un grupo privilegiado, que aún conserva una contraseña antigua, o que todavía posee una dependencia de servicio, puede convertirse en un camino de baja visibilidad de vuelta al dominio.

¿Qué son las cuentas obsoletas y sobreprivilegiadas?

Las cuentas obsoletas y sobreprivilegiadas son identidades antiguas o de baja visibilidad que aún se resuelven en acceso administrativo significativo dentro de Active Directory. Una cuenta se vuelve obsoleta cuando nadie la supervisa ya; se vuelve sobreprivilegiada cuando conserva más acceso del que exige su rol actual. Ambos problemas suelen solaparse.

Los entornos de Active Directory acumulan cuentas con el tiempo. Los empleados se van, los contratistas terminan sus proyectos, las cuentas de servicio sobreviven a los proyectos y las identidades de administración de emergencia permanecen habilitadas mucho después de que desaparezca el motivo original.

Desde la perspectiva de un atacante, esas dos condiciones se refuerzan mutuamente. El mejor objetivo no es solo una cuenta antigua. Es una cuenta antigua que todavía se encuentra en una ruta privilegiada, está débilmente monitoreada y no tiene un propietario claro que note actividad inusual.

Cómo funciona

Las cuentas de AD permanecen activas hasta que alguien las deshabilita o las elimina. Si se omite el offboarding, la revisión de cuentas de servicio o la revisión de privilegios, el entorno se llena de cuentas que:

• no se han autenticado en meses o años
• todavía pertenecen a grupos privilegiados
• tienen contraseñas establecidas hace mucho tiempo y nunca revisadas
• quedan fuera de cualquier revisión de ciclo de vida disciplinada

Una cuenta privilegiada obsoleta resulta atractiva porque combina alto valor con bajo escrutinio. Puede que la cuenta no aparezca en el trabajo administrativo diario, pero sigue resolviéndose en los mismos permisos cuando se presenta la contraseña.

La guía de remediación de cuentas obsoletas de Microsoft señala específicamente las cuentas inactivas como un riesgo de seguridad y recomienda verificaciones periódicas. Esa misma guía también advierte que las cuentas de servicio pueden no iniciar sesión durante periodos prolongados, por lo que la limpieza necesita salvaguardas en lugar de una eliminación a ciegas.

Cuentas obsoletas y sobreprivilegiadas: los límites del alcance cuando las busca

Una revisión de cuentas obsoletas debe ser precisa sobre lo que realmente significan las marcas de tiempo.

LastLogonDate y los datos de inicio de sesión replicados subyacentes son útiles para encontrar candidatas a limpieza, pero no son lo mismo que el último uso forense exacto en cada controlador de dominio. Son suficientemente buenos para identificar cuentas que necesitan revisión humana. No deben ser la única señal antes de eliminar una identidad de servicio sensible.

Por eso las revisiones maduras separan al menos tres casos:

• cuentas de usuario que claramente deberían haberse deshabilitado tras el offboarding
• identidades de servicio o de tareas programadas que aún pueden usarse de forma no interactiva
• identidades privilegiadas de emergencia o compartidas que sobrevivieron porque nadie quiso probar las dependencias

El objetivo no es conservar toda cuenta antigua porque una aplicación podría fallar. El objetivo es dejar de tratar la propiedad poco clara como una razón para preservar el privilegio dormido indefinidamente.

Una distinción operativa útil es la que hay entre inactividad e irrelevancia. Una cuenta puede estar silenciosa porque está abandonada, o silenciosa porque solo se activa mensualmente mediante una copia de seguridad, una tarea programada o un proceso de recuperación poco usado. La revisión debe separar esos casos explícitamente.

Las limitaciones de las marcas de tiempo que importan

Para la clasificación de cuentas obsoletas, use varias señales. Microsoft indica que PasswordLastSet se replica y que lastLogonTimeStamp existe para ayudar a identificar cuentas potencialmente obsoletas. Eso hace que esos atributos sean útiles para una limpieza a nivel de dominio. No significa que prueben que una cuenta no tiene dependencias.

Una revisión segura combina:

• datos de inactividad replicados, como la antigüedad de la contraseña o lastLogonTimeStamp
• datos de eventos del controlador de dominio sobre autenticación reciente
• análisis de la pertenencia a grupos y de los derechos delegados
• verificaciones de dependencias de servicios, tareas programadas y aplicaciones
• confirmación del propietario para las cuentas que deben permanecer habilitadas

Cuanto mayor es el privilegio, menos aceptable resulta confiar en una sola marca de tiempo. Un miembro dormido de Domain Admins y un usuario dormido de bajo privilegio no representan el mismo riesgo.

La cadena de ataque

Paso 1 - Enumerar cuentas obsoletas y de alto valor

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
  -Properties LastLogonDate, PasswordLastSet, MemberOf |
  Select-Object SamAccountName, LastLogonDate, PasswordLastSet |
  Sort-Object LastLogonDate

$groups = @('Domain Admins','Enterprise Admins','Schema Admins','Backup Operators','Account Operators')
foreach ($group in $groups) {
  Get-ADGroupMember -Identity $group -Recursive |
    Get-ADUser -Properties LastLogonDate, PasswordLastSet |
    Select-Object @{N='Group';E={$group}}, SamAccountName, LastLogonDate, PasswordLastSet
}

Microsoft también documenta Search-ADAccount -AccountInactive -UsersOnly como una forma práctica de encontrar cuentas de usuario inactivas. Úselo como herramienta de descubrimiento y añada después el contexto de privilegio y dependencia antes de actuar.

Paso 2 - Priorizar cuentas con contraseñas antiguas y alto privilegio

Las cuentas con contraseñas muy antiguas, pertenencia a grupos estable y sin propietario actual son las primeras que un atacante intentará validar, rociar (spray) o reutilizar.

Priorice las cuentas que cumplan más de una condición:

• datos de inicio de sesión obsoletos
• PasswordLastSet antiguo
• pertenencia a grupos privilegiados
• pertenencia a través de grupos anidados
• indicadores de cuenta como "la contraseña nunca expira"
• sin propietario de negocio o técnico designado

Paso 3 - Convertir el acceso dormido en acceso privilegiado

Una cuenta obsoleta que todavía se resuelve en Domain Admins, derechos administrativos delegados, privilegios de copia de seguridad o acceso amplio a servidores no necesita un exploit novedoso. El privilegio ya existe.

Paso 4 - Persistir mediante identidades de baja visibilidad

Las cuentas dormidas suelen estar ausentes de los flujos de trabajo diarios, por lo que la actividad inusual puede pasar desapercibida más tiempo del debido. Esto es especialmente cierto para las cuentas de administrador compartidas y las identidades de servicio que nadie ha revisado recientemente.

Detección

Event IDs de Windows

Microsoft documenta "Audit Security Group Management" como la subcategoría de auditoría que genera eventos para los cambios de pertenencia a grupos de seguridad, incluidos los grupos globales, locales y universales. Esa distinción importa cuando la ruta privilegiada usa grupos anidados o no globales.

Señales de comportamiento

• primer uso exitoso de una cuenta tras un largo periodo de inactividad
• pertenencia a grupo privilegiado combinada con una antigüedad de contraseña muy alta
• cuentas de servicio que inician sesión de forma interactiva o desde hosts inesperados
• cuentas compartidas usadas desde varios sistemas sin una razón operativa clara

Consulta SIEM (Elastic KQL)

event.code: '4624' AND
winlog.event_data.LogonType: '3' AND
winlog.event_data.TargetUserName: (* AND NOT '*$')

Esa consulta necesita enriquecerse con la antigüedad de la cuenta, el contexto de privilegio y la propiedad esperada. La inactividad sin contexto es solo una lista. La inactividad más el privilegio es el hallazgo real.

El enriquecimiento de detección que hace útil la alerta

Una alerta de cuenta obsoleta debe llevar suficiente contexto para que el responder decida si deshabilitar, investigar o escalar:

• estado actual habilitado/deshabilitado
• fecha del último cambio de contraseña
• contexto del último inicio de sesión interactivo y de red conocido
• grupos privilegiados directos y anidados
• si la cuenta está marcada como sensible o protegida
• si la cuenta posee servicios, tareas programadas o credenciales de aplicación
• si la cuenta tiene actividad Kerberos o NTLM reciente

Sin ese enriquecimiento, los equipos suelen crear una hoja de cálculo y posponer las decisiones difíciles.

Remediación

Acción rápida: deshabilite primero las cuentas de usuario obviamente obsoletas, y luego trabaje las identidades de servicio y compartidas con una revisión basada en el propietario en lugar de dejarlas indefinidamente en su sitio.

1. Deshabilitar cuentas obsoletas

$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
  -SearchBase 'OU=Users,DC=corp,DC=local' `
  -Properties LastLogonDate | ForEach-Object {
    Disable-ADAccount -Identity $_
    Write-Host "Disabled: $($_.SamAccountName) - Last login: $($_.LastLogonDate)"
  }

Para las cuentas de usuario que claramente ya no deberían existir, deshabilítelas primero, monitoree el impacto y elimínelas después del periodo de retención que acepten sus equipos de operaciones. No elimine objetos privilegiados o vinculados a servicios como primera acción, salvo que ya esté probada la ausencia de dependencia.

2. Reducir la pertenencia a grupos privilegiados

$groups = @('Domain Admins','Enterprise Admins','Schema Admins')
$groups | ForEach-Object {
  Get-ADGroupMember -Identity $_ -Recursive |
    Select-Object @{N='Group';E={$_}}, SamAccountName, distinguishedName
} | Export-Csv privileged_members.csv -NoTypeInformation

Elimine el privilegio permanente antes de discutir la eliminación de la cuenta. Una cuenta obsoleta sin pertenencia a Domain Admins o derechos delegados equivalentes sigue siendo trabajo de limpieza, pero ya no representa la misma exposición inmediata de Tier-0.

3. Aplicar una política más estricta a las identidades privilegiadas

New-ADFineGrainedPasswordPolicy -Name 'PrivilegedAccountsPSO' `
  -Precedence 10 `
  -MinPasswordLength 20 `
  -ComplexityEnabled $true `
  -PasswordHistoryCount 24 `
  -MaxPasswordAge (New-TimeSpan -Days 60) `
  -LockoutThreshold 3

Add-ADFineGrainedPasswordPolicySubject -Identity 'PrivilegedAccountsPSO' `
  -Subjects 'Domain Admins'

Microsoft documenta las políticas de contraseñas granulares como una forma de aplicar diferentes configuraciones de contraseña y bloqueo a distintos conjuntos de usuarios, incluidas configuraciones más estrictas para cuentas privilegiadas. Eso es útil cuando todavía existen cuentas privilegiadas, pero no sustituye la eliminación de la pertenencia innecesaria.

4. Corregir el proceso del ciclo de vida, no solo las cuentas

Las causas recurrentes suelen ser operativas:

• offboarding que deshabilita el acceso al correo pero olvida los grupos de AD
• cuentas de servicio sin propietario tras un cambio de equipo
• cuentas de administrador de emergencia que nunca volvieron a revisión
• cuentas compartidas mantenidas vivas porque nadie quiere probar la dependencia

Una remediación creíble cierra esas brechas de proceso mientras se realiza la limpieza de cuentas.

5. Poner en cuarentena las excepciones en lugar de olvidarlas

Si una cuenta de baja actividad debe permanecer habilitada, documéntela como una excepción con una fecha de revisión y un propietario designado. La excepción debe incluir:

• por qué la cuenta debe permanecer habilitada
• qué sistemas dependen de ella
• qué grupos o derechos delegados posee
• qué se rompería si se deshabilitara
• qué monitoreo demuestra que solo se usa como se pretende

Las excepciones sin fecha de vencimiento son la forma en que regresan las cuentas obsoletas y sobreprivilegiadas.

Valide antes de cerrar el hallazgo

Una limpieza de cuentas obsoletas no termina cuando la hoja de cálculo se ve más corta. Valide el resultado real del control.

• vuelva a ejecutar la exportación de cuentas inactivas y confirme que las mismas identidades de alto riesgo ya no están habilitadas
• confirme que la pertenencia a grupos privilegiados se eliminó de verdad, y no solo se dejó en un objeto deshabilitado que podría reactivarse sin cambios
• revise la actividad reciente de 4624 y 4768 para detectar cuentas que se volvieron a usar tras la decisión de limpieza
• documente el propietario, la dependencia y la próxima fecha de revisión para cualquier cuenta que deba permanecer habilitada pese a la baja actividad
• verifique el alcance de la política de contraseñas granular para las cuentas privilegiadas que permanezcan habilitadas
• revise las rutas de grupos anidados para comprobar que el privilegio no se preservó indirectamente

Para las cuentas de servicio, la verificación final también debe confirmar que la dependencia es real y sigue vigente. Si nadie puede probar por qué existe la cuenta, eso es evidencia para retirarla, no para otra excepción.

Cómo EtcSec detecta esto

EtcSec hace que este hallazgo sea más útil al correlacionar la inactividad, el nivel de privilegio, la antigüedad de la contraseña y la falta de cobertura de políticas. Eso importa porque una cuenta dormida de bajo valor y una cuenta dormida privilegiada no son el mismo problema operativo.

Lecturas relacionadas

• Seguridad de contraseñas en Active Directory: las malas configuraciones que importan
• Kerberoasting: cómo los atacantes crackean las contraseñas de cuentas de servicio
• Supervisión de Active Directory: los Event IDs de seguridad que importan
• Anidamiento peligroso de grupos: rutas ocultas hacia Domain Admin
• Rutas de ataque en Active Directory hacia Domain Admin

Referencias principales

• Regularly check for and remove inactive user accounts in Active Directory
• Audit Security Group Management
• Configure fine-grained password policies for AD DS
• Configure Windows event auditing (Microsoft Defender for Identity)