4.5 · Credential dumping: LSASS, NTDS.dit y DCSync

15 min de lectura · credential-access / active-directory / dcsync / lsass / privilege-escalation / deteccion · ⎙ PDF

Panorama#

Credential dumping —el volcado de credenciales— es la fase de la post-explotación donde el atacante, tras haber comprometido un equipo, extrae el material de autenticación que ese equipo guarda para reutilizarlo: reautenticarse, moverse lateralmente y escalar hacia el control del dominio. Es el pivote central de un compromiso de Active Directory, porque casi todas las técnicas de las Partes vecinas —el Pass-the-Hash de 4.2 · Kerberos, el forjado de tickets, el Pass-the-Ticket de 4.8 · Movimiento lateral— consumen credenciales que provienen de aquí.

Conviene distinguir dos depósitos de credenciales con alcances muy distintos. El primero es LSASS (Local Security Authority Subsystem Service, el proceso lsass.exe), que en cada equipo Windows cachea en memoria el material de autenticación de todas las sesiones activas de esa máquina para habilitar el inicio de sesión único. Volcar LSASS rinde las credenciales de quien haya iniciado sesión en ese host. El segundo es NTDS.dit, el archivo que en un controlador de dominio almacena los hashes NTLM de todo el dominio, más una réplica de la configuración del bosque. Volcar NTDS.dit es el objetivo terminal: con el hash de la cuenta krbtgt se forjan Golden Tickets (ver 4.2 · Kerberos) y con la base entera se persiste indefinidamente. La elección de vía depende de dónde está parado el atacante y qué privilegios reunió con el recon de 4.1 · Reconocimiento de AD.

flowchart TD
  A["Equipo comprometido"] --> B{"¿Qué acceso\ntengo?"}
  B -->|"Shell interactiva\nen un host"| C["Volcado local de LSASS\n(comsvcs / ProcDump)"]
  B -->|"Admin remoto\nsobre un host"| D["Volcado remoto de LSASS\n(lsassy / nxc --lsa)"]
  B -->|"Derechos de replicación\nsobre el dominio"| E["DCSync (MS-DRSR)\nsin tocar disco"]
  B -->|"Admin local en el DC\nsin derechos de replicación"| F["Copiar NTDS.dit + SYSTEM\n(VSS / ntdsutil ifm)"]
  C --> G["Parseo offline\n(pypykatz)"]
  D --> G
  E --> H["Hashes del dominio entero\n(incl. krbtgt)"]
  F --> H
  G --> I["Hashes NT, tickets,\ncontraseñas en claro"]
  H --> J["Golden Ticket (4.2),\npersistencia, crackeo"]
  I --> J

Volcado de LSASS: el tesoro de una máquina#

LSASS concentra todo el valor de un host porque unifica, en un solo proceso, cada formato de credencial de las sesiones activas: hashes NT (para Pass-the-Hash), tickets de Kerberos (para Pass-the-Ticket), claves maestras DPAPI (el subsistema de protección de datos de Windows) y, en sistemas heredados con WDigest activo, incluso contraseñas en texto claro. Esa concentración es también su punto débil defensivo: proteger un solo proceso mitiga muchos vectores a la vez. En un controlador de dominio, donde han iniciado sesión administradores de dominio y cuentas de servicio, un volcado de LSASS puede rendir el dominio completo.

Las técnicas se dividen según el acceso que exigen y el rastro que dejan. Las remotas parten de credenciales de administrador sobre el objetivo y operan por SMB/WMI/RPC, dejando rastro en la red; las locales exigen una shell interactiva y dejan rastro en el host —un archivo .dmp y su transferencia—. El analista defensivo elige el punto de telemetría según cuál espera.

# Remoto — un solo comando conecta por SMB, vuelca y parsea
lsassy -u administrator -p 'contraseña' -d dominio.local <IP-objetivo>
nxc smb <IP-objetivo> -u administrator -p 'contraseña' --lsa # LSA secrets del registro
nxc smb <IP-objetivo> -u administrator -p 'contraseña' -M nanodump # dumper evasivo integrado
# Local, fileless — comsvcs.dll (DLL firmada de Microsoft) volca LSASS por su PID
Get-Process lsass # obtener el PID (p. ej. 636)
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump 636 C:\mem.dmp full
# Parseo offline del volcado (implementación Python de sekurlsa)
pypykatz lsa minidump lsass.dmp

Dos matices operativos importan para entender la detección que sigue. Primero, la evasión se juega en cómo se genera el volcado: nanodump usa syscalls indirectas y manipulación de memoria para eludir el AV/EDR, mientras que las vías con binarios firmados de Microsoft —Process Explorer, ProcDump, la propia comsvcs.dll— buscan pasar por actividad legítima. El uso de comsvcs.dll vía rundll32 es además fileless: no sube ninguna herramienta, solo abusa de binarios ya presentes en el sistema (LOLBins, living-off-the-land binaries). Segundo, un caso aparte es secretsdump de Impacket, que no toca LSASS en absoluto: obtiene los hashes por el protocolo de replicación de dominio, la técnica que la siguiente sección desarrolla.

impacket-secretsdump es cualitativamente distinto del resto de las herramientas remotas: no ejecuta ningún binario en el objetivo ni lee su LSASS, sino que abusa de DRSUAPI (DCSync) para pedir los hashes como si fuera otro controlador de dominio. Por eso su detección no es de endpoint sino de red — una máquina que no es DC ejecutando DsGetNCChanges. Es la bisagra que conecta el volcado de LSASS con el saqueo de NTDS.dit.

NTDS.dit y DCSync: saquear la base del dominio#

Con privilegios sobre el dominio, el objetivo deja de ser un host y pasa a ser la base de credenciales entera. Hay dos vías de extracción, y la diferencia entre ellas es puro sigilo.

La vía remota y silenciosa es DCSync. Su poder está en que no roba ningún archivo: se hace pasar por un controlador de dominio. El protocolo de replicación de directorio de Microsoft (MS-DRSR) permite que un DC le pida a otro que le “replique” los secretos de una cuenta —o de todas— como parte del funcionamiento normal de un dominio con varios controladores. Cualquier cuenta que posea los derechos de replicación DS-Replication-Get-Changes y DS-Replication-Get-Changes-All sobre el objeto de dominio puede ejecutar esa misma operación y recibir los hashes directamente, sin tocar NTDS.dit en disco y sin ejecutar código en el DC. Esos derechos suelen acumularlos las aristas de ACL que mapea BloodHound en 4.1 · Reconocimiento de AD, y son el desenlace habitual de la ruta de 4.4 · AD CS (un TGT del DC vía ESC8) o del relay de 4.3 · NTLM.

# DCSync — pedir secretos al DC simulando ser otro DC (requiere derechos de replicación)
mimikatz # lsadump::dcsync /domain:dominio.local /user:krbtgt # el hash de krbtgt = Golden Ticket
mimikatz # lsadump::dcsync /domain:dominio.local /all /csv # todo el dominio
impacket-secretsdump dominio.local/usuario:'contraseña'@<IP-DC> # DCSync vía DRSUAPI

La nota OPSEC del material de origen es la clave defensiva de toda esta técnica: “la replicación siempre ocurre entre dos computadoras; un DCSync desde una cuenta de usuario puede levantar alertas”. La replicación legítima la originan controladores de dominio entre sí; un DsGetNCChanges cuyo origen es una cuenta de usuario o una máquina que no es DC es anómalo por definición, y ese es exactamente el gancho de detección de la sección de defensa.

La vía local aplica cuando el atacante ya tiene administración sobre el DC pero no los derechos de replicación: copiar NTDS.dit directamente. El obstáculo es que el archivo está siempre en uso y bloqueado, así que no se puede copiar en caliente. La solución abusa de Volume Shadow Copy (VSS), el servicio de instantáneas de Windows pensado para backup: toma un snapshot consistente del volumen y copia NTDS.dit desde él. Con una salvedad imprescindible: NTDS.dit está cifrado con la SYSKEY del sistema, guardada en la hive SYSTEM del registro, de modo que siempre hay que llevarse también SYSTEM —sin la SYSKEY, los hashes extraídos son inservibles—.

# Copia local sorteando el bloqueo del archivo (VSS)
vssadmin create shadow /for=C:
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit C:\Shadow\
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM C:\Shadow\
ntdsutil "ac i ntds" "ifm" "create full c:\temp" q q # empaqueta NTDS.dit + SYSTEM de una
# Extracción offline de los hashes (necesita ambos archivos)
secretsdump.py -system SYSTEM -ntds NTDS.dit LOCAL

Dos regalos de configuración: reversible encryption y el crackeo#

El material de origen destaca una joya que ahorra todo el trabajo de crackeo. Si una cuenta tiene activada la reversible encryption —el bit 0x80 (UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED) en su atributo userAccountControl—, su contraseña no se almacena como un hash unidireccional sino cifrada de forma reversible con la SYSKEY. Como un administrador de dominio puede extraer la SYSKEY, esa contraseña se revierte trivialmente a texto claro: secretsdump y Mimikatz la imprimen directamente como CLEARTEXT, sin crackear nada. Es una opción heredada (para RADIUS/CHAP) que hoy es un regalo para el atacante, y por eso barrer las cuentas que la tengan activada es una acción de higiene defensiva.

# Localizar cuentas con reversible encryption (defensa: deben ser cero)
Get-ADUser -Filter 'userAccountControl -band 128' -Properties userAccountControl

Para el resto de las credenciales —hashes NT unidireccionales— el paso final es el crackeo offline con hashcat en modo NTLM (-m 1000), alimentado con diccionarios (rockyou, listas de HIBP, weakpass) y reglas de mutación. No toda contraseña cae, pero en un dominio real un porcentaje sustancial sí, y basta una cuenta de servicio con contraseña débil para reabrir la cadena.

# Crackeo offline de hashes NT (-m 1000 = NTLM)
hashcat -m 1000 -w 4 -O -a 0 -o crackeadas.txt hashes.txt diccionario.txt -r regla.rule

Bajo el capó: LSASS, los SSP y por qué Credential Guard cambia el juego#

Vale bajar una vez al nivel de la estructura, porque LSASS no es una «caja» mágica que guarda contraseñas: es un proceso de modo usuario que hospeda varios subsistemas, y entender cómo están dispuestos ahí adentro es lo que explica por qué el volcado rinde ese menú de formatos, por qué un .dmp offline se basta a sí mismo, y —sobre todo— por qué las mitigaciones modernas (Credential Guard, PPL) cambian el juego a nivel de mecanismo y no como un eslogan.

LSASS es un anfitrión de proveedores, no un depósito único. lsass.exe aloja la LSA (Local Security Authority) y, cargados en su propio espacio de direcciones, un conjunto de Security Support Providers (SSP): cada SSP es una DLL que implementa un protocolo de autenticación y mantiene su propio material de credencial en la memoria de LSASS. msv1_0 guarda el hash NT (para responder los desafíos NTLM de 4.3 · NTLM); kerberos guarda las claves de largo plazo y los tickets TGT/TGS de 4.2 · Kerberos; wdigest —heredado— necesitaba la contraseña de forma reversible; tspkg, livessp y cloudap añaden escritorio remoto y Azure AD. Por eso un solo volcado rinde todos los formatos a la vez: no es un blob homogéneo, son varios proveedores, cada uno con su almacén. El menú que imprime pypykatz es, literalmente, un recorrido proveedor por proveedor.

El material está en RAM porque el SSO lo exige. La razón de que LSASS cachee credenciales es el inicio de sesión único: reautenticar sin volver a pedir la contraseña. msv1_0 debe conservar el hash NT para calcular las respuestas NTLM cuando el usuario toque otro recurso; kerberos conserva la clave de largo plazo para renovar el TGT; y wdigest, por diseño de su protocolo (HTTP Digest para RADIUS/CHAP), necesitaba la contraseña en claro —de ahí el clásico UseLogonCredential=1 que un atacante reactiva para forzar su reaparición—. La reversible encryption de la sección anterior es la versión de directorio de la misma lógica heredada: comodidad de autenticación de hace veinte años que hoy es material listo para reutilizar.

Por qué el .dmp offline se basta a sí mismo. sekurlsa —el módulo de Mimikatz que pypykatz reimplementa— no «parsea LSASS» por arte de magia: camina las estructuras internas de cada SSP (la lista de LogonSessions, las struct internas de msv1_0) y descifra el material con la propia clave de cifrado de memoria de LSASS. LSASS protege sus secretos en RAM con LsaProtectMemory/LsaUnprotectMemory —una clave AES/3DES con su IV—, pero guarda esa misma clave dentro de su propio espacio de direcciones. Un volcado full contiene entonces las dos cosas: los secretos cifrados y la llave para descifrarlos. Ese es el motivo por el que la vía comsvcs.dll MiniDump ... full necesita el modificador full (la memoria completa, no solo los handles) y por el que el .dmp resultante se procesa en la máquina del atacante sin volver a tocar el objetivo.

Credential Guard: el mecanismo, no el eslogan. Credential Guard se apoya en la Virtualization-Based Security (VBS): el hipervisor parte la ejecución en Virtual Trust Levels —VTL0 (normal, donde vive lsass.exe) y VTL1 (aislado)—. Credential Guard traslada los secretos (hash NT, claves Kerberos) a un proceso de LSA aislado, LSAIso.exe, que corre en VTL1. El LSASS de VTL0 deja de tener los secretos: lo único que puede hacer es pedirle a LSAIso, por una interfaz acotada de llamadas proxy, que calcule la respuesta a un desafío. Por eso volcar lsass.exe con Credential Guard activo rinde blobs cifrados inservibles: la clave vive en VTL1, inalcanzable desde VTL0 aunque el atacante sea SYSTEM, porque la frontera la impone el hipervisor y no una ACL que un privilegio pueda saltar. Y sus límites definen el pivote del atacante moderno: Credential Guard no protege los tickets Kerberos ya emitidos hacia VTL0 (de ahí el Pass-the-Ticket de 4.8 · Movimiento lateral), no cubre el SAM de cuentas locales, y no protege retroactivamente credenciales cacheadas antes de habilitarlo. Es exactamente por eso que el atacante que se topa con Credential Guard deja de volcar LSASS y se mueve a robar tickets o a DCSync, que nunca toca LSASS.

PPL: la otra mitad, ortogonal. RunAsPPL no oculta los secretos: marca lsass.exe como Protected Process Light, de modo que el Security Reference Monitor deniega cualquier OpenProcess que pida VmRead desde un proceso de menor nivel de protección —incluido SYSTEM—. Por eso Mimikatz necesita !+/mimidrv: un driver firmado que baja a kernel para retirar la marca de protección. Sortear PPL es, por tanto, un problema estructuralmente de kernel —bring your own vulnerable driver—, que conecta con 3.21 · Explotación de kernel. Las dos defensas son ortogonales y se complementan: Credential Guard esconde el secreto; PPL bloquea la lectura del proceso.

De dónde sale realmente la telemetría. La firma de detección tampoco es arbitraria. El SACL (System Access Control List) que Windows instala por defecto sobre lsass.exe dispara la auditoría (Event ID 4656/4663) solo cuando se solicita el permiso VmRead (0x0010, Virtual Memory Read): Microsoft focalizó el SACL en el único acceso que importa —leer la memoria de LSASS— para detectar el volcado sin ahogar el registro con consultas inofensivas. Ese SACL es el fundamento del Sysmon Event ID 10 que la defensa consume. El corolario ofensivo, que Forshaw explicita, es que un atacante con SeSecurityPrivilege puede reescribir ese SACL para cegar la telemetría (dejando su huella en el Event ID 4907) antes de tocar el proceso. Todo este substrato —el nivel de protección de LSASS, su SACL, los SSP cargados— se inspecciona en vivo con NtObjectManager (Get-NtProcess -Name lsass.exe -Access QueryLimitedInformation, y la lectura de su descriptor de seguridad), que es lo que convierte esta explicación en algo que un analista puede abrir y verificar por su cuenta.

Defensa y detección#

El volcado de credenciales es ruidoso si se sabe qué mirar, y cada vía tiene una firma propia. La defensa combina detección específica con una postura que reduce la superficie de raíz.

DCSync — la firma de oro. El Event ID 4662 (operación sobre un objeto de directorio) que referencia el GUID de acceso DS-Replication-Get-Changes (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2) originado por una cuenta que no es un controlador de dominio es la alerta más limpia de todo Active Directory: la replicación legítima solo la hacen los DC entre sí. A nivel de red, monitorear el tráfico DRSUAPI (DsGetNCChanges) proveniente de IPs que no son DC detecta lo mismo. La postura que lo previene: minimizar quién posee GetChanges/GetChangesAll (idealmente solo los DC) y auditar periódicamente la ACL del objeto de dominio.
Volcado de LSASS. El Sysmon Event ID 10 (acceso a lsass.exe) captura el dumping local; conviene alertar sobre procesos no esperados que abren LSASS con permisos de lectura de memoria, y en particular sobre la línea de comando rundll32 ... comsvcs.dll, MiniDump. El fundamento de esa telemetría es el SACL por defecto de lsass.exe, que solo audita el permiso VmRead (ver «Bajo el capó»); por eso conviene además vigilar el Event ID 4907 (cambios de auditoría/SACL sobre el proceso), que delata al atacante que intenta cegar la detección antes de volcar. Como mitigación de raíz, Credential Guard no «esconde mejor» los secretos sino que los traslada a un proceso aislado en VTL1 (VBS) fuera del alcance de un volcado de VTL0 —aunque no cubre tickets ya emitidos, el SAM local ni las sesiones previas a su activación—, y PPL (Protected Process Light) marca el proceso para que el SRM impida su lectura desde usermode, incluso a SYSTEM (reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v RunAsPPL /t REG_DWORD /d 1); su rodeo exige bajar a kernel (BYOVD), lo que eleva el costo y el ruido del ataque. Desactivar WDigest elimina el almacenamiento de contraseñas en claro.
Copia de NTDS.dit. Detectar la ejecución de vssadmin create shadow y ntdsutil ... ifm por línea de comando (Event ID 4688 con auditoría de command-line), los accesos a rutas \\?\GLOBALROOT\... sobre NTDS.dit/SYSTEM, y las transferencias de archivos anómalamente grandes (del orden de decenas de MB) desde un controlador de dominio hacia una estación de trabajo.
Vías remotas de LSASS. Arranques inesperados del servicio RemoteRegistry (que secretsdump levanta), accesos a los recursos compartidos administrativos C$/ADMIN$/IPC$ desde estaciones no administrativas, y la transferencia del .dmp resultante.
Higiene de configuración. Barrer y eliminar la reversible encryption (userAccountControl -band 128 = 0) cierra el regalo del texto claro.

El mapeo defensivo consolidado de Active Directory —la correlación de estos eventos con la línea base, las reglas SIEM y los playbooks de respuesta— se desarrolla en 4.9 · Defensa de AD. La detección de autenticación y logon que acompaña a estas técnicas (Event ID 4624/4776) vive en la Parte azul, en blue-dfir/effective-threat-investigation.

Referencias#

red-infra/ad-attacks/cap-03 — Volcado de credenciales de dominio: DCSync, extracción de NTDS.dit y reversible encryption.
red-infra/ad-cluster/cap-02 — Credential dumping de LSASS: técnicas remotas y locales, evasión y su detección purple.
red-infra/windows-security-internals/cap-09 (Forshaw, Security Auditing) — el SACL por defecto de lsass.exe audita solo el permiso VmRead; fundamento del Sysmon 10 y del cegado de telemetría vía SeSecurityPrivilege.
red-infra/windows-security-internals/cap-13 (Forshaw) — arquitectura de la SSPI y los Security Support Providers como anfitriones del material de credencial en LSASS.
Microsoft — How Credential Guard works (VBS/VTL y el aislamiento en LSAIso.exe) y Configuring Additional LSA Protection (RunAsPPL).
MITRE ATT&CK — T1003.001 LSASS Memory, T1003.003 NTDS y T1003.006 DCSync.
Microsoft — Credential Guard y Protecting LSA with RunAsPPL; guía de auditoría de replicación de directorio (Event ID 4662).

Mencionado en

0.3 · Sistemas operativos: privilegio, procesos y aislamientoEl sustrato de ejecución sobre el que corre todo lo demás. El sistema operativo tiene una sola misión de seguridad: administrar el privilegio y hacer cumplir el aislamiento, de modo que un programa no pueda hacer lo que no le corresponde ni tocar lo que no es suyo. Este capítulo explica la frontera primaria —la que separa el núcleo (kernel), que manda sobre el hardware, del espacio de usuario, donde corren los programas— y por qué esa frontera es la línea que la escalada de privilegios busca cruzar. Recorre el modelo de privilegio de Windows (los identificadores de seguridad, los tokens de acceso, los niveles de integridad, el control de cuentas de usuario y el papel central del proceso que custodia las credenciales, LSASS) y el de Linux (usuarios y grupos, los bits de permiso, el conjunto de capabilities que fragmenta el poder de root, el bit setuid, los espacios de nombres que aíslan contenedores y la interfaz de llamadas al sistema como la puerta entre el usuario y el núcleo). El hilo que une todo es el privilegio como la abstracción central: comprenderlo es comprender por qué la escalada, el volcado de credenciales y la evasión son variaciones de un mismo movimiento —conseguir más autoridad de la otorgada, o esconderse de quien la vigila—. No rehace el volcado de credenciales de la Parte 4 ni la escalada de la Parte 3: nombra la arquitectura de privilegio que ambos presuponen.
0.4 · Criptografía: confianza matemática y sus límitesEl sustrato de confianza verificable. La criptografía es la única herramienta de la seguridad que apoya sus garantías en la matemática y no en la vigilancia: bien usada, permite confiar en la confidencialidad, la integridad y el origen de un dato sin tener que custodiar el canal por el que viaja. Este capítulo ordena sus tres primitivas —el cifrado simétrico (una clave compartida, rápido, para el grueso de los datos), el cifrado asimétrico (un par de claves pública y privada, que resuelve el problema de acordar secretos con desconocidos) y las funciones de hash (huellas de tamaño fijo que garantizan integridad, no confidencialidad)— y combate el error de categoría más común y más caro: confundir cifrar, codificar y hashear. Sobre esas primitivas levanta las construcciones que el resto del manual dio por sentadas: las funciones de derivación de claves con sal que deciden si un hash de contraseña resiste o cae, la firma digital y la infraestructura de clave pública (PKI) que sostiene tanto TLS como la autenticación por certificados del Active Directory, y Kerberos como criptografía aplicada donde la diferencia entre un algoritmo viejo y uno moderno decide si un ticket se puede crackear. Cierra con la lección de arquitectura: la criptografía casi nunca falla en el algoritmo; falla en la implementación y en la gestión de las claves. No rehace Kerberos ni AD CS: da el fundamento matemático que ambos presuponen.
2.6 · Leaks, breaches y stealer logs: procesar y pivotar datos filtradosEl capítulo que cierra P2 —y con ella el bloque rojo— desarrolla en profundidad la «técnica más valiosa» que 2.2 introdujo: el investigador arma su propia colección offline de datos filtrados y la consulta. La habilidad durable no son las URLs (caducan) sino la cadena de herramientas de línea de comandos para procesar datasets gigantes sin una base indexada. La taxonomía tiene cuatro capas de invasividad creciente —leaks, breaches, stealer logs y ransomware— y su técnica estrella es el reúso de contraseña: hallar la clave de un objetivo revela las demás cuentas que la reúsan. El encuadre ético que gobierna todo —ingerir el dato para notificar a los comprometidos, jamás acceder a cuentas ni redistribuir— es a la vez la línea legal y la puerta al bloque azul.
3.1 · Metodología de pentest: del scoping al reporteEl capítulo que abre la Parte 3 y enmarca todo lo que sigue: qué distingue un pentest de un red team (y qué es un assumed breach), las fases del engagement como ciclo de vida, el mindset de enumeración exhaustiva y cíclica, cómo las credenciales encadenan el ataque, y por qué la metodología del atacante es también el mapa del defensor.
3.9 · Escalada de privilegios (Windows/Linux)Del foothold sin privilegios a root/SYSTEM: por qué la escalada local es un problema de enumeración y misconfiguración antes que de exploits — credenciales tiradas, ACL flojas y servicios en Windows, SUID/sudo/cron/capabilities en Linux, abuso de tokens y GTFOBins — con el exploit de kernel como último recurso y su detección.
3.11 · Evasión de AV/EDRLa evasión del payload —complementaria a la del canal de 3.10—: cómo mira un AV/EDR (motores, y los cuatro métodos de detección firma→heurística→comportamiento→ML/AMSI), y cómo cada técnica ataca una capa concreta. La escalera de evasión que va del disco a la memoria a los binarios de confianza: obfuscación on-disk y recompilar la herramienta, inyección in-memory y thread injection, LOLBAS y «PowerShell sin powershell.exe», y la frontera —cegar al vigía con AMSI/ETW bypass, unhooking de EDR e Internal Monologue—; con el mapeo de por qué cada movimiento deja una traza de comportamiento nueva.
3.21 · Exploit-dev V — Explotación de kernel: del bug de driver a UID 0El capstone del track de explotación binaria: cómo un bug de gestión de memoria en el núcleo (o en un driver) se convierte en control del anillo de máximo privilegio. El modelo del kernel (espacio de direcciones compartido, el panic como fracaso), la taxonomía de bugs, la escalera de tres fases (recolección → detonación → ejecución), la escalada a UID 0 en Linux (task_struct → commit_creds, grooming de SLUB) y a SYSTEM en Windows (robo de token en EPROCESS, la recuperación anti-deadlock), el kernel moderno (SMEP/SMAP/KPTI, BYOVD, Dirty Pipe) y por qué se detecta mal, con su lente defensivo.
4.1 · Reconocimiento de Active DirectoryCómo se mapea un dominio de Active Directory antes de atacarlo: el modelo de grafo de BloodHound, la enumeración con PowerView y el AD Module, el user hunting hacia Domain Admin y el catálogo de aristas abusables, con su detección.
4.2 · Kerberos: Kerberoasting, AS-REP y tickets forjadosCómo se abusa de Kerberos en Active Directory: Kerberoasting, AS-REP Roasting, Pass-the-Ticket/Hash y la familia de tickets forjados Golden/Silver/Diamond/Sapphire, con su detección. Incluye los internals del protocolo —la clave RC4 como NT hash, la estructura del PAC y sus firmas, y la validación del PAC que faltaba— que explican por qué la familia entera funciona y que anclan la mitigación estructural (PAC signature enforcement, noPac).
4.3 · NTLM: captura, relay y coerciónLa debilidad estructural de NTLM en la red: captura de Net-NTLMv1/v2, relay a LDAP/SMB sin craquear nada, coerción con PetitPotam/SpoolSample y las variantes que sortean el signing (Drop the MIC, mitm6), con su detección. Incluye los internals de SSPI —el intercambio de tres tokens, la disociación entre la capa lógica y la de red como causa raíz del relay, el MIC que protege integridad pero no dirección, el double-hop problem y el channel binding/target name opt-in— que explican por qué el relay es estructural y no un bug parcheable.
4.4 · AD CS: escalada por certificados (ESC1–ESC11)La PKI del dominio como ruta limpia a Domain Admin: la familia ESC1–ESC11, el SAN arbitrario como falla central, la ruta sin credenciales por coerción y relay (ESC8/ESC11), Certifried, y las técnicas PKINIT transversales —Pass-the-Certificate, UnPAC-the-Hash y Shadow Credentials— con su detección.
4.6 · Delegación y trusts: cruzar los límites del bosqueLas dos maneras de cruzar un límite de seguridad en Active Directory: las relaciones de confianza entre dominios y bosques (SID History, Trust Ticket, PAM trust) y la delegación Kerberos (unconstrained, constrained/S4U, RBCD y el Bronze Bit) — el terreno donde el compromiso de un host se vuelve compromiso del bosque, con la detección de cada vía.
4.7 · ACLs, grupos privilegiados y persistencia en ADEl modelo de permisos de Active Directory como superficie de escalada: el catálogo de aristas de ACE (GenericAll, WriteDACL, ForceChangePassword…) que convierten un control parcial en dominio, los grupos built-in que dan SYSTEM sin ser administradores, y la persistencia que se repara sola — AdminSDHolder/SDProp y el SSP malicioso — con su detección. Incluye los internals del SRM —la estructura del descriptor de seguridad, el WriteDac inalienable del dueño, el algoritmo de access-check en tres fases (mandatory/token/discrecional), el orden canónico y la brecha entre permisos declarados y acceso efectivo— que explican por qué el abuso de ACE funciona y qué auditar más allá de la membresía.
4.8 · Movimiento lateral: Pass-the-Hash, Pass-the-Ticket y Overpass-the-HashReutilizar credenciales sin conocer la contraseña: el material robado —NT hash o ticket Kerberos— se convierte en acceso remoto. Pass-the-Hash (NTLM), Overpass-the-Hash (el hash reingresa a Kerberos) y Pass-the-Ticket (.kirbi/.ccache), las vías de ejecución (SMB/WMI/WinRM/DCOM) y NetExec como orquestador — con su detección.
4.9 · Defensa de Active Directory: detección, hardening y respuestaEl capítulo azul que cierra la Parte 4: consolida en un sistema coherente el mapeo defensivo que 4.1–4.8 vinieron enlazando. La telemetría que hay que tener antes de que sirva, el diccionario de Event IDs de AD por fase, la correlación que convierte alertas sueltas en una historia de ataque, el hardening que quita cada técnica de raíz y el playbook de respuesta —incluido el doble reset de krbtgt—.
5.5 · Forense de memoriaEl quinto y último capítulo-fundamento de P5, y el que destapa lo que el disco no ve. La RAM es evidencia volátil que muere en el reinicio —procesos activos, conexiones establecidas, credenciales en claro, código inyectado sin archivo—, de modo que se captura en vivo antes de apagar, con cuidado de no corromperla. Sobre el volcado, Volatility perfila el sistema y triangula lo oculto: pslist frente a psscan expone el proceso que un rootkit borró de la lista del kernel, malfind localiza el código inyectado en regiones RWX sin archivo de respaldo, netscan recupera el canal de C2 y hashdump las credenciales. Es el espejo forense de la inyección in-memory (3.11) y de los rootkits (3.14): las técnicas que ganaron contra el escaneo de disco pierden en memoria, porque para ejecutar tienen que estar ahí. Cierra los fundamentos 5.1–5.5; los binarios que extrae alimentan el análisis de malware de 5.8.
5.6 · Detección de movimiento lateral en el SIEMEl primero de los seis capítulos que cierran, desde el lado azul, las técnicas del bloque rojo. El movimiento lateral es la fase que convierte un equipo comprometido en una red comprometida, y no puede ejecutarse en silencio: toda ejecución remota en Windows deja un rastro característico —un inicio de sesión de red, un servicio recién instalado, un recurso administrativo tocado, un proceso hijo que no corresponde—. Recorre la telemetría de cada vía (PsExec y admin shares, WMI y WinRM, RDP, pass-the-hash) insistiendo en la regla que las une: el evento se lee correlacionando origen y destino, nunca en una máquina sola. Cierra con la contracara arquitectónica —la segmentación reduce el blast radius y obliga al tráfico este-oeste a cruzar un punto donde se lo puede ver— y con los dos casos donde el lateral es el punto de detección final. Es el espejo azul de 4.8, 4.9 y 3.13.
5.12 · Detección de rootkits: integridad de kernel y arranqueA un rootkit no se le pregunta si está: posee el árbitro que respondería. Este capítulo consolida las dos detecciones que P5 ya construyó —el forense de memoria de 5.5 para la vista cruzada en Windows y la detección de persistencia de 5.10 para Linux— y añade lo que ninguno alcanza: la escalera de profundidad completa hasta el firmware, el vector de entrada al anillo 0 que domina hoy (BYOVD, cargar un driver firmado pero vulnerable), y la arquitectura de integridad que es la única defensa que gana. La tesis es incómoda pero clarificadora: contra un adversario que reside en la capa donde corren las herramientas de inspección, la respuesta no es detección sino diseño —negar el punto de observación (HVCI/VBS mueve el árbitro por debajo del kernel), controlar quién entra al anillo 0 (lista de drivers bloqueados) y anclar el arranque en el hardware (Secure Boot + arranque medido + TPM)—; y donde la detección todavía aplica, tiene que venir desde abajo o desde afuera del rootkit, nunca del host que este ya controla.