Qué es Mimikatz: credential dumping, técnicas y detección en 2026

Mimikatz es una herramienta open-source de post-explotación creada por Benjamin Delpy en 2007, diseñada para extraer credenciales (contraseñas, hashes NTLM y tickets Kerberos) directamente de la memoria del proceso LSASS en sistemas Windows. Desde su publicación se ha convertido en pivote estándar de cualquier operación red team contra Active Directory y, a la vez, en una de las piezas más vistas en intrusiones reales investigadas en los últimos diez años.

Esta guía cubre qué hace Mimikatz por dentro, los módulos que aparecen una y otra vez en informes de post-explotación (sekurlsa, lsadump, kerberos, crypto), cómo encaja en operaciones de red team autorizadas, cómo se detecta desde un EDR o un SIEM moderno y qué controles realmente reducen el impacto cuando un atacante llega al endpoint. Está orientada a equipos azules, equipos rojos y responsables de seguridad que necesitan entender la huella de Mimikatz sin lecturas marketinianas.

Lo esencial sobre Mimikatz

• Es la herramienta de referencia para volcar credenciales en memoria de Windows desde hace casi dos décadas.
• Funciona principalmente contra el proceso LSASS, donde el sistema operativo mantiene material de autenticación reutilizable.
• Habilita ataques Pass-the-Hash, Pass-the-Ticket, Golden Ticket, Silver Ticket y DCSync sin tocar la red de forma evidente.
• Su detección obliga a combinar telemetría de endpoint (Sysmon, EDR), eventos de Active Directory y reglas de comportamiento.
• Las mitigaciones efectivas pasan por LSA Protection, Credential Guard, tier model y eliminación de protocolos heredados.

Qué es Mimikatz: origen y propósito

Mimikatz nace en 2007 como un proyecto personal de Benjamin Delpy, ingeniero francés conocido en la comunidad como gentilkiwi. Su origen fue una demostración: Delpy quería evidenciar que el proveedor de seguridad WDigest de Windows mantenía contraseñas en plaintext dentro de la memoria del sistema operativo, algo que Microsoft consideraba aceptable por compatibilidad. La publicación de la herramienta convirtió un detalle de diseño en un riesgo operativo masivo, y forzó cambios profundos en el modelo de credenciales de Windows a partir de Windows 8.1 y Server 2012 R2.

La herramienta es dual por naturaleza. Es a la vez un proyecto de investigación documentado en GitHub bajo gentilkiwi/mimikatz y un arma estándar en el arsenal de actores APT y operadores de ransomware. Esa ambigüedad no es accidental: Delpy ha defendido públicamente que mantener el código abierto obliga a los proveedores a corregir las debilidades del modelo en lugar de esconderlas.

Su penetración real en la industria es notable. Mimikatz está integrado en Metasploit a través del módulo kiwi de Meterpreter, viene embebido en Cobalt Strike como funcionalidad mimikatz ejecutable inline desde un Beacon, aparece como dependencia o referencia en marcos como Empire, PoshC2, Brute Ratel y Sliver, y se reescribe periódicamente en otros lenguajes para evadir firmas (Pypykatz en Python, SafetyKatz, Invoke-Mimikatz en PowerShell). Cualquier consultoría de red team seria asume que el cliente va a ver intentos de ejecución de Mimikatz o sus derivados en algún punto de la operación, y diseña la prueba alrededor de esa realidad.

Cómo funciona técnicamente: LSASS y WDigest

Para entender Mimikatz hay que entender primero cómo guarda Windows el material de autenticación reutilizable. El componente clave es LSASS (Local Security Authority Subsystem Service), el proceso en modo usuario que gestiona las políticas locales de seguridad, valida intentos de inicio de sesión y mantiene en memoria las credenciales necesarias para single sign-on dentro de la sesión interactiva del usuario.

Cuando un usuario inicia sesión en una máquina Windows, LSASS recibe sus credenciales y las almacena internamente para que los proveedores de seguridad (Security Support Providers o SSPs) puedan reutilizarlas sin volver a pedirlas. Los proveedores históricos incluyen NTLM, Kerberos, Digest, WDigest, CredSSP, TsPkg y LiveSSP. Algunos solo necesitan hashes, pero otros, en particular WDigest hasta 2013, mantenían la contraseña en claro dentro de la memoria del proceso para soportar autenticación HTTP Digest.

El cambio histórico llegó con el boletín KB2871997 y los cambios introducidos en Windows 8.1, Server 2012 R2 y posteriores: WDigest pasó a estar deshabilitado por defecto, y la clave de registro HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential controla si se vuelve a cachear texto plano. En la práctica, una década después, sigue habiendo sistemas legados donde WDigest está activado por compatibilidad o donde un atacante con privilegios suficientes lo reactiva temporalmente para forzar al usuario a reautenticarse y capturar su contraseña en claro.

Aunque WDigest ya no sea el vector universal de 2014, LSASS sigue manteniendo en memoria hashes NTLM, claves Kerberos (claves AES128, AES256 y RC4 derivadas de la contraseña) y tickets TGT y TGS activos. Cualquier proceso con privilegio SeDebugPrivilege puede abrir un handle al proceso LSASS, leer su memoria y reconstruir esas estructuras. Eso es exactamente lo que hace Mimikatz: no explota una vulnerabilidad clásica, abusa de un modelo de diseño documentado.

Módulos clave de Mimikatz

Mimikatz se organiza en módulos invocados con sintaxis modulo::comando. La lista real tiene decenas, pero los módulos siguientes concentran más del 90% del uso ofensivo y defensivo.

sekurlsa::logonpasswords

Es el comando más conocido. Lee la memoria de LSASS y extrae para cada sesión activa los hashes NTLM, claves Kerberos y, si WDigest está habilitado, contraseñas en claro de todos los usuarios con sesión iniciada. Su salida típica incluye al usuario interactivo de la máquina, cuentas de servicio que han pasado por el host y, en servidores de salto o terminal servers, decenas de identidades reutilizables a la vez. Ejecución habitual con privilegios de administrador local:

privilege::debug
sekurlsa::logonpasswords

Es el primer paso de la mayoría de las cadenas de movimiento lateral en AD.

sekurlsa::pth

Implementa Pass-the-Hash. A partir de un hash NTLM extraído del paso anterior, lanza un nuevo proceso (típicamente cmd.exe o powershell.exe) suplantando esa identidad sin conocer la contraseña en claro. Permite que el atacante actúe en la red como el usuario comprometido contra cualquier servicio que acepte autenticación NTLM (SMB, WMI, RDP en escenarios concretos).

sekurlsa::pth /user:Administrator /domain:contoso.local /ntlm:31d6cfe0d16ae931b73c59d7e0c089c0

Es una de las técnicas más antiguas que sigue siendo eficaz en entornos sin segmentación adecuada.

sekurlsa::tickets

Vuelca todos los tickets Kerberos en memoria del proceso LSASS, incluidos TGT y TGS activos para todas las sesiones. Los tickets se exportan en formato .kirbi y pueden reimportarse en otra máquina con kerberos::ptt para hacer Pass-the-Ticket, suplantando al usuario titular del ticket frente a servicios Kerberos hasta que el ticket caduca.

sekurlsa::tickets /export

Útil para escalar lateralmente sin tocar contraseñas, especialmente contra cuentas de servicio cuyo hash NT no es trivial de crackear pero cuyo TGT está en memoria de un servidor accesible.

lsadump::sam

Extrae los hashes de las cuentas locales del SAM (Security Account Manager) del propio sistema. Requiere SYSTEM para acceder a las claves del registro implicadas. Es típicamente el primer paso cuando se compromete una workstation: obtener el hash del administrador local para reutilizarlo contra el resto del parque si no hay rotación adecuada (problema que LAPS resuelve si está bien desplegado).

privilege::debug
token::elevate
lsadump::sam

lsadump::dcsync

Probablemente el comando más destructivo. Implementa el protocolo MS-DRSR y se hace pasar por un controlador de dominio para solicitar replicación de credenciales. A partir de una cuenta con los privilegios Replicating Directory Changes, Replicating Directory Changes All y Replicating Directory Changes In Filtered Set, descarga remotamente los hashes NT de cualquier usuario del dominio, incluido krbtgt. No requiere ejecutar código en el DC ni dejar binarios en él.

lsadump::dcsync /domain:contoso.local /user:krbtgt

Obtener el hash de krbtgt habilita Golden Tickets; obtener el de cualquier admin habilita compromiso total. Es la pieza que convierte un ACL mal puesto en un compromiso de dominio.

kerberos::golden

Forja un Golden Ticket: un TGT arbitrario firmado con el hash NT de la cuenta krbtgt. Permite emitir tickets como cualquier usuario del dominio, con la pertenencia a grupos que el atacante decida y con periodo de validez de hasta diez años. Si la cuenta krbtgt no se rota, un Golden Ticket de hoy sigue funcionando indefinidamente.

kerberos::golden /user:Administrator /domain:contoso.local /sid:S-1-5-21-... /krbtgt:HASH /ticket:golden.kirbi

Es persistencia de dominio nivel APT y motivo por el que la rotación doble de krbtgt cada 6 a 12 meses es un control crítico.

kerberos::silver

Forja un Silver Ticket: un TGS arbitrario para un servicio concreto, firmado con el hash NT de la cuenta de servicio asociada al SPN. A diferencia del Golden Ticket, el Silver no pasa por el DC en el momento del uso, lo que lo hace especialmente sigiloso. Solo da acceso al servicio cuyo hash se haya capturado, pero contra un MSSQL o un share crítico puede ser suficiente.

kerberos::golden /service:cifs /target:fileserver01 /rc4:HASH /user:Administrator ...

Aparece en operaciones de persistencia silenciosa contra servicios sensibles.

crypto::certificates

Extrae certificados y sus claves privadas del almacén de Windows, incluidos certificados marcados como no exportables. Tiene impacto directo sobre infraestructuras PKI internas: un certificado de autenticación de máquina o de smart card capturado se puede reutilizar contra cualquier servicio que acepte ese certificado. Combinado con ADCS mal configurado (familia de ataques ESC1-ESC11) abre rutas de escalada a Domain Admin sin necesidad de tocar LSASS.

crypto::capi
crypto::certificates /export

Uso legítimo en red team y pentesting

Mimikatz tiene encaje legítimo claro cuando se ejecuta dentro de una operación autorizada por escrito. Las operaciones de red team y los pentests internos contra Active Directory necesitan demostrar el impacto real de un compromiso, y eso pasa por reproducir las mismas técnicas que usaría un atacante avanzado, incluida la extracción de credenciales en endpoints comprometidos durante la prueba.

Los marcos formales bajo los que aparece son consistentes. TIBER-EU y DORA TLPT para entidades financieras europeas exigen pruebas con TTPs realistas mapeadas a inteligencia de amenazas reciente, y el credential dumping con Mimikatz o derivados está catalogado en MITRE ATT&CK bajo T1003 OS Credential Dumping, sub-técnicas T1003.001 LSASS Memory y T1003.006 DCSync, entre otras. Cualquier ejercicio serio en banca europea va a tocar esas técnicas.

Los requisitos operativos cuando se usa Mimikatz en legítimo son estrictos. Tiene que existir un contrato firmado con scope explícito sobre los dominios y máquinas autorizadas, una ventana temporal acordada, un canal de comunicación directo con el cliente para parar la operación si algo escala fuera de control, preservación de logs de las herramientas usadas y custodia documentada de las credenciales extraídas durante el ejercicio (idealmente cifradas y borradas tras la entrega del informe). Sin esos controles, ejecutar Mimikatz contra una infraestructura ajena, aunque sea para "demostrar el problema", es un delito de acceso no autorizado bajo el artículo 197 bis del Código Penal español y figuras equivalentes en el resto de la Unión Europea.

La línea entre uso legítimo e ilegítimo no la marca la herramienta. La marcan la autorización escrita, el scope y la trazabilidad.

Mimikatz en ataques reales: APT y ransomware operators

El catálogo de actores que han usado Mimikatz en operaciones documentadas es largo. APT28 (atribuido a GRU ruso) y APT29 (atribuido a SVR ruso) aparecen en informes públicos del FBI y CISA usando Mimikatz para movimiento lateral en intrusiones contra agencias gubernamentales europeas y estadounidenses. Lazarus Group (atribuido a Corea del Norte) lo ha utilizado en campañas contra el sector financiero y de criptoactivos.

En el ecosistema ransomware el uso es prácticamente universal. Los afiliados de Conti, LockBit, BlackCat/ALPHV, Royal, Black Basta y Akira documentados por respondedores de incidentes han usado Mimikatz o variantes como parte del playbook estándar entre la fase de acceso inicial y el despliegue del cifrador. La cadena típica que aparece en informes de DFIR sigue una secuencia repetida: acceso inicial vía phishing o explotación de un appliance perimetral, escalada local en el primer endpoint, ejecución de Mimikatz contra LSASS para conseguir credenciales adicionales, descubrimiento de Active Directory con BloodHound, escalada a Domain Admin vía DCSync o golden ticket, despliegue del ransomware contra todo el dominio.

El punto que importa subrayar es que Mimikatz raramente es el vector inicial. Es el multiplicador. La inversión defensiva da más retorno cerrando el initial access y dificultando la post-explotación que persiguiendo el binario mimikatz.exe con firmas estáticas que cualquier operador medianamente competente evade en minutos.

Detección con EDR y SIEM

La detección moderna de Mimikatz no se basa en buscar el binario. Se basa en perseguir el comportamiento. Las técnicas siguientes son las que producen más valor en producción:

• Acceso al handle del proceso LSASS (Sysmon EventID 10 ProcessAccess). Cualquier proceso que abre lsass.exe con permisos 0x1010 o 0x1410 es altamente sospechoso. Es la huella más limpia del acceso de Mimikatz a la memoria del subsystem. Reglas Sigma públicas (proc_access_win_lsass_dump.yml y derivadas) cubren el patrón.
• Llamadas a MiniDumpWriteDump sobre lsass.exe. Variantes modernas no usan Mimikatz directamente, sino que generan un volcado de memoria de LSASS con la API legítima de Windows y luego procesan el .dmp offline con Pypykatz o Nanodump. EDRs maduros instrumentan esa API y alertan independientemente del binario que la invoque.
• Cobalt Strike Beacon ejecutando mimikatz inline. Cuando un Beacon ejecuta el módulo mimikatz integrado, el patrón en endpoint incluye inyección reflexiva en el proceso del Beacon, acceso a LSASS desde un proceso no esperado (típicamente rundll32.exe o un binario LOLBAS) y tráfico C2 saliente con timing característico. Reglas EDR específicas para Cobalt Strike capturan la combinación.
• Enumeración masiva de tickets Kerberos (Windows Event 4769 anómalo). Picos repentinos de peticiones de TGS desde un único host hacia muchas cuentas de servicio sugieren Kerberoasting o enumeración previa a Silver Ticket. Reglas SIEM con baselining por usuario detectan el patrón.
• Detección de DCSync (Windows Event 4662 con Object Type GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 o 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2). Cualquier cuenta que no sea controlador de dominio que dispare ese evento contra el objeto del dominio está haciendo replicación, y eso casi siempre es DCSync. Es una de las reglas con menos falsos positivos contra Mimikatz.
• Firmas AMSI y bypass detection. Mimikatz y sus variantes en PowerShell (Invoke-Mimikatz, SafetyKatz) suelen intentar bypass de AMSI antes de cargarse. Detectar el patrón de bypass (manipulación de amsiInitFailed, parcheo de amsi.dll en memoria) es más eficaz que detectar la cadena mimikatz directamente.
• Hunting de procesos hijo no esperados de lsass.exe. LSASS no debería generar procesos hijo en operación normal. Cualquier child process es señal clara de manipulación.
• Behavior analytics sobre Active Directory. Una workstation que de pronto consulta el catálogo global, enumera grupos privilegiados y solicita TGS para cuentas de servicio sensibles está fuera de su perfil normal. UEBA en SIEM detecta el patrón cuando las reglas estáticas se quedan cortas.

La detección por capas es la única que aguanta operadores serios. Una sola regla, por buena que sea, se evade.

Mitigación efectiva

Las mitigaciones que reducen el impacto real de Mimikatz están todas documentadas y la mayoría disponibles sin coste adicional en licencias Windows ya pagadas:

• LSA Protection (RunAsPPL). Habilitar RunAsPPL en el registro convierte LSASS en un Protected Process Light, lo que impide a cualquier proceso no firmado abrir un handle de lectura sobre su memoria. Mimikatz sin bypass específico falla. Existen bypasses (drivers vulnerables, Mimikatz !+ con mimidrv.sys), pero suben el listón notablemente.
• Credential Guard. Disponible desde Windows 10 Enterprise y Server 2016, aísla LSASS dentro de un contenedor basado en virtualización (VBS) gestionado por Hyper-V. Las credenciales NTLM y los TGT viven dentro del enclave y son inaccesibles desde el sistema operativo, incluso con SYSTEM. Es la mitigación más potente disponible contra credential dumping en endpoints.
• Eliminar WDigest cache (KB2871997 y posteriores). Asegurar que UseLogonCredential está en 0 o ausente, y monitorizar cualquier cambio. Cierra la captura de contraseñas en claro desde LSASS.
• Restringir SeDebugPrivilege. El privilegio de depuración es lo que permite abrir handles arbitrarios contra procesos del sistema. Revisar la política Debug programs y mantenerla limitada a administradores estrictamente necesarios reduce la superficie.
• Tier model administrativo (T0, T1, T2). Separación estricta entre cuentas de dominio (T0), cuentas de administración de servidores (T1) y cuentas de administración de estaciones de trabajo (T2). Un administrador de dominio que nunca pone su credencial en un endpoint T2 no deja material reutilizable que Mimikatz pueda extraer desde ahí.
• LAPS (Local Administrator Password Solution o Windows LAPS moderno). Rotación automática de contraseñas de administrador local únicas por máquina. Convierte el clásico Pass-the-Hash desde una workstation comprometida contra el resto del parque en una técnica inviable.
• Modelos zero trust en Active Directory. Protected Users group fuerza Kerberos sin RC4, deshabilita NTLM y restringe delegación para los usuarios incluidos. Authentication silos y authentication policies atan credenciales privilegiadas a hosts concretos. Ambas reducen drásticamente lo que vale un hash extraído.
• Reducción de superficie. Deshabilitar protocolos heredados (NTLMv1, SMBv1, LLMNR, NBT-NS), forzar SMB signing y LDAP signing, y eliminar cuentas de servicio con SPN y contraseña débil. Cierra los canales donde un hash extraído se reutiliza.

Ningún control aísla solo. La defensa contra Mimikatz es por capas y depende tanto del endpoint como del diseño del dominio.

Mimikatz alternatives y derivados

El binario mimikatz.exe original está firmado por todas las soluciones EDR del mercado, y cualquier copia sin modificar se bloquea antes de ejecutarse en un endpoint con protección activa. Esto no significa que el problema esté cerrado. El ecosistema de derivados es amplio:

• Pypykatz: reimplementación en Python puro, frecuente en operaciones donde Python se ejecuta sobre WSL, sobre un servidor Linux con acceso a un volcado de LSASS, o como librería para frameworks de explotación.
• lsassy: cliente que vuelca LSASS remotamente mediante múltiples técnicas (procdump, comsvcs.dll, dllinject) y parsea offline con Pypykatz.
• Nanodump: utilidad ligera que genera volcados de LSASS evadiendo la mayoría de EDRs mediante técnicas como duplicación de handles, syscalls directas y forks del proceso.
• SafetyKatz e Invoke-Mimikatz: versiones PowerShell con bypass de AMSI integrado.
• Frameworks completos como Cobalt Strike, Brute Ratel y Sliver llevan funcionalidad equivalente integrada sin depender del binario externo.

La implicación operativa es clara: detectar y bloquear el binario Mimikatz cierra el caso más torpe, pero las técnicas son hoy commodity. La defensa eficaz mira la conducta sobre LSASS y el tráfico de replicación contra los DCs, no el nombre del ejecutable.

Encaje con marcos normativos

Mimikatz aparece de forma explícita en varios marcos de referencia que aplican a empresas españolas y europeas. En MITRE ATT&CK la técnica principal es T1003 OS Credential Dumping con sub-técnicas T1003.001 (LSASS Memory), T1003.002 (Security Account Manager), T1003.004 (LSA Secrets), T1003.005 (Cached Domain Credentials) y T1003.006 (DCSync). Cualquier programa de detección serio mide cobertura contra esas técnicas con telemetría real, no con asunciones.

En el marco regulatorio europeo, NIS2 (artículo 21) exige medidas técnicas y organizativas para gestión de incidentes, control de acceso y gestión de identidades. Un entorno donde Mimikatz funciona trivialmente porque LSA Protection está deshabilitada, Credential Guard sin desplegar y no hay separación de cuentas privilegiadas no aprueba auditoría seria. La ISO 27001:2022 lo cubre principalmente en el control A.5.16 Identity management y en los controles A.8.5 Secure authentication, A.8.7 Protection against malware y A.5.7 Threat intelligence, todos relevantes para sustentar la postura defensiva contra credential dumping. Para entidades financieras, DORA y los ejercicios TLPT asociados incluyen credential dumping en el catálogo de TTPs obligatorios a simular.

Demostrar resistencia a Mimikatz, no en papel sino con evidencia técnica reciente, es parte del expediente de cumplimiento maduro en cualquiera de los marcos anteriores.

Preguntas frecuentes

¿Es ilegal descargar Mimikatz?

Descargar el binario o el código fuente desde el repositorio público de GitHub no es ilegal en España ni en la Unión Europea. La herramienta se publica con fines de investigación y se usa de forma cotidiana en formación, laboratorios y certificaciones ofensivas. Lo que sí es delito, bajo el artículo 197 bis del Código Penal español, es ejecutarla contra sistemas para los que no se tiene autorización por escrito del titular. La frontera no la marca el archivo, la marca la autorización explícita y el scope de la operación.

¿Mimikatz funciona en Windows 11 actualizado?

Sí, con matices. Mimikatz se sigue ejecutando contra Windows 11 y Server 2022 actuales, pero las protecciones modernas (LSA Protection, Credential Guard, VBS) bloquean los módulos clásicos contra LSASS si están habilitadas. En entornos sin esas protecciones activadas, el comportamiento es prácticamente igual que en Windows 7. Existen bypasses específicos para Credential Guard y RunAsPPL documentados públicamente, pero suben mucho el listón operativo y el riesgo de detección.

¿Qué diferencia hay entre Mimikatz y Pypykatz?

Mimikatz es el original, escrito en C, ejecuta directamente sobre Windows y necesita acceso interactivo al sistema. Pypykatz es una reimplementación en Python puro que parsea estructuras de LSASS desde un volcado de memoria (un .dmp generado previamente con cualquier herramienta). Pypykatz permite procesar credenciales offline, encadenarse con scripts y operar desde Linux. Funcionalmente cubren un solapamiento amplio en sekurlsa y lsadump, aunque Mimikatz tiene más módulos (en particular kerberos::golden interactivo y todo el área crypto).

¿Mi EDR comercial detecta Mimikatz?

Los EDR de Microsoft Defender for Endpoint, CrowdStrike, SentinelOne, Palo Alto Cortex y similares detectan y bloquean el binario Mimikatz estándar y la mayoría de variantes públicas conocidas. La detección por comportamiento sobre acceso a LSASS también está madura. Lo que no detectan de forma fiable son derivados ofuscados ad-hoc, técnicas de volcado mediante syscalls directas o operadores con tradecraft elaborado. El nivel de cobertura real solo se mide con ejercicios purple team que validen las reglas contra TTPs reales.

¿Puedo usar Mimikatz en mi propio laboratorio?

Sí, sin restricción mientras los sistemas implicados sean propiedad del usuario y estén aislados de redes productivas. Montar un dominio Active Directory en máquinas virtuales y practicar sekurlsa::logonpasswords, DCSync y Golden Ticket es la forma estándar de aprender. Los laboratorios públicos como Hack The Box, TryHackMe y los entornos de certificaciones OSCP, OSEP o CRTP incluyen Mimikatz como parte del temario y son terreno legítimo.

¿Cómo se relaciona Mimikatz con ataques ransomware?

Mimikatz aparece de forma casi sistemática en los playbooks de afiliados de ransomware modernos como Conti, LockBit, BlackCat, Royal o Akira. La cadena habitual: acceso inicial vía phishing o explotación perimetral, escalada local, ejecución de Mimikatz contra LSASS para obtener credenciales adicionales, descubrimiento del dominio con BloodHound, escalada a Domain Admin mediante DCSync, despliegue del cifrador contra todo el AD. Cerrar credential dumping eficazmente convierte cadenas de ransomware completas en intrusiones contenidas en un solo endpoint.

Recursos relacionados

• Ataques Kerberos en Active Directory: el contexto en el que Mimikatz forja Golden Tickets, Silver Tickets y ejecuta DCSync.
• Red Team: guía para empresas: el tipo de operación dentro de la cual Mimikatz se ejecuta de forma autorizada.
• Qué es MITRE ATT&CK: el framework que cataloga T1003 OS Credential Dumping y sus sub-técnicas.
• Qué es PKI: el contexto sobre certificados que Mimikatz puede extraer con crypto::certificates.
• Qué es un EDR: el control de endpoint que detecta el comportamiento sobre LSASS.
• Qué es un SIEM: la plataforma donde se centralizan los eventos 4662, 4769 y Sysmon EID 10 relevantes.
• Qué es hacking ético: el marco profesional bajo el que herramientas como Mimikatz se usan legítimamente.

Validar postura defensiva con Secra

En Secra ejecutamos auditorías adversariales sobre Active Directory con foco en credential dumping y movimiento lateral: simulación de TTPs reales con Mimikatz, Cobalt Strike y derivados modernos en entornos previamente autorizados, validación purple team de detecciones sobre LSASS y DCSync, revisión del despliegue de LSA Protection y Credential Guard, auditoría de tier model administrativo y mapeo completo de hallazgos a MITRE ATT&CK con remediación priorizada. Si tu organización quiere medir hoy cuánto le costaría a un atacante con un endpoint comprometido llegar a Domain Admin, o necesita evidenciar resistencia a credential dumping para NIS2, DORA o ISO 27001:2022, escríbenos a través de contacto.