Honeytokens en AD: cuentas trampa, SPN señuelo y señuelos

La mayoría de las detecciones de AD son estadísticas: muchas solicitudes 4769 con RC4, más inicios de sesión fallidos de lo habitual, un cambio de grupo a una hora inusual. Necesitan ajuste y producen falsos positivos que acostumbran a los analistas a ignorarlas. El engaño invierte ese modelo. Se colocan objetos que ningún usuario, servicio o script legítimo toca jamás, y cualquier interacción con ellos se trata como un incidente. Un honeytoken bien colocado convierte el Kerberoasting, el AS-REP roasting, el password spraying y el reconocimiento LDAP en señales prácticamente seguras.

Esta guía construye cinco señuelos: una cuenta de administrador trampa, un SPN señuelo, un señuelo vulnerable a AS-REP roasting, una contraseña falsa de Group Policy Preferences y un objeto señuelo con auditoría de lectura. Después trata las alertas, la verificación y qué excluir para que sus propias herramientas no los activen. Da por hecho que ya existe la base de directiva de auditoría y SACL descrita en la guía pilar de auditoría y detección.

Principios de diseño

Un señuelo solo funciona si es atractivo, inerte y supervisado:

• Atractivo. Aparece en la enumeración que los atacantes ya ejecutan: recopilación de BloodHound, listado de SPN, consultas adminCount=1, búsquedas en SYSVOL. Los nombres, las descripciones y las fechas deben encajar con su convención de nomenclatura. svc-sql-backup funciona. honeypot01, no.
• Inerte. No concede nada. Sin pertenencias reales a grupos con derechos, sin delegación, sin derechos de inicio de sesión y con una contraseña de 64 o más caracteres aleatorios que no se registra en ningún sitio.
• Supervisado. Cada señuelo tiene una regla de detección que se ha probado de extremo a extremo antes de confiar en ella.

Mantenga un registro de señuelos, con nombre, SID, finalidad, ID de regla y responsable, fuera de AD, en la documentación de su SOC. Cuantas menos personas sepan qué cuentas son señuelos, mejor. Eso incluye a la mayoría de los administradores del dominio.

Medir: lo que ven hoy los atacantes

Examine su dominio como lo hacen las herramientas de reconocimiento, para que los señuelos encajen en el paisaje:

# SPN de usuario existentes (lo que enumera una herramienta de Kerberoasting)
Get-ADUser -Filter 'servicePrincipalName -like "*"' -Properties servicePrincipalName, pwdLastSet, description |
  Select-Object SamAccountName, @{n='SPN';e={$_.servicePrincipalName -join ';'}},
    @{n='PwdLastSet';e={[datetime]::FromFileTime($_.pwdLastSet)}}, Description

# Cuentas marcadas con adminCount=1 (lo que enumeran las consultas de «cuentas privilegiadas»)
Get-ADUser -LDAPFilter '(adminCount=1)' | Select-Object SamAccountName, DistinguishedName

Replique la nomenclatura, la ubicación en OU y el estilo de las descripciones que encuentre. Las cuentas reales vulnerables a Kerberoasting deben corregirse, no limitarse a rodearlas de señuelos. Consulte la defensa frente a Kerberoasting.

Construir los señuelos

Cree todos los señuelos en una OU de aspecto normal, no en una OU dedicada llamada «Decoys». Aplique Deny log on locally, Deny log on through Remote Desktop Services y Deny access to this computer from the network a un grupo que los contenga. Configúrelos mediante una GPO en Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

Cuenta de administrador trampa

Un señuelo que parece un administrador olvidado:

# Windows PowerShell 5.1: System.Web está disponible en .NET Framework
Add-Type -AssemblyName System.Web
function New-DecoyPassword {
  ConvertTo-SecureString ([System.Web.Security.Membership]::GeneratePassword(64,10)) -AsPlainText -Force
}
New-ADUser -Name 'adm-jmorel' -SamAccountName 'adm-jmorel' -Path 'OU=Admins,OU=Corp,DC=corp,DC=example,DC=com' `
  -Description 'Infra admin - legacy' -AccountPassword (New-DecoyPassword) -Enabled $true -AccountNotDelegated $true

Inclúyala en un grupo con nombre de grupo de administración que no tenga derechos, o asígnele adminCount=1 para que aparezca en las consultas de cuentas «privilegiadas». No la agregue a Domain Admins ni a ningún grupo real de Tier 0: eso convertiría el señuelo en una cuenta real de Tier 0.

SPN señuelo

Asocie un SPN verosímil a una cuenta de servicio señuelo. Cualquier 4769 para ese SPN significa que alguien solicita un ticket para un servicio que no existe:

New-ADUser -Name 'svc-sqlrpt' -SamAccountName 'svc-sqlrpt' -Path 'OU=Service Accounts,OU=Corp,DC=corp,DC=example,DC=com' `
  -AccountPassword (New-DecoyPassword) -Enabled $true -Description 'SQL Reporting Services'
Set-ADUser 'svc-sqlrpt' -ServicePrincipalNames @{ Add = 'MSSQLSvc/sqlrpt01.corp.example.com:1433' }

Asegúrese de que no existe ningún registro DNS ni ningún host llamado sqlrpt01, para que ningún cliente intente llegar a él por accidente.

Señuelo vulnerable a AS-REP roasting

El AS-REP roasting se dirige a las cuentas que tienen activada la opción Do not require Kerberos preauthentication. Un señuelo con este indicador genera un 4768 con PreAuthType 0 cuando alguien lo ataca:

New-ADUser -Name 'svc-scanlegacy' -SamAccountName 'svc-scanlegacy' -Path 'OU=Service Accounts,OU=Corp,DC=corp,DC=example,DC=com' `
  -AccountPassword (New-DecoyPassword) -Enabled $true -Description 'Legacy scanner (Unix)'
Set-ADAccountControl -Identity 'svc-scanlegacy' -DoesNotRequirePreAuth $true

Con una contraseña aleatoria de 64 caracteres, el hash obtenido no sirve de nada sin conexión. La propia solicitud es la alerta.

Contraseña GPP falsa

Los atacantes siguen buscando valores cpassword en SYSVOL. Lo primero es eliminar las contraseñas GPP reales. Después, un Groups.xml señuelo en una GPO sin vincular, cuyo cpassword se descifra como una contraseña creíble pero incorrecta de la cuenta de administrador trampa, le proporciona dos puntos de alerta:

1. Evento 5145 (Audit Detailed File Share) para el acceso a esa ruta concreta de Groups.xml en el recurso compartido SYSVOL, si puede asumir el volumen en los DC.
2. 4771, 4776 o 4625 cuando el atacante prueba la contraseña descifrada contra la cuenta señuelo.

Use una GPO que no esté vinculada en ningún sitio, para que ningún cliente la procese nunca. No reutilice un patrón de contraseña de su entorno real.

Objeto señuelo con auditoría de lectura

El reconocimiento LDAP, como BloodHound o ADExplorer, lee todos los objetos. Una SACL que audite las lecturas de un objeto señuelo convierte ese barrido en un 4662:

$dn   = 'CN=adm-jmorel,OU=Admins,OU=Corp,DC=corp,DC=example,DC=com'
$acl  = Get-Acl "AD:\$dn"
$rule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    [System.Security.Principal.SecurityIdentifier]'S-1-1-0',
    [System.DirectoryServices.ActiveDirectoryRights]'ReadProperty',
    [System.Security.AccessControl.AuditFlags]'Success')
$acl.AddAuditRule($rule)
Set-Acl -Path "AD:\$dn" -AclObject $acl

Esto requiere DS Access > Audit Directory Service Access (Success) en los controladores de dominio. Limite la SACL a este único objeto: auditar lecturas en cualquier objeto con mucha actividad inunda el registro. Para entender cómo leer este tipo de grafo de ataque desde el lado defensivo, consulte la gestión de rutas de ataque.

Ubicación y ciclo de vida

Los señuelos envejecen como las cuentas reales. Una cuenta de servicio cuyo pwdLastSet es de hoy y que nunca ha iniciado sesión parece colocada a propósito. Cree los señuelos y déjelos reposar unas semanas antes de confiar en ellos. Escalone sus fechas de creación y evite crearlos todos en un único cambio que aparezca en la misma ráfaga de eventos 4720.

Distribuya los señuelos por los lugares en los que miran los atacantes: al menos uno en cada dominio del bosque, uno en la OU donde residen sus administradores reales y uno entre las cuentas de servicio. En entornos grandes, un señuelo por cada OU de las principales unidades de negocio le ayuda a saber de qué parte de la red procedía el reconocimiento, porque el campo IpAddress de los eventos 4768 y 4769 muestra el host de origen.

Revise los señuelos dos veces al año. Confirme que siguen existiendo, que conservan sus SACL y SPN y que siguen activando sus reglas. Un proyecto de limpieza de objetos que elimine sus señuelos es una forma silenciosa de perder cobertura.

Aplicar: reglas de alerta

Escriba una regla por señuelo, basada en el SID cuando el evento lo incluya y en el nombre en caso contrario:

Una comprobación local para pruebas, o para entornos pequeños sin SIEM:

$decoys = 'adm-jmorel','svc-sqlrpt','svc-scanlegacy'
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4768,4769,4771,4776; StartTime=(Get-Date).AddHours(-1) } |
  Where-Object {
    $d = ([xml]$_.ToXml()).Event.EventData.Data
    ($d | Where-Object { $_.Name -in 'TargetUserName','ServiceName' }).'#text' | Where-Object { $_ -in $decoys }
  } | Select-Object TimeCreated, Id, MachineName

Envíe estas alertas a la guardia, no a una cola de revisión diaria. Si utiliza Microsoft Defender for Identity, etiquete además cada señuelo como honeytoken en Settings > Identities > Entity tags > Honeytoken, para que el sensor genere su propia alerta aunque su regla del SIEM falle. La entrada del glosario sobre honeytoken resume el concepto para las partes interesadas.

Las cuentas trampa solo son tan buenas como la cobertura de eventos que tienen detrás. Todas las reglas anteriores dependen de que los eventos de todos los DC lleguen al SIEM, que es lo que proporciona Windows Event Forwarding.

Verificar

Pruebe cada señuelo desde una estación de trabajo normal unida al dominio, como usuario estándar, tras abrir un ticket de cambio. Avise antes al SOC o hágalo como un ejercicio de purple team planificado:

# SPN señuelo: solicite un ticket de servicio y confirme que llegó un 4769 al SIEM
Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList 'MSSQLSvc/sqlrpt01.corp.example.com:1433'
klist

# Administrador trampa: un inicio de sesión Kerberos fallido genera un 4771 en el DC
runas /user:CORP\adm-jmorel cmd.exe   # introduzca una contraseña incorrecta

Para el objeto con auditoría de lectura, ábralo en Usuarios y equipos de Active Directory con el Editor de atributos y confirme que se genera un 4662 con su usuario como SubjectUserName. Anote la latencia de extremo a extremo, desde la acción hasta el aviso, de cada señuelo. Repita la prueba cada trimestre y después de cualquier cambio en el SIEM o en el recopilador.

Qué se rompe

Los señuelos no cambian el comportamiento de producción, pero chocan con herramientas legítimas que leen o tocan todos los objetos:

• Entra Connect y otros motores de sincronización leen todos los objetos de su ámbito. Mantenga los señuelos con auditoría de lectura en una OU fuera del ámbito de sincronización, o excluya la cuenta de sincronización de la regla del 4662 por su SID.
• Las herramientas de evaluación e inventario (PingCastle, la recopilación de BloodHound que ejecuta su propio equipo, los conectores de la CMDB, los sensores de Defender for Identity) activan las SACL de lectura y pueden solicitar tickets de servicio. Excluya explícitamente sus cuentas de servicio y documente la exclusión, sabiendo que los atacantes pueden intentar esconderse detrás de esas mismas cuentas.
• La protección contra password spraying y el bloqueo de cuentas. Que un señuelo se bloquee por la actividad de un atacante no es un problema, pero asegúrese de que ninguna automatización del servicio de asistencia lo desbloquea o restablece su contraseña.
• Los scripts de limpieza de cuentas que deshabilitan las cuentas inactivas durante 90 días deshabilitarán sus señuelos. Exclúyalos por SID en el script, no mediante un patrón de nombres que un atacante pueda aprender.
• Los auditores y los pentesters los activarán. Es una ventaja, pero acuerde con ellos el proceso de respuesta antes del encargo.

Lecturas relacionadas: la referencia de ID de evento de seguridad de AD explica cada campo utilizado arriba, la defensa frente a Kerberoasting elimina las cuentas realmente vulnerables entre las que se sitúan los señuelos, y el área de auditoría, registro y detección enumera el resto de la serie.