Este writeup tiene fines educativos y de práctica profesional. Las respuestas corresponden al laboratorio público de CyberDefenders. Las direcciones IP, nombres de host, cuentas de usuario y credenciales mostradas pertenecen al escenario controlado del reto, no a infraestructura ni sistemas reales.
0x00 — Introducción
Octavo post de la serie de laboratorios de CyberDefenders.
En esta ocasión analizamos PsExec Hunt, un laboratorio de Network Forensics donde investigamos actividad de movimiento lateral sospechoso detectado por un IDS.
El escenario parte de una alerta del IDS que marcó actividad de PsExec — una herramienta admin legítima de Microsoft que los atacantes adoran para ejecutar comandos remotos y moverse lateralmente por la red.
Mi misión: analizar el PCAP, identificar el punto de entrada del atacante, las máquinas comprometidas, el alcance del incidente y cualquier IoC que revele sus tácticas.
A lo largo del análisis disecciono SMB, sigo la autenticación NTLM, rastreo los shares administrativos y reconstruyo la cadena completa del ataque.
0x01 — El Escenario
| Elemento | Detalle |
|---|---|
| Alerta inicial | IDS detecta movimiento lateral vía PsExec |
| Evidencia | Archivo PCAP con tráfico SMB/NTLM |
| Herramienta | Wireshark para análisis de tráfico de red |
| Protocolo objetivo | SMB2 sobre TCP puerto 445 |
| Misión | Identificar IP del atacante, hosts comprometidos, credenciales usadas, alcance del ataque |
0x02 — Análisis
Q1
¿Cuál es la dirección IP de la máquina desde la que el atacante obtuvo acceso inicialmente?
Lo primero: abro el PCAP en Wireshark y reviso la jerarquía de protocolos con Statistics → Protocol Hierarchy.
SMB domina el PCAP: 93.5% de los paquetes. Es lo esperable en un escenario de lateral movement — todo va por el 445.
Filtrando las negociaciones SMB, veo tráfico entre 10.0.0.130 y 10.0.0.133.
El cliente 10.0.0.130 manda el primer SMB Negotiate Protocol Request a 10.0.0.133.
Una Negotiate Request es el saludo inicial de SMB — cliente y servidor acuerdan la versión del protocolo antes de seguir hablando. Que 10.0.0.130 inicie la conversación me confirma que es el origen del ataque.
RESPUESTA Q1
Respuesta: 10.0.0.130
Q2
¿Cuál es el nombre de host de la máquina a la que el atacante pivotó primero?
Sigo el flujo TCP del paso anterior. El tráfico SMB muestra autenticación NTLM, que es justo lo que toca mirar para sacar el hostname del objetivo.
En el intercambio NTLM, el servidor manda un NTLMSSP_CHALLENGE que arrastra metadatos del sistema:
- NetBIOS nombre de dominio
- NetBIOS nombre de la computadora
- DNS nombre de dominio/computadora
Ahí dentro está el hostname: SALES-PC. Clásico lateral movement — el atacante pivota de su máquina al primer objetivo.
RESPUESTA Q2
Respuesta: SALES-PC
Q3
¿Cuál es el nombre de usuario de la cuenta que el atacante utilizó para la autenticación?
Busco el SMB2 Session Setup Request en el flujo. Ahí está el NTLM auth con el nombre de cuenta.
El campo NTLM dentro del Session Setup muestra el session ID y la cuenta: ssales. Los metadatos confirman que viene de HR-PC.
Cuenta comprometida o credenciales robadas — da igual, el caso es que ssales es la cuenta que el atacante está usando. Para IR, saber qué usuario está comprometido es oro: te da el punto de partida para revisar permisos, grupos y alcance del incidente.
RESPUESTA Q3
Respuesta: ssales
Q4
¿Cuál es el nombre del ejecutable utilizado por el atacante en la máquina objetivo?
Bajando por el flujo TCP, busco los Create Request de SMB. El atacante está montando un servicio en la máquina objetivo.
El paquete muestra un Create Request para PSEXESVC.exe. Si has visto PsExec antes, sabes exactamente qué es: el binario del servicio que PsExec copia al objetivo para ejecutar comandos remotos. Lo legítimo usado para lo ilegítimo, como siempre.
Con Export Objects → SMB de Wireshark confirmo la transferencia del binario. PSEXESVC.exe viajando por la red — un clásico que cualquier SOC que se precie debería tener en sus reglas de detección.
RESPUESTA Q4
Respuesta: PSEXESVC.exe
Q5
¿Qué recurso compartido utilizó el atacante para instalar el servicio en la máquina comprometida?
Toca mirar qué share usó para dejar el binario. PsExec casi siempre tira por ADMIN$ — es el patrón habitual, pero hay que confirmarlo en el PCAP.
El SMB2 Tree Connect Request apunta a \\10.0.0.133\ADMIN$. Confirmado: el binario se instala en el share ADMIN$, que mapea a C:\Windows.
RESPUESTA Q5
Respuesta: ADMIN$
Q6
¿Qué recurso compartido de red utilizó PsExec para la comunicación entre las dos máquinas?
Otra vez los Tree Connect, pero ahora buscando el canal de comunicación entre las dos máquinas.
El Tree Connect muestra una conexión a \\10.0.0.133\IPC$. Ahí está — PsExec usa IPC$ para el canal de comunicación entre procesos (RPC) que necesita para ejecutar comandos remotos.
RESPUESTA Q6
Respuesta: IPC$
Q7
¿Cuál es el nombre de host de la segunda máquina a la que el atacante intentó acceder?
Busco más tráfico SMB hacia otros hosts. Si el atacante ya pivotó una vez, probablemente lo intentó más veces.
Otra SMB Negotiate Request, esta vez de 10.0.0.130 a 10.0.0.131. El NTLM Challenge de la respuesta trae los metadatos del host objetivo.
El hostname es MARKETING-PC. Pero revisando el flujo TCP, el auth falló: STATUS_LOGON_FAILURE. Las credenciales de ssales no servían en esa máquina — o no tenía permisos, o la cuenta no existía ahí. El atacante probó suerte y no le salió. Vale, al menos sabemos hasta dónde intentó llegar.
RESPUESTA Q7
Respuesta: MARKETING-PC
0x03 — Cadena de Ataque
| Fase | Acción | Detalle técnico |
|---|---|---|
| 1. Punto de entrada | Atacante desde 10.0.0.130 | SMB Negotiate Protocol Request |
| 2. Autenticación | Credencial comprometida: ssales | NTLM authentication desde HR-PC |
| 3. Objetivo 1 (éxito) | SALES-PC comprometido | 10.0.0.133 — acceso exitoso |
| 4. Despliegue | Instalación de PSEXESVC.exe | Via ADMIN$ share — Create Request |
| 5. Comunicación | Canal IPC$ establecido | Tree Connect a IPC$ para RPC |
| 6. Ejecución remota | PsExec activo en SALES-PC | Control remoto completo |
| 7. Objetivo 2 (fallo) | MARKETING-PC rechazó acceso | 10.0.0.131 — STATUS_LOGON_FAILURE |
0x04 — Lecciones Aprendidas
- PsExec: herramienta legítima, uso malicioso
PsExec es una herramienta administrativa legítima de Microsoft, pero su abuso para movimiento lateral es extremadamente común en ataques reales.
Los SOC deben monitorizar la creación del servicio PSEXESVC.exe en recursos compartidos administrativos, especialmente cuando se origina desde cuentas no privilegiadas o fuera de horarios habituales.
- Recursos compartidos administrativos como vectores de ataque
Los recursos compartidos ocultos ADMIN son objetivos clásicos para movimiento lateral.
Deshabilitar estos recursos compartidos en sistemas que no requieren administración remota reduce significativamente la superficie de ataque.
Si son necesarios, implementar restricciones basadas en IP y monitorización continua.
- Autenticación NTLM como evidencia forense
El tráfico NTLM capturado en PCAP revela información crítica: nombres de host, cuentas comprometidas, dominios y resultados de autenticación.
Los investigadores deben buscar específicamente paquetes NTLMSSP_CHALLENGE y NTLMSSP_AUTH para reconstruir la cadena de movimiento lateral.
- Detección de movimiento lateral en SIEM
Las reglas de detección deben activarse ante
(1) conexiones SMB inusuales entre hosts internos (2) creación del servicio PSEXESVC.exe (3) múltiples intentos de autenticación desde una misma IP origen a diferentes destinos (4) acceso a ADMIN fuera de patrones normales.
La correlación de eventos es clave.
- Los fallos de autenticación también cuentan
El intento fallido en MARKETING-PC (STATUS_LOGON_FAILURE) es evidencia valiosa y revela el alcance del intento de compromiso y sugiere que las credenciales robadas tenían permisos limitados.
Los logs de fallos de autenticación son tan importantes como los exitosos para entender el alcance completo del ataque.
- Análisis de PCAP como skill fundamental
Wireshark y el análisis profundo de protocolos (SMB, NTLM, RPC) son skills fundamentales para Network Forensics.
Conocer cómo filtrar por tcp.stream, usar Statistics → Protocol Hierarchy, exportar objetos SMB y diseccionar paquetes NTLM permite reconstruir ataques complejos desde tráfico capturado.
[EOF] “SMB traffic tells the story — follow the packets, find the attacker”