Cisco Data Breach: anatomia de un credential dump en Active Directory
Analisis tecnico del credential dump filtrado por Kraken ransomware contra Cisco: tecnicas de extraccion NTLM, riesgos de Pass-the-Hash y Golden Ticket, y medidas de deteccion y mitigacion para proteger Active Directory.
Un credential dump que expone los riesgos de Active Directory
TL;DR: En febrero de 2025, el grupo ransomware Kraken publico un dataset con credenciales extraidas del Active Directory de Cisco: usernames, SIDs, RIDs y hashes NTLM, incluyendo cuentas criticas como Administrator:500 y krbtgt. Aunque Cisco afirma que los datos provienen de un incidente de 2022 ya remediado, el caso es un ejemplo perfecto para analizar las tecnicas de credential dumping, sus riesgos reales y las defensas disponibles.
El 10 de febrero de 2025, el grupo de ransomware Kraken publico en su blog de la dark web un conjunto de datos que afirmaban haber extraido de la red interna de Cisco Systems. El dataset contenia credenciales del entorno Windows Active Directory de la compania.
Cisco respondio confirmando que los datos existen pero que corresponden a un incidente de seguridad de mayo de 2022, completamente remediado en su momento y sin impacto actual en clientes.
Independientemente de la cronologia, el caso ofrece una oportunidad para analizar en profundidad como funcionan los ataques de credential dumping contra Active Directory y por que siguen siendo una de las tecnicas mas efectivas en el arsenal de los atacantes.
Que datos se filtraron
El dataset publicado por Kraken contiene tres tipos de informacion:
Usernames y dominios. Identificadores de usuarios individuales y sus dominios AD asociados. Esta informacion permite mapear la estructura organizativa del entorno comprometido.
RIDs (Relative Identifiers). Numeros unicos asignados a cada cuenta dentro del dominio. El RID 500 corresponde siempre a la cuenta Administrator integrada, y el RID 502 a la cuenta krbtgt. La presencia de estas cuentas en la filtracion indica acceso al controlador de dominio.
Hashes NTLM. Representaciones hash de las contrasenas de los usuarios. NTLM (NT LAN Manager) es un protocolo de autenticacion de Microsoft que, pese a estar obsoleto, sigue presente por compatibilidad retroactiva en la mayoria de entornos Windows.
Tecnicas de extraccion: como se obtienen las credenciales
La estructura de los datos filtrados apunta al uso de herramientas de credential dumping. Estas son las tecnicas mas probables:
Mimikatz y LSASS
Mimikatz es la herramienta de referencia para la extraccion de credenciales en Windows. Funciona accediendo a la memoria del proceso LSASS (Local Security Authority Subsystem Service), que mantiene en memoria las credenciales de los usuarios autenticados.
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords
Este comando extrae contrasenas en texto plano (si estan disponibles), hashes NTLM y tickets Kerberos de todos los usuarios con sesion activa. Requiere privilegios de administrador local o SYSTEM.
Tecnica MITRE ATT&CK
El credential dumping esta documentado en MITRE ATT&CK como:
- T1003.001 — OS Credential Dumping: LSASS Memory
- T1003.002 — OS Credential Dumping: Security Account Manager (SAM)
- T1003.003 — OS Credential Dumping: NTDS (controladores de dominio)
- T1003.006 — OS Credential Dumping: DCSync
Extraccion de NTDS.dit
En un controlador de dominio, la base de datos NTDS.dit contiene los hashes de todas las cuentas del dominio. Se puede extraer mediante:
Volume Shadow Copy:
vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\ntds.dit C:\ntds.dit
Secretsdump (Impacket):
secretsdump.py -just-dc DOMINIO/[email protected]
DCSync: Usando el protocolo de replicacion de directorio (MS-DRSR) para solicitar hashes sin acceder fisicamente al controlador de dominio.
SAM database
En equipos locales (no controladores de dominio), la base de datos SAM almacena los hashes de las cuentas locales. Herramientas como pwdump, hashdump (Metasploit) o reg save permiten su extraccion:
reg save HKLM\SAM sam.hiv
reg save HKLM\SYSTEM system.hiv
Explotacion de hashes NTLM
La posesion de hashes NTLM habilita dos vectores de ataque principales:
Pass-the-Hash (PtH)
El atacante usa el hash directamente para autenticarse, sin necesidad de crackear la contrasena. Funciona porque el protocolo NTLM utiliza el hash como base de autenticacion, no la contrasena en texto plano.
# Con Impacket
psexec.py -hashes :aad3b435b51404eeaad3b435b51404ee:hash DOMINIO/usuario@objetivo
# Con CrackMapExec
crackmapexec smb 10.0.0.0/24 -u administrador -H hash --exec-method smbexec
Este tipo de ataque es especialmente peligroso porque no deja el mismo rastro que un login convencional y funciona incluso si la contrasena ha sido cambiada pero el hash no ha sido invalidado en todas las sesiones activas.
Cracking offline
Los hashes NTLM pueden ser crackeados offline con herramientas como Hashcat o John the Ripper. NTLM usa MD4 sin salt, lo que lo hace vulnerable a ataques de fuerza bruta y diccionario a velocidades extremas.
# Hashcat mode 1000 = NTLM
hashcat -m 1000 -a 0 hashes.txt rockyou.txt
Con hardware moderno (GPU), se pueden probar billones de combinaciones por segundo contra hashes NTLM, lo que hace que contrasenas debiles sean crackeables en segundos.
El riesgo critico: compromiso de krbtgt
La presencia de la cuenta krbtgt en la filtracion de Cisco es el dato mas preocupante. Esta cuenta es la que firma todos los tickets Kerberos TGT (Ticket Granting Ticket) del dominio.
Golden Ticket
Si un atacante posee el hash de krbtgt, puede crear Golden Tickets: tickets TGT falsificados que le permiten suplantar cualquier usuario del dominio, incluidos administradores de dominio.
mimikatz # kerberos::golden /user:administrador /domain:DOMINIO.LOCAL /sid:S-1-5-21-... /krbtgt:hash /ticket:golden.kirbi
Un Golden Ticket:
- Permite acceso como cualquier usuario del dominio
- Tiene una validez que el atacante controla (puede ser de anos)
- Sobrevive a cambios de contrasena de usuarios normales
- Solo se invalida rotando la contrasena de krbtgt dos veces consecutivas
Silver Ticket
Con hashes de cuentas de servicio, el atacante puede crear Silver Tickets para acceder a servicios especificos (SQL Server, Exchange, file shares) sin pasar por el KDC (Key Distribution Center).
Deteccion de credential dumping
Eventos Windows
La monitorizacion de eventos Windows es la primera linea de deteccion:
| Event ID | Descripcion | Relevancia |
|---|---|---|
| 4624 | Logon exitoso (tipo 9 = NewCredentials) | PtH detection |
| 4672 | Privilegios especiales asignados | Escalada de privilegios |
| 4648 | Logon con credenciales explicitas | Movimiento lateral |
| 4662 | Operacion sobre objeto AD | DCSync detection |
| 4688 | Creacion de proceso | Ejecucion de herramientas |
Sysmon
Sysmon Event ID 10 (ProcessAccess) detecta accesos al proceso LSASS:
<RuleGroup groupRelation="or">
<ProcessAccess onmatch="include">
<TargetImage condition="is">C:\Windows\System32\lsass.exe</TargetImage>
<GrantedAccess condition="is">0x1010</GrantedAccess>
</ProcessAccess>
</RuleGroup>
Reglas Sigma
title: LSASS Memory Access - Possible Credential Dumping
id: 0d894093-71bc-43c3-8985-4513b67d0e6a
status: stable
logsource:
category: process_access
product: windows
detection:
selection:
TargetImage|endswith: '\lsass.exe'
GrantedAccess|contains:
- '0x1010'
- '0x1038'
- '0x1fffff'
condition: selection
level: high
tags:
- attack.credential_access
- attack.t1003.001
Deteccion en Linux con eBPF (Tetragon)
Para entornos Linux o contenedores, herramientas basadas en eBPF como Tetragon (Cilium/Isovalent) permiten monitorizar a nivel de kernel:
- Accesos a
/proc/*/mem(patron de dump de procesos) - Lectura de ficheros sensibles (shadow, SAM equivalents)
- Ejecucion de binarios conocidos de credential dumping
- Syscalls de ptrace (usado por debuggers y dumpers)
Tetragon opera con overhead minimo al ejecutar los filtros directamente en el kernel via programas eBPF, sin copiar eventos al espacio de usuario hasta que coinciden con una politica de deteccion.
Mitigacion y hardening de Active Directory
Acciones inmediatas tras un credential dump
-
Rotacion de contrasenas. Forzar cambio inmediato en todas las cuentas potencialmente afectadas, empezando por las privilegiadas.
-
Doble rotacion de krbtgt. Rotar la contrasena de krbtgt dos veces con un intervalo de al menos 12 horas entre rotaciones. Esto invalida todos los Golden Tickets existentes.
-
Revocar sesiones activas. Invalidar todos los tickets Kerberos y tokens de sesion activos.
-
Auditar accesos. Revisar logs de los ultimos 90 dias buscando indicadores de Pass-the-Hash y movimiento lateral.
Hardening a medio plazo
Deshabilitar NTLM. Migrar a Kerberos como unico protocolo de autenticacion. NTLM deberia restringirse progresivamente hasta eliminarlo:
# Group Policy: Network security: Restrict NTLM
# Configurar a "Deny all accounts" cuando sea posible
Credential Guard. Windows Credential Guard aísla las credenciales en un contenedor virtualizado (VSM) que impide el acceso directo a LSASS, incluso con privilegios de SYSTEM.
LAPS (Local Administrator Password Solution). Implementar LAPS para que cada equipo tenga una contrasena de administrador local unica y rotada automaticamente, eliminando el riesgo de PtH con una sola credencial de admin local.
Tiering de privilegios. Separar las cuentas administrativas en tiers (T0 para domain controllers, T1 para servidores, T2 para workstations). Ningun administrador deberia usar las mismas credenciales en multiples tiers.
MFA para accesos privilegiados. Implementar autenticacion multifactor obligatoria para todas las cuentas con privilegios administrativos.
PAWs (Privileged Access Workstations). Usar estaciones de trabajo dedicadas y aisladas para la administracion de infraestructura critica.
Contexto de la respuesta de Cisco
Cisco afirma que los datos publicados por Kraken corresponden a un incidente de seguridad de mayo de 2022, completamente resuelto en su momento. La compania indica que no ha habido impacto en clientes y que el incidente fue remediado.
Sin embargo, la reaparicion de estos datos en 2025 plantea preguntas relevantes:
- Si las credenciales fueron rotadas correctamente tras el incidente original, los hashes filtrados deberian ser inutiles.
- La publicacion por un grupo ransomware diferente al que origino el compromiso sugiere que los datos circularon en mercados underground durante casi tres anos.
- Esto refuerza la importancia de asumir que cualquier dato exfiltrado sera eventualmente publicado, independientemente del tiempo transcurrido.
Lecciones para equipos de seguridad
Este caso ilustra varios principios fundamentales de la seguridad de Active Directory:
NTLM es un riesgo aceptado, no una necesidad. La mayoria de entornos lo mantienen por compatibilidad, pero cada dia que NTLM permanece habilitado es un dia mas de exposicion a PtH.
krbtgt es la joya de la corona. Si un atacante obtiene el hash de krbtgt, tiene las llaves del reino. La rotacion periodica de esta cuenta deberia ser un procedimiento operativo estandar, no una respuesta a incidentes.
Los datos exfiltrados no caducan. Tres anos despues de un incidente, las credenciales reaparecieron publicadas. La respuesta a un compromiso debe asumir el peor escenario temporal.
La deteccion temprana es posible. Las tecnicas de credential dumping generan artefactos detectables. La combinacion de eventos Windows, Sysmon, reglas Sigma y herramientas eBPF como Tetragon proporciona multiples capas de deteccion que pueden identificar el ataque antes de que las credenciales sean exfiltradas.
Preguntas frecuentes
Artículos relacionados
Pirámide del Dolor: Por Qué los TTPs Valen Más que los IOCs
Cyber Kill Chain vs MITRE ATT&CK: Cuándo Usar Cada Uno
Tracking Campaigns: De IOCs Aislados a Clusters de Actividad
Ransomware Forensics: Investigacion y Recuperacion
Plan de Respuesta a Incidentes segun NIST SP 800-61
Windows Forensics: Artefactos Clave para Investigaciones
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.