Persistencia en Active Directory

Tras comprometer el dominio, el objetivo del atacante es no perder el acceso aunque se cambien contraseñas, se reinstalen hosts o se detecte la intrusión inicial. AD ofrece mecanismos de persistencia extraordinariamente potentes porque su confianza se basa en claves criptográficas (krbtgt, claves de servicio, certificados) que rara vez se rotan y que permiten forjar autenticación arbitraria. Un Golden Ticket o una clave de CA robada pueden dar meses de acceso invisible. Por eso, limpiar un dominio comprometido es mucho más difícil que detectar el compromiso.

Modelo de amenaza

La persistencia en AD explota que la autenticación se sostiene en secretos de larga vida. Quien roba la clave krbtgt puede forjar TGTs para cualquier usuario indefinidamente; quien roba la clave de una cuenta de servicio forja tickets para ese servicio; quien roba la clave privada de la CA forja certificados para cualquiera. Ninguno de estos requiere volver a explotar nada: la credencial forjada es válida. Erradicar implica rotar esos secretos, a menudo dos veces.

Red Team

Golden Ticket (krbtgt)

Con el hash de la cuenta krbtgt (de un DCSync), forjas un TGT para cualquier usuario, con cualquier pertenencia a grupos, válido años. Es la persistencia de dominio por excelencia.

# obtener el krbtgt (DCSync)
secretsdump.py dominio/da:pass@<DC> -just-dc-user krbtgt
# forjar e inyectar
ticketer.py -nthash <krbtgt_hash> -domain-sid <SID> -domain dominio.local Administrator
mimikatz # kerberos::golden /user:Administrator /domain:... /sid:... /krbtgt:... /ptt

Silver Ticket (clave de servicio)

Con el hash de una cuenta de servicio/equipo, forjas un TGS directamente para ese servicio (CIFS, HTTP, MSSQL) sin pasar por el DC → sigiloso (no genera tráfico al KDC). Acceso persistente a un servicio concreto.

Diamond / Sapphire Ticket

Variantes más sigilosas: en vez de forjar desde cero (Golden), se modifica un TGT legítimo (Diamond) o se usan PACs de cuentas reales (Sapphire) para evadir detecciones que buscan tickets “imposibles”.

DCSync como persistencia

Conceder a una cuenta controlada derechos de replicación (DS-Replication-Get-Changes) permite volver a volcar hashes (incluido krbtgt) cuando se quiera, sin ser DA. ACL discreta y potente.

DCShadow

Registrar una máquina controlada como un DC falso y replicar cambios maliciosos al directorio (añadir SID history, cambiar membresías, sembrar backdoors) sin dejar los logs normales de modificación. Persistencia sigilosa a nivel de directorio.

AdminSDHolder / ACL backdoors

Modificar la ACL del objeto AdminSDHolder (plantilla de permisos de grupos protegidos): cada hora, SDProp reaplica esos permisos a todos los grupos privilegiados → te concedes acceso permanente que “revive” aunque lo quiten. Igual con ACLs sembradas (GenericAll sobre DA, WriteDacl sobre el dominio para DCSync).

Otros

Certificados (AD CS): robar la clave de la CA → Golden Certificate; o guardar un PFX de cuenta privilegiada (ver AD CS (Active Directory Certificate Services)). Sobrevive a resets de contraseña.
Skeleton Key: parche en memoria del DC que acepta una contraseña maestra para cualquier usuario (volátil).
Cuentas/SPN ocultos, GPO backdoor (Abuso de GPO), Shadow Credentials sembradas (Shadow Credentials).

Herramientas

mimikatz (kerberos::golden, lsadump::dcsync, lsadump::dcshadow, misc::skeleton).
impacket (ticketer.py, secretsdump.py, dacledit.py para ACLs).
Rubeus (golden/silver/diamond), Certipy (golden certificate), PowerView (ACL backdoors).

Impacto

Acceso persistente y a menudo invisible al dominio, resistente a cambios de contraseña y a la limpieza parcial. Es lo que convierte un incidente en un compromiso de largo plazo; su existencia obliga a medidas de erradicación drásticas.

Blue Team

Detección

Golden/Silver tickets: TGT/TGS usados sin AS-REQ previo (4769 sin 4768 correspondiente), lifetimes anómalos (10 años), cifrado RC4, SIDs/grupos imposibles en el PAC.
DCSync desde un principal no-DC (4662 con GUID de replicación) — alta fidelidad.
DCShadow: registro efímero de un nuevo nDC/servidor en la Configuration partition; replicación desde un origen inesperado.
Cambios en AdminSDHolder y en ACLs del dominio (5136); cuentas nuevas en grupos protegidos que reaparecen tras quitarlas.

Telemetría

Auditoría de replicación (4662), de cambios en objetos sensibles (5136 sobre AdminSDHolder/dominio), Kerberos (4768/4769 con tipo de cifrado y correlación AS/TGS), y herramientas específicas (Microsoft Defender for Identity, detección de Golden Ticket/DCShadow).

Hardening y erradicación

Rota krbtgt DOS veces (con intervalo para la replicación) → invalida todos los Golden Tickets existentes. Paso imprescindible tras un compromiso de DC.
Restringe derechos de replicación a los DCs; audita ACLs del dominio y de AdminSDHolder regularmente.
gMSA y contraseñas largas en cuentas de servicio (mitiga Silver Tickets por crack); AES sobre RC4.
Protege la CA (clave en HSM, auditoría) para cortar Golden Certificates; revisa Shadow Credentials.
Tiering/PAW, Protected Users, y monitorización continua con Defender for Identity / detecciones de persistencia.

Respuesta (erradicación completa)

Tras compromiso de dominio: rota krbtgt ×2, resetea todas las cuentas privilegiadas y de servicio, revisa AdminSDHolder y ACLs, reemite/revoca certificados si la CA cayó, elimina cuentas/SPN/GPO/Shadow Creds sembrados, y reconstruye los DCs si hubo DCShadow/Skeleton Key. Asume que una persistencia no detectada reabre todo.

CVEs y casos reales

Golden Ticket, DCSync, DCShadow, Skeleton Key son TTPs de mimikatz (MITRE T1558.001 Golden, T1558.002 Silver, T1003.006 DCSync, T1207 DCShadow, T1098 account manipulation).
APT29, APT28, FIN6, grupos de ransomware emplean Golden Tickets y DCSync para persistir tras el compromiso inicial.
La rotación doble de krbtgt es guía oficial de Microsoft tras un incidente de AD precisamente por los Golden Tickets.

Checklist de prueba

Golden Ticket con el hash de krbtgt (forja + ptt)
Silver Ticket con clave de servicio/equipo (sigiloso)
Diamond/Sapphire para evadir detección de tickets forjados
DCSync rights concedidos a una cuenta controlada
DCShadow para sembrar cambios sin logs normales
AdminSDHolder / ACL backdoors (DCSync, GenericAll sobre DA)
Golden Certificate (clave de CA) / Shadow Credentials sembradas
Blue: ¿se rotó krbtgt ×2 y se auditan replicación/AdminSDHolder?