Cuentas privilegiadas

P-Kerberoasting

Qué significa

En Active Directory, algunas cuentas están registradas para ejecutar servicios como un SQL Server o una aplicación web. Estas cuentas tienen un Nombre principal de servicio (SPN), que es esencialmente una etiqueta que dice "esta cuenta ejecuta un servicio de red".

El riesgo de seguridad es: cualquier usuario autenticado del dominio puede solicitar un ticket de Kerberos para cualquier cuenta con un SPN. Ese ticket está cifrado con la contraseña de la cuenta, y el atacante puede intentar descifrarlo sin conexión, sin activar ninguna alerta.

Esto se llama un Kerberoasting ataque. Es especialmente peligroso cuando la cuenta con el SPN también es un Administrador de dominio, porque descifrar esa contraseña significa control total del dominio.

Qué comprueba el análisis

El análisis de AD marca las cuentas que cumplen las tres condiciones:

1. La cuenta es miembro de un grupo privilegiado (Administradores de dominio, Administradores empresariales, etc.)

2. La cuenta tiene un Nombre principal de servicio (SPN)

3. La contraseña de la cuenta no ha sido cambiada en más de 40 días (dando a los atacantes más tiempo para descifrarla)

Por qué la alerta puede persistir

Debes abordar las tres condiciones. Soluciones incompletas comunes:

• Cambió la contraseña pero conservó el SPN: La alerta desaparece temporalmente, pero vuelve después de 40 días.

• Se quitó el SPN pero la cuenta sigue en Administradores de dominio: La alerta desaparece, pero el riesgo subyacente permanece.

Cómo diagnosticar

$privilegedGroups = @("Administradores de dominio", "Administradores empresariales", "Administradores de esquema", "Administradores")
$threshold = (Get-Date).AddDays(-40)

foreach ($group in $privilegedGroups) {
  Get-ADGroupMember -Identity $group -Recursive |
    Where-Object { $_.objectClass -eq "user" } |
    ForEach-Object { Get-ADUser $_ -Properties ServicePrincipalName, PasswordLastSet } |
    Where-Object { $_.ServicePrincipalName.Count -gt 0 -and $_.PasswordLastSet -lt $threshold } |
    Select-Object SamAccountName,
      @{N="Edad de la contraseña (días)"; E={[math]::Round(((Get-Date) - $_.PasswordLastSet).TotalDays)}},
      @{N="SPN"; E={$_.ServicePrincipalName -join "; "}}
}

Cómo corregir

Mejor opción: elimina la cuenta de los grupos privilegiados. Las cuentas de servicio rara vez necesitan ser Administradores de dominio. Crea una cuenta dedicada, sin privilegios, con solo los permisos que el servicio realmente necesita:

Remove-ADGroupMember -Identity "Administradores de dominio" -Members "svc_account" -Confirm:$false

Si no puedes quitarla del grupo de administradores: Como mínimo, restablece la contraseña con regularidad (cada 30 días o menos):

Set-ADAccountPassword -Identity "svc_account" `
  -NewPassword (ConvertTo-SecureString "YourNewStr0ngP@ssw0rd!" -AsPlainText -Force) -Reset

Mejor solución a largo plazo: Convierte a una Cuenta de servicio administrada por grupo (gMSA), que rota su contraseña automáticamente cada 30 días:

New-ADServiceAccount -Name "gMSA_SQLService" `
  -DNSHostName "gmsa_sqlservice.yourdomain.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "SQLServersGroup"

P-AdminLogin

Qué significa

Todos los dominios de Active Directory tienen una cuenta de Administrador integrada que se crea automáticamente cuando se configura el dominio. Esta cuenta tiene control total sobre todo el dominio y no puede bloquearse.

Debido a su poder y previsibilidad (los atacantes saben que siempre existe), debe reservarse para solo emergencias, como la recuperación tras un desastre. La administración diaria debe usar cuentas de administrador personales (por ejemplo, adm_john) para que las acciones puedan atribuirse a personas concretas.

Qué comprueba el análisis

El análisis de AD comprueba si la cuenta de Administrador integrada ha iniciado sesión en algún controlador de dominio en los últimos 35 días. Si lo ha hecho, se activa la alerta, indicando que la cuenta se está usando para tareas rutinarias en lugar de reservarse para emergencias.

Por qué la alerta puede persistir

• Cambiar el nombre de la cuenta no ayuda. El análisis identifica al Administrador integrado por su identificador interno (RID-500), no por su nombre.

• Cambiar la contraseña no ayuda. El análisis comprueba la actividad de inicio de sesión, no la antigüedad de la contraseña.

• Los scripts automatizados o las tareas programadas que se ejecutan como Administrador integrado seguirán activando la alerta.

• Solo tienes que esperar. Después de que dejes de usar la cuenta, la alerta se limpia automáticamente al cabo de 35 días.

Cómo diagnosticar

# Comprueba cuándo inició sesión por última vez el Administrador integrado en cada DC
$domainSID = (Get-ADDomain).DomainSID
$adminSID = "$domainSID-500"

Get-ADDomainController -Filter * | ForEach-Object {
  $dc = $_
  $admin = Get-ADUser -Identity $adminSID -Server $dc.HostName -Properties LastLogon
  $lastLogon = [DateTime]::FromFileTime($admin.LastLogon)
  $daysAgo = [math]::Round(((Get-Date) - $lastLogon).TotalDays, 1)

  [PSCustomObject]@{
    DC        = $dc.HostName
    LastLogon = $lastLogon
    DaysAgo   = $daysAgo
    Status    = if ($daysAgo -le 35) { "ALERTA - Usado recientemente" } else { "OK" }
  }
} | Format-Table -AutoSize

También comprueba si hay tareas programadas que puedan estar usando el Administrador integrado:

Get-ADDomainController -Filter * | ForEach-Object {
  Invoke-Command -ComputerName $_.HostName -ScriptBlock {
    Get-ScheduledTask | Where-Object {
      $_.Principal.UserId -match "Administrador"
    } | Select-Object TaskName, @{N="RunAs"; E={$_.Principal.UserId}}
  }
}

Cómo corregir

1. Crea cuentas de administrador personales para cada administrador (por ejemplo, adm_john, adm_jane)

2. Actualiza cualquier tarea programada para que use una cuenta de servicio dedicada en lugar del Administrador integrado

3. Deja de iniciar sesión con el Administrador integrado para las tareas rutinarias

4. La alerta se limpiará automáticamente 35 días después del último inicio de sesión

P-AdminNum

Qué significa

Cuantas más cuentas con privilegios de administrador haya en tu dominio, mayor será la superficie de ataque. Cada cuenta de administrador es un posible punto de entrada para un atacante. Con el tiempo, muchas organizaciones terminan teniendo demasiadas cuentas de administrador: acceso temporal que nunca se revocó, cuentas de servicio agregadas a Administradores de dominio por conveniencia, etc.

Qué comprueba el análisis

El análisis de AD cuenta el número total de usuarios únicos en todos los grupos privilegiados (Administradores de dominio, Administradores empresariales, Administradores, Operadores de cuentas, Operadores de servidores, Operadores de copias de seguridad, etc.). Si el mismo usuario está en varios grupos, solo se cuenta una vez.

La alerta se activa si:

• Más de 10% de los usuarios activos son privilegiados, O

• Más de 50 existen cuentas privilegiadas

Esta comprobación se omite para organizaciones pequeñas con menos de 100 usuarios activos.

Cómo diagnosticar

$privilegedGroups = @(
  "Administradores de dominio", "Administradores empresariales", "Administradores de esquema", "Administradores",
  "Operadores de cuentas", "Operadores de servidores", "Operadores de copias de seguridad", "Operadores de impresión"
)

$uniqueMembers = @{}
foreach ($group in $privilegedGroups) {
  try {
    Get-ADGroupMember -Identity $group -Recursive |
      Where-Object { $_.objectClass -eq "user" } |
      ForEach-Object { $uniqueMembers[$_.DistinguishedName] = $_.SamAccountName }
  } catch {}
}

$activeUsers = (Get-ADUser -Filter "Enabled -eq `$true" | Measure-Object).Count
$pct = [math]::Round(($uniqueMembers.Count / $activeUsers) * 100, 1)

Write-Host "Cuentas privilegiadas: $($uniqueMembers.Count)"
Write-Host "Usuarios activos: $activeUsers"
Write-Host "Proporción: $pct% (alerta si >10% o >50 cuentas)"
Write-Host ""
$uniqueMembers.Values | Sort-Object | ForEach-Object { Write-Host "  - $_" }

Cómo corregir

Revisa la lista y elimina las cuentas que realmente no necesiten acceso de administrador:

Remove-ADGroupMember -Identity "Administradores de dominio" -Members "username" -Confirm:$false

Buenas prácticas:

• Usa cuentas de administrador separadas (adm_john) que sean diferentes de las cuentas de uso diario

• Elimina las cuentas de servicio de los grupos de administradores, otorgando solo los permisos específicos que necesiten

• Revisa la pertenencia a grupos privilegiados de forma periódica

P-ProtectedUsers

Qué significa

El grupo de Usuarios protegidos es un grupo de seguridad especial introducido en Windows Server 2012 R2. Los miembros de este grupo obtienen protecciones adicionales:

• Pueden autenticarse solo con Kerberos (el protocolo más seguro), no con el protocolo NTLM más antiguo

• Sus credenciales no se almacenan en caché en las máquinas en las que inician sesión: un atacante que comprometa una estación de trabajo no puede robar sus credenciales de la memoria

• La delegación está deshabilitada: su cuenta no puede ser suplantada por servicios

Estas protecciones son críticas para las cuentas de administrador, que son los principales objetivos en la mayoría de los ataques.

Qué comprueba el análisis

El análisis de AD verifica que todas las cuentas de administrador habilitadas (miembros de Administradores de dominio, Administradores empresariales, etc.) también sean miembros del grupo de Usuarios protegidos grupo.

Por qué la alerta puede persistir

• Los usuarios agregados mediante grupos anidados pueden no detectarse. Agrega a los usuarios directamente al grupo Usuarios protegidos.

• Los retrasos de replicación entre controladores de dominio pueden causar inconsistencias temporales.

• Las cuentas de servicio administradas (gMSA) se excluyen de esta comprobación: no necesitan estar en Usuarios protegidos.

Cómo diagnosticar

$protectedUsers = (Get-ADGroupMember -Identity "Usuarios protegidos").DistinguishedName
$privilegedGroups = @("Administradores de dominio", "Administradores empresariales", "Administradores de esquema", "Administradores")

$notProtected = foreach ($group in $privilegedGroups) {
  Get-ADGroupMember -Identity $group -Recursive |
    Where-Object { $_.objectClass -eq "user" } |
    ForEach-Object { Get-ADUser $_ -Properties Enabled } |
    Where-Object { $_.Enabled -and $_.DistinguishedName -notin $protectedUsers }
}

$notProtected | Select-Object -Unique SamAccountName, Name | Format-Table -AutoSize

Cómo corregir

Add-ADGroupMember -Identity "Usuarios protegidos" -Members "adm_john", "adm_jane"

Importante: Agregar cuentas a Usuarios protegidos aplica autenticación solo Kerberos. Algunas aplicaciones heredadas que requieren NTLM pueden dejar de funcionar para estas cuentas. Prueba primero con una cuenta antes de agregar a todos los administradores.

Mejor práctica: las cuentas de administrador deben usarse solo para tareas de administración (no para correo, navegación web o ejecución de aplicaciones empresariales), por lo que la compatibilidad con NTLM rara vez es un problema.