5.6 · Detección de movimiento lateral en el SIEM

Panorama#

Los cinco capítulos anteriores construyeron los fundamentos de la defensa: el programa y su ciclo de detección (5.1), la capa de datos sobre la que todo se apoya (5.2), la detección de identidad y correo (5.3), el ciclo de respuesta (5.4) y el forense de memoria (5.5). Con ese piso puesto, empiezan los seis capítulos que devuelven al bloque rojo su lente defensivo, uno por técnica. Este es el primero, y le toca la fase bisagra de toda intrusión: el movimiento lateral (lateral movement), el conjunto de técnicas con las que un adversario que ya tiene un punto de apoyo pivota hacia otros equipos de la red interna buscando datos, credenciales de mayor privilegio o el controlador de dominio.

Es la fase que decide la magnitud del incidente. Un equipo comprometido es un problema de un equipo; un adversario que se movió a diez es una brecha de red, y si llegó al dominio, la respuesta deja de ser reimaginar una estación de trabajo y pasa a ser el doble reset de krbtgt que describe la defensa de Active Directory (4.9). Por eso el lateral es, en casi todos los playbooks, el punto de detección final: el último momento en que contener todavía significa contener algo acotado.

La buena noticia para el defensor es que esta fase es estructuralmente ruidosa. Las técnicas ofensivas que describieron el movimiento lateral en AD (4.8) —pass-the-hash, overpass-the-hash, pass-the-ticket ejecutados por PsExec, WMI, WinRM o DCOM— y el pivoting y tunneling (3.13) comparten una restricción física: para ejecutar código en otra máquina hay que autenticarse contra ella y hacer que algo arranque allí. Y ambas cosas las audita Windows. El adversario puede elegir entre binarios firmados, protocolos nativos y credenciales legítimas —eso es exactamente lo que hace el abuso de herramientas administrativas—, pero no puede saltar de host sin dejar en el destino un inicio de sesión, y casi nunca sin dejar un servicio, una tarea o un proceso hijo fuera de lugar.

La tesis del capítulo es doble. Primero: el movimiento lateral se detecta correlacionando origen y destino, no leyendo una máquina sola. Un 4624 de tipo 3 en un servidor de archivos es, aislado, uno de los eventos más comunes del dominio; el mismo evento leído junto con lo que ocurría en el equipo que lo originó, y junto con el servicio que se instaló treinta segundos después, es una firma de ejecución remota. Segundo: la contracara del problema no es solo analítica sino arquitectónica —la segmentación de red reduce el radio de alcance del adversario y, al obligar al tráfico interno a cruzar fronteras controladas, lo vuelve visible—.

Este capítulo no repite el diccionario de eventos de autenticación de AD que ya fijó 4.9 ni la mecánica de las técnicas ofensivas que detalló 4.8: se apoya en ambos y se concentra en la telemetría de ejecución remota y en la arquitectura de red que la hace legible.

flowchart TD
    A["Host comprometido
(foothold)"] --> B["Descubrimiento
AD + recursos compartidos"]
    B --> C{"Vía de ejecución remota"}
    C -->|"SMB / admin shares"| D["PsExec
4624 t3 → 5140/5145 → 7045/4697 → 4688"]
    C -->|"WinRM / WMI"| E["PS Remoting
4624 t3 → wsmprovhost.exe (4688) → 4104"]
    C -->|"RDP"| F["Escritorio remoto
4624 t10 → 4778/4779"]
    C -->|"credencial inyectada"| G["Pass-the-hash
4624 t3 + NTLM + cuenta local"]
    D --> H["Nuevo host controlado"]
    E --> H
    F --> H
    G --> H
    H --> I["Repetir: el radio crece
hasta el límite del segmento"]
    I -.->|"la segmentación
corta aquí"| J["Frontera inspeccionada
(este-oeste)"]

La regla de lectura: dos máquinas, no una#

Antes de recorrer las vías conviene fijar el método, porque es lo que distingue una investigación de lateral de una lista de eventos sueltos. Cada salto involucra dos sistemas y deja evidencia complementaria en ambos, y ninguna de las dos mitades es concluyente por sí sola.

En el origen queda la evidencia de la herramienta: el proceso que lanzó la ejecución remota (4688 con la línea de comandos completa, si el command-line auditing de 5.2 está habilitado), el bloque de script que la construyó (4104), y a veces la escritura del binario que se va a copiar. En el destino queda la evidencia del acceso: el inicio de sesión de red, el recurso compartido tocado, el servicio instalado, el proceso creado. Investigar solo el destino informa que alguien entró pero no desde dónde ni con qué; investigar solo el origen informa que se usó una herramienta pero no si tuvo éxito.

De ahí que la recolección tenga que ser previa al incidente. Si el reenvío de eventos —el Windows Event Forwarding que 5.2 describió— solo cubre servidores, la mitad de origen del salto vive en la estación de trabajo del usuario, que es justamente el equipo que el adversario ya controla y donde puede borrar el registro. Ese borrado deja el evento 1102, que es a la vez una pérdida y una señal.

SMB y recursos compartidos administrativos: la vía clásica#

La ruta más antigua y todavía la más usada aprovecha los recursos compartidos administrativos (admin shares): los volúmenes ocultos ADMIN$, C$ e IPC$ que Windows expone por omisión a los administradores del equipo. Son la antesala de la ejecución remota, porque permiten copiar un binario al destino sin ninguna herramienta adicional. El caso canónico es PsExec, la utilidad legítima de Sysinternals que administradores y adversarios usan por las mismas razones: está firmada, es conocida y hace exactamente lo que se necesita.

La secuencia que deja en el destino es una firma completa, y su valor está en el orden:

1. 4624 con logon type 3 — inicio de sesión de red. La autenticación contra el destino.
2. 5140 y 5145 — acceso a un objeto de red compartido y verificación detallada de acceso a un archivo dentro de él. Aquí aparece ADMIN$ y el nombre del binario copiado.
3. 7045 (canal System) y 4697 (canal Security) — instalación de un nuevo servicio. PsExec instala PSEXESVC con inicio bajo demanda; es el mecanismo por el que consigue ejecutar con privilegios de SYSTEM.
4. 4688 — creación de proceso. El árbol delata la maniobra: services.exe arranca PSEXESVC.exe, y este actúa como padre de la carga real. En el caso documentado sobre el conjunto de datos de APT29, ese hijo es python.exe ejecutándose desde C:\Windows\Temp —la combinación de proceso padre imposible y ruta de directorio temporal que 5.2 llamó hiding in plain sight—.

El evento 7045 merece un lugar propio en cualquier programa de detección. La instalación de un servicio nuevo es una operación poco frecuente y altamente significativa en un parque estable: los servicios legítimos se instalan cuando se despliega software, en ventanas de mantenimiento conocidas y por paquetes de instalación conocidos. Un 7045 en una estación de trabajo un martes a las tres de la tarde, con un nombre de servicio de ocho caracteres aleatorios y un binario en %TEMP%, es de las alertas de mayor fidelidad que existen. Y no cubre solo el lateral: la creación de servicios es también un mecanismo de persistencia, junto con las claves Run del registro (4657 nativo, o los Sysmon 12 y 13, más precisos) y las tareas programadas (4698 al crearse, con la carga útil visible en el bloque <Exec> del XML; 4699, 4700 y 4702 para eliminación, habilitación y actualización).

Conviene registrar aquí la variante fileless de persistencia que acompaña a esta familia, porque es la más elusiva y la que peor se cubre: la suscripción de eventos WMI (WMI event subscription), donde el adversario vincula una condición del sistema con la ejecución de código sin dejar archivo. Nativamente se audita con el evento 5861 del canal WMI-Activity, que muestra el par filtro–consumidor —el consumidor malicioso suele ser un CommandLineEventConsumer—. Con Sysmon la fidelidad es mucho mayor, porque separa las tres fases: 19 registro del filtro, 20 registro del consumidor, 21 vinculación efectiva entre ambos.

WMI, WinRM y PowerShell Remoting: ejecución por canal firmado#

La segunda familia abusa de los protocolos nativos de administración remota. WMI (Windows Management Instrumentation) y WinRM (Windows Remote Management, la base de PowerShell Remoting) existen precisamente para que un administrador ejecute comandos en equipos remotos, están firmados por Microsoft y su tráfico es indistinguible del legítimo a nivel de protocolo. Esta es la razón por la que la detección estática fracasa aquí: no hay binario malicioso que reconocer, solo uso de una función legítima por una cuenta que no debería usarla.

El rastro característico es un proceso anfitrión. Cuando llega una sesión de PowerShell Remoting, el servicio WinRM del equipo destino instancia wsmprovhost.exe, que recibe y ejecuta los comandos entrantes. Ese proceso es la firma: aparece en 4688 en el destino, y todo lo que engendre es, por definición, ejecución remota. La misma lógica aplica a WMI, donde el proceso anfitrión es WmiPrvSE.exe —y un WmiPrvSE.exe como padre de cmd.exe o powershell.exe es la relación padre-hijo anómala que 4.8 ya señalaba desde el lado ofensivo—.

El contenido de la ejecución lo recupera el Script Block Logging (4104) que 5.2 desarrolló. Los comandos llegan codificados por el propio protocolo y suelen venir además ofuscados por el operador, pero 4104 registra el bloque ya desofuscado, justo antes de su evaluación, de modo que reconstruye el cradle real: la descarga, el IEX, la carga en memoria. Esta pareja —wsmprovhost.exe en 4688 como señal de que hubo ejecución remota, 4104 como contenido de lo que se ejecutó— cubre la vía casi por completo cuando ambas fuentes están habilitadas.

La conclusión operativa es una regla de línea base más que una firma: en un entorno normal, el conjunto de equipos que originan sesiones de WinRM es pequeño y estable (los servidores de administración, las consolas del equipo de sistemas). Una estación de trabajo de usuario que de pronto abre sesiones de PowerShell Remoting contra otros equipos es anómala aunque cada evento individual sea impecable. Es el principio de 5.1 aplicado: la detección madura apunta al comportamiento, no al artefacto.

RDP: el salto interactivo#

El Remote Desktop Protocol es la vía interactiva, y su telemetría es más sencilla. El acceso queda como 4624 con logon type 10 (inicio de sesión interactivo remoto), distinguible de los tipos 2 (consola local) y 3 (red). El canal TerminalServices agrega el detalle de las sesiones: 4778 cuando una sesión se reconecta y 4779 cuando se desconecta, eventos que importan porque los adversarios que operan por RDP suelen dejar la sesión desconectada en lugar de cerrarla —lo que mantiene los procesos vivos y las credenciales cargadas—.

La lectura útil combina tres cosas: el tipo 10 en equipos donde nadie debería entrar gráficamente, el par origen-destino (RDP de estación de trabajo a estación de trabajo casi nunca es legítimo; el patrón normal es de consola de administración a servidor), y la ventana horaria. A esto se suma la regla de exposición: un 4624 tipo 10 originado en una dirección externa es, salvo excepción documentada, un incidente —y refuerza por qué exponer RDP a internet sigue siendo una de las causas raíz más frecuentes de despliegue de ransomware—.

Pass-the-hash y el límite de la autenticación como prueba#

Las técnicas de reutilización de credenciales que detalló 4.8 —pass-the-hash, overpass-the-hash, pass-the-ticket— tienen la propiedad incómoda de que producen autenticaciones perfectamente válidas. No hay un fallo que registrar: el adversario presenta material criptográfico legítimo, robado del proceso LSASS o de un volcado como los que describe el credential dumping (4.5), y el controlador de dominio o el servidor destino lo aceptan porque es correcto. Es la misma lección que 5.3 fijó del lado de la nube con el replay de tokens: una autenticación exitosa no implica legitimidad.

Lo que queda son señales indirectas, y son señales de forma más que de contenido. Para pass-the-hash, la combinación característica es un 4624 de tipo 3 cuyo Authentication Package es NTLM en un entorno donde Kerberos es el estándar, especialmente si la cuenta es local en lugar de de dominio: es exactamente lo que produce inyectar un hash NT en la sesión. La reutilización de una misma cuenta local con la misma contraseña en muchos equipos —el escenario que LAPS existe para eliminar— convierte esa señal en un patrón de abanico: un mismo par cuenta/hash autenticándose contra decenas de destinos en minutos. Para overpass-the-hash, 4.9 ya fijó la señal: el 4768 con cifrado RC4 (0x17) donde el entorno negocia AES, la firma del downgrade. Para pass-the-ticket, lo delator es la ausencia: un uso de servicio sin el 4768/4769 previo que debería haberlo precedido, porque el ticket no se pidió, se importó.

Estas detecciones son frágiles individualmente y por eso conviene el apoyo de un motor que trabaje sobre comportamiento agregado. El análisis de comportamiento de usuarios y entidades (UEBA, User and Entity Behavior Analytics) aprende la línea base de cada cuenta y cada activo —qué servidores consume habitualmente un usuario, desde qué ubicación opera, en qué horario— y alerta sobre la desviación en lugar de sobre la firma. Es el enfoque con el que plataformas como Microsoft ATA detectaban pass-the-ticket heurísticamente, sin ninguna firma estática: no reconocían el ticket robado, reconocían que esa cuenta nunca antes había tocado ese servidor desde ese equipo. La contrapartida es la conocida: la línea base tarda en formarse, hereda como «normal» lo que ya estaba comprometido cuando se instaló, y su tasa de falsos positivos depende de cuán estable sea el entorno.

La contracara arquitectónica: segmentación y tráfico este-oeste#

Toda la sección anterior es analítica: leer mejor lo que ocurre. Pero hay una palanca previa y más potente, que es limitar lo que puede ocurrir. El movimiento lateral es posible en la medida en que la red permite que cualquier equipo hable con cualquier otro por SMB, WinRM o RDP, y en la mayoría de las redes planas eso es exactamente lo que sucede.

La segmentación de red parte del supuesto que ya ordena todo P5: el perímetro será vulnerado. Si esa premisa se acepta, la pregunta de diseño deja de ser cómo impedir la entrada y pasa a ser cuánto alcanza el adversario una vez adentro —el blast radius o radio de alcance—. Segmentar es agrupar los activos por afinidad funcional o nivel de riesgo y exigir que las comunicaciones entre grupos crucen un control. Se implementa en tres planos: físico (equipamiento separado), lógico (VLANs sobre conmutadores compartidos, la forma habitual) y virtual (dentro del hipervisor, con conmutadores virtuales que aíslan máquinas contiguas alojadas en el mismo anfitrión y bloquean la suplantación de MAC o el DHCP no autorizado). La DMZ es el caso particular más antiguo: la subred donde viven los servicios expuestos, separada de la red corporativa interna.

El concepto operativo que une segmentación y detección es el tráfico este-oeste (east-west traffic): el flujo que viaja lateralmente entre servidores y segmentos internos, por oposición al tráfico norte-sur que entra y sale de la organización. Históricamente la inspección se concentró en el norte-sur, en el perímetro, y el este-oeste quedó sin observar —que es precisamente el plano donde ocurre el movimiento lateral—. Segmentar tiene entonces un doble efecto: contiene, porque un adversario en el segmento de usuarios no alcanza directamente el de servidores; y hace visible, porque el tráfico que antes era interno e inobservable ahora tiene que atravesar un cortafuegos o un sensor donde se lo registra.

De ahí la ubicación de los sensores. Los sistemas de detección y prevención de intrusiones —IDS pasivo, que alerta, e IPS en línea, que bloquea— rinden en los cuellos de botella: las fronteras entre segmentos, la DMZ, la infraestructura central, los hipervisores. Un IDS colgado únicamente del enlace a internet no ve nada del capítulo que acaba de leerse.

Este es el punto donde la segmentación se encuentra con el modelo de zero trust: si la confianza no se concede por ubicación en la red sino que cada solicitud se autentica y autoriza, el valor de haber comprometido un equipo del segmento «interno» cae drásticamente. Los controles de acceso a la red (NAC) van en la misma dirección al auditar la postura del dispositivo —parches, antivirus— antes de concederle acceso, y al poner en cuarentena al que no cumple. En entornos híbridos el problema se extiende: la conexión entre el centro de datos y la nube es una frontera más que hay que tratar como tal, con la complicación de que la evidencia del lado del proveedor está limitada por el modelo de responsabilidad compartida que 5.4 discutió.

Dos casos: el lateral como punto de detección final#

Los playbooks de respuesta muestran por qué este capítulo importa tanto en la práctica, y comparten una estructura reveladora: en ambos, el movimiento lateral es la etapa donde el SOC finalmente corta.

El primer caso empieza en la nube. Una campaña AiTM con temática de SharePoint intercepta el flujo de autenticación; el usuario completa el MFA con normalidad y el adversario captura el token de sesión, que reproduce desde otro dispositivo e IP —la técnica que 5.3 desarrolló—. Con ese acceso hace reconocimiento del buzón buscando instrucciones de acceso remoto, encuentra las de la VPN, y con la identidad comprometida entra a la red interna. A partir de ahí el incidente deja de ser de nube: descubrimiento de Active Directory (picos de consultas LDAP y Kerberos desde un host inusual, en una sesión VPN recién establecida), enumeración de recursos compartidos SMB (5140/5145), movimiento lateral hacia recursos administrativos (4624 tipo 3 contra C$ y ADMIN$) y, finalmente, preparación de ransomware con inhibición de la recuperación: intentos de detener servicios críticos, borrar instantáneas de volumen y atacar la plataforma de respaldos. El SOC detecta al correlacionar los intentos contra los backups con el movimiento lateral SMB previo.

El segundo caso empieza en el endpoint. Un enlace por Microsoft Teams —que evade las pasarelas diseñadas para correo— apunta a un archivo en OneDrive corporativo; al abrirse, una aplicación de ofimática engendra powershell.exe (la relación padre-hijo anómala de 5.2), que ejecuta código en memoria capturado por 4104 e interceptado parcialmente por AMSI. El proceso establece beaconing HTTPS hacia un dominio externo, descarga una carga secundaria, hace descubrimiento de host y dominio, e intenta volcar credenciales contra LSASS —donde el EDR alerta—. Sigue con exploración de recursos compartidos (5140) y termina en la preparación del salto lateral: inicios de sesión de red tipo 3, acceso a C$ y sabotaje del agente de EDR. También aquí la etapa final es el lateral.

La lección que ambos casos formulan explícitamente es la misma que 5.3 ya había enunciado y que conviene fijar como principio de diseño de reglas: el SOC detectó el incidente cuando múltiples comportamientos se correlacionaron en una historia de ataque completa, no cuando se disparó una alerta aislada. La forma que toma esa correlación es una regla encadenada —si se observa A, y el comportamiento posterior coincide con B y C, y la actividad alcanza descubrimiento de recursos o movimiento lateral, y hay impacto posible sobre el negocio, entonces severidad crítica— que es, como notó 5.1, una máquina de estados sobre la cadena de ataque antes que un umbral sobre un evento.

Vale la pena señalar lo que los dos casos dejan pendiente. El beaconing HTTPS del segundo, la telemetría de cortafuegos y proxy que lo revela, y las técnicas con que el canal se camufla, son el objeto del capítulo siguiente: la caza de C2 y comunicaciones salientes (5.7). El sabotaje del agente de EDR que aparece en ambos pertenece a la detección de evasión (5.8).

Postura: qué reduce el lateral antes de detectarlo#

El capítulo cierra con lo accionable, ordenado de más estructural a más analítico, porque ese es el orden de retorno real:

• Segmentación con denegación por omisión entre segmentos, e inspección del tráfico este-oeste. Es lo único que reduce el radio de alcance en lugar de solo reportarlo.
• Eliminar la reutilización de credenciales locales con LAPS, y aplicar el modelo de niveles (tiering) de 4.9: que una credencial de administrador de dominio nunca se exponga en la memoria de una estación de trabajo es lo que corta la cadena que 4.5 y 4.8 describen.
• Restringir las vías de ejecución remota a los orígenes que las necesitan: WinRM y RDP habilitados desde las consolas de administración y no desde cualquier equipo; RDP jamás expuesto a internet; los recursos administrativos accesibles solo desde el segmento de administración.
• Telemetría completa en ambos extremos: 4688 con línea de comandos, 4104, 5140/5145 habilitados (que no lo están por omisión), Sysmon donde aporte fidelidad, y reenvío de eventos que incluya las estaciones de trabajo, no solo los servidores.
• Reglas de alta fidelidad primero: 7045 fuera de ventana de mantenimiento, wsmprovhost.exe o WmiPrvSE.exe como padre de un intérprete, 4624 tipo 10 desde el exterior, 4624 tipo 3 con NTLM y cuenta local en abanico. Son pocas, se explican solas y no generan la fatiga de alertas contra la que advirtió 5.1.
• Cacería sobre la línea base: qué equipos originan sesiones remotas, qué cuentas tocan qué recursos, qué servicios se instalaron esta semana. Es material de hipótesis en el sentido de 5.1, y su producto debería ser una regla nueva, no un informe.

Con esto queda cerrado el primero de los seis capítulos que devuelven al bloque rojo su contraparte azul: la telemetría de ejecución remota responde a 4.8, la lectura desde el SIEM completa lo que 4.9 dejó planteado, y la segmentación es la respuesta arquitectónica al pivoting de 3.13. El adversario que se mueve lateralmente pierde, en esta fase, la ventaja que tenía en las anteriores: puede elegir credenciales legítimas y binarios firmados, pero no puede saltar sin tocar dos máquinas y dejar la huella en las dos.

Referencias#

• blue-dfir/effective-threat-investigation/cap-07 — persistencia y movimiento lateral en Windows Event Logs: 4698/7045/4697, suscripción WMI (5861, Sysmon 19/20/21), PsExec y ADMIN$ (4624 t3, 5140/5145, PSEXESVC), WinRM y wsmprovhost.exe, RDP (4624 t10, 4778/4779), pass-the-hash (4624 t3 + NTLM).
• blue-dfir/attack-defense/cap-10 — segmentación de red: defensa en profundidad, VLANs, segmentación física, lógica y virtual, DMZ, tráfico este-oeste, VPN y NAC, zero trust.
• blue-dfir/attack-defense/cap-11 — sensores activos: IDS frente a IPS, sensores de host y de red, detección por firmas frente a comportamiento, UEBA, falsos positivos y negativos.
• blue-dfir/incident-playbook/cap-02 — playbook AiTM: replay de token, acceso VPN, descubrimiento de AD, movimiento lateral SMB e inhibición de la recuperación.
• blue-dfir/incident-playbook/cap-07 — playbook Teams/OneDrive: PowerShell fileless, C2 sobre HTTPS, acceso a credenciales y preparación del movimiento lateral.
• MITRE ATT&CK — T1021 (Remote Services) y sus subtécnicas T1021.001 (RDP), T1021.002 (SMB/Windows Admin Shares), T1021.006 (WinRM); T1550.002 (Pass the Hash), T1550.003 (Pass the Ticket); T1543.003 (Windows Service); T1546.003 (WMI Event Subscription); T1135 (Network Share Discovery). Mitigaciones M1030 (Network Segmentation), M1026 (Privileged Account Management), M1027 (Password Policies, LAPS), M1042 (Disable or Remove Feature).