> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/cyber-best-practices/es/guias-de-remediacion-de-vulnerabilidades/ad-scan-vulnerability-remediation-guide/privileged-accounts.md).

# 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

```powershell
$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:

```powershell
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):

```powershell
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:

```powershell
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

```powershell
# 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:

```powershell
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

```powershell
$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:

```powershell
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

```powershell
$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

```powershell
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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.stoik.io/cyber-best-practices/es/guias-de-remediacion-de-vulnerabilidades/ad-scan-vulnerability-remediation-guide/privileged-accounts.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
