Cuentas AD deshabilitadas, expiradas, bloqueadas grupos privilegiados: por qué persisten los derechos de admin

Cuentas AD deshabilitadas, expiradas, bloqueadas grupos privilegiados es exactamente el hueco que cubre este artículo: una cuenta cuyo propio estado —deshabilitada, expirada o bloqueada— indica que no debería tener acceso, pero que sigue siendo formalmente miembro de Domain Admins, Enterprise Admins u otro grupo Tier 0. Una cuenta de administrador deshabilitada es casi siempre un paso de offboarding olvidado. Una cuenta expirada es un acceso concedido por tiempo limitado que nadie retiró del grupo cuando venció el plazo. Una cuenta bloqueada puede ser solo un ticket de helpdesk, o el tramo final de un ataque de password spraying todavía en curso. Este artículo cubre los tres estados, además de su prima cercana, el flag adminCount huérfano, y cómo detectarlos y corregirlos.

Cuentas AD deshabilitadas, expiradas, bloqueadas grupos privilegiados: los cuatro estados

Cada una de estas cuatro condiciones tiene una definición precisa a nivel de atributo, y cada una tiene su propia forma de terminar silenciosamente dentro de un grupo privilegiado sin que nadie haya decidido que así fuera.

La cuenta deshabilitada

El bit ACCOUNTDISABLE (0x2) está activado en userAccountControl; la cuenta no puede iniciar sesión de forma interactiva. (Microsoft Learn: UserAccountControl property flags) Las cuentas deshabilitadas se acumulan porque las checklists de offboarding suelen detenerse en «deshabilitar la cuenta». Eso bloquea el inicio de sesión, pero no cambia nada en la pertenencia a grupos: el SID sigue en Domain Admins. Cualquier herramienta de rutas de ataque que calcule «quién podría llegar a ser administrador de dominio» —BloodHound, PingCastle o EtcSec incluidos— la sigue contando, porque esos grafos se construyen sobre la pertenencia a grupos, no sobre userAccountControl. Si la cuenta se reactiva alguna vez —por error, por un ticket de ITSM retrasado, o por un atacante que ha obtenido permisos para cambiar un solo bit— su antiguo privilegio vuelve a estar activo de inmediato, sin ningún trabajo adicional.

La cuenta expirada

accountExpires contiene un valor distinto de 0 o del centinela «nunca expira» 9223372036854775807, y ese valor (un FILETIME de Windows) está en el pasado. (Microsoft Learn: Account-Expires attribute) Este atributo se usa con frecuencia para cuentas de contratistas o de elevación temporal con una fecha de fin planificada. El KDC se niega a emitir un ticket-granting ticket pasada esa fecha, así que la cuenta deja de funcionar para el inicio de sesión interactivo o de red —pero accountExpires tampoco afecta a la pertenencia a grupos. Si la intención real era «el acceso de administrador de esta persona termina en esta fecha», fijar una fecha de expiración sin retirar también la pertenencia al grupo solo bloquea la puerta principal.

La cuenta bloqueada

lockoutTime es distinto de cero y la duración del bloqueo de la cuenta aún no ha transcurrido. Windows nunca establece un bit UF_LOCKOUT en el propio valor almacenado de userAccountControl; el estado bloqueado/desbloqueado en vivo se expone mediante el atributo construido msDS-User-Account-Control-Computed. (MS-ADLS: lockoutTime, MS-ADTS: msDS-User-Account-Control-Computed) A diferencia de deshabilitar o expirar, el bloqueo no es una decisión administrativa: es un efecto secundario de los intentos de inicio de sesión fallidos que chocan con la política de bloqueo de cuentas. Una cuenta privilegiada puede bloquearse porque alguien escribió mal su contraseña, o porque está siendo atacada en ese momento: una campaña de password spraying o fuerza bruta que llega a una cuenta privilegiada y está a punto de tener éxito puede producir exactamente la misma señal justo antes de autenticarse.

El flag adminCount huérfano

adminCount=1 marca a los miembros de los grupos protegidos por AdminSDHolder, pero una cuenta puede conservarlo aunque ya no pertenezca a ningún grupo protegido —el caso inverso: no un privilegio vivo en una cuenta muerta, sino un marcador muerto que queda de un privilegio ya retirado. El mecanismo detrás de esto es el proceso SDProp, que se ejecuta en el controlador de dominio que tiene el rol PDC Emulator (por defecto, aproximadamente una vez por hora), recorre la pertenencia de los grupos protegidos, establece adminCount=1 en cada miembro, copia la ACL de AdminSDHolder en el objeto, y deshabilita la herencia de ACL. (Microsoft Community Hub: Five common questions about AdminSDHolder and SDProp) Cuando la cuenta se retira más tarde del grupo protegido, SDProp simplemente deja de tocarla: no revierte adminCount a 0 ni restaura la herencia. El flag y la ACL desconectada quedan como un marcador silencioso, de apariencia permanente, de un privilegio que la cuenta ya no tiene.

Detección

Atributos y consultas de PowerShell

Las consultas directas de pertenencia con el módulo de PowerShell de AD revelan rápidamente las cuatro condiciones:

# Cuentas deshabilitadas que siguen en un grupo privilegiado
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Get-ADUser -Properties Enabled, userAccountControl |
    Where-Object { -not $_.Enabled }

# Cuentas expiradas (accountExpires establecido y en el pasado — 0 y el
# centinela int64 máximo significan ambos "nunca expira")
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Get-ADUser -Properties accountExpires |
    Where-Object {
        $_.accountExpires -gt 0 -and
        $_.accountExpires -lt 9223372036854775807 -and
        [datetime]::FromFileTime($_.accountExpires) -lt (Get-Date)
    }

# Cuentas actualmente bloqueadas, cruzadas con los grupos privilegiados
Search-ADAccount -LockedOut -UsersOnly |
    Where-Object { (Get-ADPrincipalGroupMembership $_.SamAccountName).Name -contains "Domain Admins" }

# adminCount=1 sin pertenencia actual a un grupo protegido (flag huérfano)
Get-ADUser -LDAPFilter "(adminCount=1)" -Properties adminCount, memberOf, Enabled

Filtro LDAP para herramientas de bind directo

Para herramientas que no pasan por el módulo de PowerShell de AD, la comprobación del bit de deshabilitación usa el OID LDAP_MATCHING_RULE_BIT_AND sobre userAccountControl:

(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))

Esto coincide con la propia semántica de AND bit a bit de AD: la cláusula solo se cumple si el segundo bit (0x2, ACCOUNTDISABLE) está activado en el valor almacenado. (MS-ADTS: LDAP_MATCHING_RULE_BIT_AND)

Event IDs de Windows para correlacionar

Estos eventos se registran en los controladores de dominio bajo la auditoría de Account Management —consulte la referencia completa de Event IDs de supervisión de Active Directory para la configuración de registro más amplia:

Fuentes: Event ID 4725, Event ID 4740, Event ID 4767, Event ID 4738, Event ID 4728, Event ID 4756.

Remediation

Para cuentas deshabilitadas y expiradas

1. Haga que la comprobación sea recurrente, no solo parte del offboarding. Un proceso de baja que deshabilita la cuenta cuando alguien se marcha no detectará una fecha de expiración que ya venció hace seis meses. Programe la ejecución regular de las consultas anteriores, o de una regla SIEM/EASM equivalente.
2. Vincule el offboarding al retiro del grupo, no solo a deshabilitar la cuenta. Deshabilitar bloquea el inicio de sesión; no revoca la pertenencia al grupo que los grafos de rutas de ataque, los derechos delegados y parte de la lógica de autorización de aplicaciones siguen leyendo. Cuando el acceso deba terminar, retire explícitamente la cuenta del grupo privilegiado.
3. Trate las fechas de expiración como un disparador de revisión de pertenencia, no como un sustituto. Si una cuenta se incorporó a un grupo privilegiado por tiempo limitado, fije un recordatorio correspondiente para retirar la pertenencia en la fecha de expiración o antes —no dependa únicamente de accountExpires para representar «esta persona ya no es administradora».

Para cuentas privilegiadas bloqueadas

Como desbloquear una cuenta es una operación barata, rápida y delegable —un permiso de AD distinto al de restablecer la contraseña—, una cuenta Tier 0 bloqueada está a un solo desbloqueo de volver a ser totalmente utilizable. Enrute el Event ID 4740 en miembros de grupos protegidos hacia su propia vía de alerta, separada del ruido rutinario de bloqueos de helpdesk, y confirme que el desbloqueo (Event ID 4767) provino de un administrador esperado antes de dar el incidente por cerrado.

Para flags adminCount huérfanos

Para cada cuenta con adminCount=1 pero sin pertenencia actual a un grupo protegido, confirme que realmente ya no es privilegiada —revise las pertenencias anidadas, no solo las directas, ya que retirarla de un grupo asignado directamente puede dejar privilegio indirecto en pie. Una vez confirmado que está limpia, reinicie adminCount y reactive la herencia de ACL en lugar de dejar el flag obsoleto y la ACL desconectada; dejarlos ensucia cada futura auditoría de permisos sobre ese objeto.

Cómo lo detecta EtcSec

EtcSec comprueba las cuatro condiciones en cada auditoría de Active Directory: DISABLED_ACCOUNT_IN_ADMIN_GROUP y EXPIRED_ACCOUNT_IN_ADMIN_GROUP marcan a los miembros de grupos privilegiados cuyo propio estado de cuenta ya debería haber bloqueado su acceso, LOCKED_ACCOUNT_ADMIN hace aflorar las cuentas privilegiadas actualmente bloqueadas para el escenario de password spraying descrito arriba, y ADMIN_COUNT_ORPHANED captura el caso inverso —el marcador residual adminCount=1 que queda tras retirar una pertenencia protegida.