Movimiento lateral en Windows:
WMI, WinRM, PsExec, DCOM y la telemetría que los delata
Serie Blue Team | unfantasmaenelsistema.com
Cuando un atacante consigue ejecutar código en el primer equipo de una red, ese equipo casi nunca es el objetivo. El objetivo suele ser un servidor de ficheros, la base de datos de nóminas o el controlador de dominio. Para llegar hasta ahí tiene que moverse lateralmente: saltar de una máquina a otra reutilizando credenciales válidas y los mismos mecanismos de administración remota que usa el equipo de sistemas todos los días.
Ese es justo el problema para quien defiende. El movimiento lateral no usa exploits ni malware llamativo: usa WMI, WinRM, la creación remota de servicios, tareas programadas y DCOM, todo ello funcionalidad legítima de Windows. Este artículo cataloga esos mecanismos desde el punto de vista de la detección: qué son, qué rastro deja cada uno en los logs y cómo se distingue el salto de un atacante del trabajo normal de un administrador. No hay recetas de ejecución.
Qué aprenderás en este artículo
Los seis mecanismos de movimiento lateral que aparecen en casi todos los incidentes · Qué Event ID y qué telemetría deja cada uno en el equipo de origen y en el de destino · Cómo se detecta por anomalía de contexto: origen inusual, cuenta, horario y volumen · Qué mitigaciones cortan de raíz cada vía: segmentación, firewall de host, Protected Users y tiering · Cómo encaja esto con NTLM relay, Kerberoasting y la caza de C2
1. Qué es el movimiento lateral y por qué es difícil de ver
El movimiento lateral es la fase en la que un atacante que ya controla un equipo lo usa como trampolín para acceder a otros dentro de la misma red. En la matriz de MITRE ATT&CK es la táctica TA0008 (Lateral Movement), y la técnica dominante es T1021 – Remote Services, con subtécnicas por protocolo (T1021.002 SMB/admin shares, T1021.003 DCOM, T1021.006 WinRM).
Tres características lo hacen escurridizo:
- Usa credenciales válidas. Tras robar un hash, un ticket de Kerberos o una contraseña, el atacante se autentica como un usuario real. Para el servidor de destino es un inicio de sesión legítimo más
- Usa protocolos de administración. WMI y WinRM existen para gestionar equipos en remoto. El mismo canal que usa una consola de inventario o un script de despliegue sirve para ejecutar la siguiente fase del ataque
- Se parece al trabajo de IT. Un administrador que se conecta a veinte equipos por WinRM en una tarde genera un patrón muy similar al de un atacante enumerando la red. La diferencia está en el contexto, no en el evento aislado
Por eso la detección de movimiento lateral no busca una firma: busca autenticaciones y ejecuciones remotas que no encajan con el mapa normal de quién administra qué, desde dónde y a qué hora.
2. Catálogo de mecanismos y su rastro
Cada mecanismo legítimo de ejecución remota deja una combinación característica de eventos en el equipo de origen (donde está el atacante) y en el de destino (al que salta). Conocer ese patrón es lo que permite escribir la detección.
| Mecanismo | Qué es (uso legítimo) | Cómo se abusa (alto nivel) |
|---|---|---|
| Servicios remotos / PsExec | El Administrador de control de servicios (SCM) permite crear y arrancar servicios en equipos remotos por RPC/SMB | Se crea un servicio temporal en el destino que ejecuta el código del atacante con privilegios de SYSTEM |
| WMI (Win32_Process) | Infraestructura de gestión para consultar estado y configurar equipos en remoto | Se invoca la creación de un proceso en el equipo remoto a través del servicio WMI |
| WinRM / PowerShell Remoting | Implementación de WS-Management; base de Enter-PSSession e Invoke-Command | Se abre una sesión remota de PowerShell y se ejecuta la siguiente fase en memoria |
| Tareas programadas | El servicio de Programador de tareas admite registrar tareas en equipos remotos | Se registra una tarea en el destino que lanza el código, a veces con desencadenante inmediato |
| DCOM | Invocación de objetos COM entre equipos (MMC, Excel, ShellWindows y otros) | Se instancia un objeto DCOM con métodos que acaban ejecutando un comando en el destino |
| Admin shares SMB (C$, ADMIN$) | Recursos administrativos ocultos para copiar ficheros y gestionar equipos | Se copian binarios o scripts al destino como paso previo a otro de los mecanismos |
2.1 Servicios remotos y PsExec
PsExec (de Sysinternals) y sus clones funcionan creando un servicio en el equipo de destino a través del recurso ADMIN$ y del SCM. El servicio arranca, ejecuta lo que se le indica y normalmente se elimina después. Rastro típico:
- Destino, Event ID 5145 (acceso detallado a recurso compartido): apertura de ADMIN$ y a menudo de un named pipe característico (PSEXESVC o un nombre aleatorio)
- Destino, Event ID 7045 (System log): instalación de un servicio nuevo, con nombre de binario en una ruta poco habitual o con nombre aleatorio
- Destino, Event ID 4697 (Security log, si está auditado): instalación de servicio, equivalente auditable del 7045
- Destino, Event ID 4624 tipo 3 (inicio de sesión por red) seguido a veces de un tipo 2 si hay creación interactiva de token, con la cuenta del atacante
- Sysmon Event ID 1: creación de services.exe engendrando el proceso del servicio; Sysmon 17/18 para la creación y conexión del named pipe
2.2 WMI
La ejecución remota por WMI hace que el servicio WMI del destino (Winmgmt, dentro de un svchost.exe) cree el proceso solicitado. Rastro:
- Destino: WmiPrvSE.exe como proceso padre del proceso creado (Sysmon 1 / 4688). Un padre WmiPrvSE.exe para cmd.exe o powershell.exe es una señal fuerte
- Destino, Microsoft-Windows-WMI-Activity/Operational: operaciones de consumo y ejecución; útil para ver consultas y suscripciones
- Destino, Event ID 4624 tipo 3 con la cuenta usada, más 4672 si la cuenta tiene privilegios
- Origen, Sysmon 1: ejecución del cliente WMI (por ejemplo wmic.exe o un script que use la API), aunque un atacante cuidadoso usará la API directamente y no wmic
2.3 WinRM y PowerShell Remoting
WinRM escucha por defecto en los puertos 5985 (HTTP) y 5986 (HTTPS). Cuando llega una sesión, el servicio arranca wsmprovhost.exe en el destino como host del runspace remoto. Rastro:
- Destino: wsmprovhost.exe como proceso padre de lo que se ejecute en la sesión (Sysmon 1 / 4688)
- Destino, Microsoft-Windows-PowerShell/Operational Event ID 4103/4104: registro de bloques de script con el contenido ejecutado (si está habilitado Script Block Logging)
- Destino, Event ID 4624 tipo 3 con el paquete de autenticación Negotiate/Kerberos
- Red: conexión entrante a 5985/5986 en el destino (Sysmon 3 / firewall), correlacionable con el origen
- Origen, Event ID 4104: aparición de Invoke-Command / New-PSSession / Enter-PSSession en el log de PowerShell
2.4 Tareas programadas
El registro remoto de tareas usa el servicio Programador de tareas por RPC. Rastro:
- Destino, Event ID 4698 (tarea creada), 4702 (tarea actualizada), 4699 (tarea eliminada) en el Security log con auditoría de cambios de objeto activada
- Destino, Microsoft-Windows-TaskScheduler/Operational Event ID 106/140/141/200/201: registro, actualización, borrado y ejecución de la tarea
- Destino, Event ID 4624 tipo 3 con la cuenta del atacante inmediatamente antes del 4698
- Destino, Sysmon 1: svchost.exe (con la línea de comandos del Programador de tareas) como padre del proceso de la tarea
2.5 DCOM
El movimiento lateral por DCOM instancia en remoto objetos COM cuyos métodos permiten ejecutar comandos (aplicaciones de Office, MMC20.Application, ShellWindows, ShellBrowserWindow y algunos más). Rastro:
- Destino: el proceso servidor del objeto COM como padre inesperado — mmc.exe, excel.exe o explorer.exe engendrando cmd.exe o powershell.exe (Sysmon 1 / 4688)
- Destino, Event ID 4624 tipo 3 seguido de la creación del proceso hijo anómalo
- Destino, Sysmon 1 con IntegrityLevel y el árbol completo; el salto DCOM suele dejar un árbol corto y raro (svchost -> proceso COM -> intérprete)
- Red: RPC dinámico sobre el puerto 135 y un puerto alto negociado, entrante en el destino
2.6 Admin shares SMB
La copia de ficheros a C$ o ADMIN$ rara vez es el mecanismo de ejecución en sí, pero suele preceder a PsExec o a una tarea programada. Event ID 5140 (recurso compartido accedido) y 5145 (acceso detallado, con el nombre del fichero) en el destino, con la cuenta y la IP de origen, son la señal. Un pico de escrituras en ADMIN$ desde una estación de trabajo —no desde un servidor de gestión— merece revisión.
3. Cómo se detecta: anomalía de contexto
Ninguno de los eventos anteriores es malicioso por sí mismo. La detección consiste en cruzar esa telemetría con el modelo de lo que es normal en la organización. Cuatro ejes:
| Eje | Pregunta | Señal de alarma |
|---|---|---|
| Origen | ¿Desde qué equipo llega la ejecución remota? | Estación de trabajo a estación de trabajo; un equipo de usuario iniciando sesiones tipo 3 contra decenas de hosts |
| Cuenta | ¿Qué cuenta se autentica y encaja con su función? | Cuenta de servicio usada de forma interactiva; cuenta de un usuario de oficina administrando servidores; cuentas privilegiadas fuera de las PAW |
| Horario | ¿Cuándo ocurre? | Ejecución remota masiva de madrugada o en fin de semana sin ventana de cambios abierta |
| Volumen y forma | ¿Cuántos destinos y con qué patrón? | Fan-out: un origen -> muchos destinos en minutos; mismos comandos repetidos; nombres de servicio o de tarea aleatorios |
3.1 Reglas que rinden
- Padre-hijo remoto anómalo: WmiPrvSE.exe, wsmprovhost.exe o services.exe (con servicio recién creado) como padre de cmd.exe, powershell.exe, rundll32.exe o wscript.exe
- Estación a estación: Event ID 4624 tipo 3 en un equipo cliente cuyo origen (IpAddress / WorkstationName) es otro equipo cliente, no un servidor de gestión conocido
- Servicio efímero: 7045 seguido en pocos minutos de la parada y desinstalación del mismo servicio, con ruta de binario en %TEMP%, en la raíz de C: o con nombre aleatorio
- Tarea recién creada que ejecuta un intérprete: 4698 cuyo cuerpo XML invoca powershell.exe, cmd.exe o mshta.exe, sobre todo con desencadenante inmediato o de arranque
- PowerShell Remoting inusual: 4104 en destinos que nunca reciben Invoke-Command, o desde orígenes que no son de administración
El proyecto Sigma publica decenas de reglas ya escritas para T1021 y sus subtécnicas; sirven de punto de partida y luego se ajustan al inventario propio. La correlación origen-destino se hace mejor en el SIEM uniendo el 4648/4624 del origen con el 4624 tipo 3 del destino por marca de tiempo y cuenta.
Baseline antes que regla
Documenta primero qué equipos administran a qué: servidores de gestión, jump hosts, cuentas de servicio de despliegue, ventanas de mantenimiento · Convierte ese mapa en listas de exclusión estrechas (este origen, esta cuenta, este destino), nunca en desactivar la detección completa · Lo que queda fuera del mapa —estación a estación, cuenta que no toca, hora que no cuadra— es precisamente lo que hay que alertar
Kerberos, NTLM y el equipo de origen
Si el atacante usa pass-the-hash o pass-the-ticket, el equipo de origen puede no mostrar un 4624 interactivo previo coherente: la sesión de red aparece sin un logon local que la justifique · Cruza el movimiento lateral con las señales de robo de credenciales (acceso a LSASS, Kerberoasting, NTLM relay): rara vez van por separado
4. Cómo se mitiga
La detección llega después del salto. La mitigación busca que el salto no sea posible o que su alcance sea mínimo. Se combinan varias capas:
- Segmentación de red y firewall de host. El movimiento lateral necesita que el puerto de destino esté accesible. Bloquear el tráfico estación-a-estación en 135, 445, 5985 y 5986 con el Firewall de Windows por GPO corta la mayoría de las vías entre equipos de usuario. Las conexiones de administración se permiten solo desde jump hosts concretos
- Tiering de administración (modelo de niveles de Microsoft). Las cuentas de Tier 0 (dominio) nunca inician sesión en equipos de Tier 1 o 2; las de Tier 1 (servidores) nunca en estaciones. Así un equipo de usuario comprometido no tiene en memoria credenciales que sirvan para saltar hacia arriba
- Protected Users y «Account is sensitive and cannot be delegated». Para cuentas privilegiadas, impide el uso de NTLM y la delegación, y acorta la vida de los tickets
- Windows Defender Credential Guard y LSASS como proceso protegido (RunAsPPL) para dificultar el robo de credenciales que alimenta el salto
- Reglas ASR que bloquean la creación de procesos por PsExec y WMI, y la ejecución de scripts descargados; primero en auditoría, luego en bloqueo
- Deshabilitar lo que no se usa. Si WinRM no hace falta en las estaciones, se apaga por GPO. Si un servidor no necesita el Programador de tareas remoto, se restringe. Menos superficie, menos vías
- Cuentas administrativas locales únicas por equipo con LAPS, para que el hash del administrador local de un equipo no abra los demás
Lo que NO arregla el problema
Apagar SMB o WinRM en los servidores que los necesitan para operar solo traslada el trabajo del atacante a otro de los seis mecanismos · Confiar únicamente en el antivirus: el movimiento lateral usa binarios y protocolos legítimos, no ficheros que una firma reconozca · Auditar los Event ID sin un modelo de lo normal: se genera ruido, no detección
5. Encaje con el resto de la serie
El movimiento lateral es la bisagra entre el acceso inicial y el impacto. La telemetría de procesos y de logon sale de Sysmon y de los logs de eventos de Windows; las detecciones se escriben como reglas Sigma y se despliegan en el SIEM (Wazuh en el laboratorio de la serie). Las credenciales que hacen posible el salto se roban con las técnicas de Kerberoasting, NTLM relay y volcado de LSASS, y se contienen con LAPS y Credential Guard. El destino final del movimiento lateral suele ser el dominio: ahí entran AD CS (ESC) y la seguridad de Active Directory. Y el canal que el atacante mantiene mientras salta es un C2, que se caza por sus propias señales de red.
Marco legal y de uso
Este artículo es material de defensa: describe qué vigilar y qué bloquear en sistemas propios o en un laboratorio aislado (el rango 192.168.56.x de la serie), no cómo ejecutar el movimiento lateral · Probar detecciones y mitigaciones se hace únicamente sobre equipos de tu organización o de tu laboratorio, nunca sobre sistemas de terceros y nunca sobre un dominio en producción sin autorización escrita · En España, el acceso o la interferencia no autorizados en sistemas ajenos están tipificados en los artículos 197 bis, 197 ter y 264 del Código Penal, con independencia de que se usen protocolos legítimos de administración · Para validar detección de forma controlada, Atomic Red Team publica pruebas reversibles mapeadas a T1021; ejecútalas solo en tu laboratorio
Referencias
attack.mitre.org/tactics/TA0008 — Táctica Lateral Movement y técnica T1021 Remote Services · learn.microsoft.com/security/privileged-access-workstations/privileged-access-access-model — Modelo de niveles (tiering) de administración · learn.microsoft.com/windows/security/identity-protection/credential-guard — Windows Defender Credential Guard · github.com/SigmaHQ/sigma — Reglas de detección para T1021 (WMI, WinRM, servicios remotos, DCOM) · learn.microsoft.com/defender-endpoint/attack-surface-reduction-rules-reference — Reglas ASR contra PsExec y WMI · github.com/redcanaryco/atomic-red-team — Pruebas controladas T1021 para validar detección en laboratorio
Conclusión
El movimiento lateral es el punto en el que un incidente pasa de ser un equipo comprometido a ser un problema de toda la organización. Y es de los más difíciles de ver, porque WMI, WinRM, los servicios remotos, las tareas programadas y DCOM son herramientas de administración legítimas que el atacante utiliza con credenciales robadas pero válidas.
La defensa que funciona combina dos cosas. Detección por contexto: cada mecanismo deja un rastro conocido —WmiPrvSE.exe o wsmprovhost.exe como padres raros, servicios efímeros con nombre aleatorio, tareas nuevas que lanzan intérpretes, sesiones tipo 3 de estación a estación— que solo se convierte en alerta cuando no encaja con el mapa de quién administra qué. Y contención estructural: segmentación, firewall de host, tiering, Protected Users y LAPS, para que aunque el atacante quiera saltar, no llegue a ningún sitio útil.
unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)