Conexiones de Red en Memoria: netscan y Deteccion de Comunicaciones C2

La red en la memoria: conexiones que el firewall no vio

Los logs del firewall registran conexiones que pasaron por el. El IDS captura las que coinciden con sus firmas. El SIEM correlaciona lo que recibe de ambos. Pero ninguno de estos sistemas tiene visibilidad completa sobre las conexiones de red que un sistema mantiene en un momento dado.

La memoria RAM del sistema contiene el estado de red mas completo posible: cada socket abierto, cada conexion TCP establecida o en proceso de handshake, cada puerto UDP en escucha, y el proceso exacto propietario de cada uno. Ademas, conexiones que ya se cerraron pueden persistir como estructuras de datos no recicladas en el pool de memoria del kernel.

Para un analista que investiga comunicaciones C2 (Command and Control), movimiento lateral o exfiltracion de datos, el analisis de red en memoria es una fuente de evidencia que complementa y a veces supera los logs de red tradicionales.

Plugin netscan: el escaner de red de Volatility

vol -f memory.raw windows.netscan

netscan escanea el pool de memoria del kernel buscando estructuras de red TCP y UDP por sus pool tags. La salida tipica:

Offset          Proto  LocalAddr       LocalPort  ForeignAddr      ForeignPort  State        PID   Owner          Created
0xfa8001234560  TCPv4  192.168.1.50    49832      185.100.87.202   443          ESTABLISHED  5700  powershell.exe 2026-06-01 14:22:20
0xfa8001234780  TCPv4  192.168.1.50    49833      10.0.0.25        445          ESTABLISHED  4321  svchost.exe    2026-06-01 14:25:30
0xfa80012349a0  TCPv4  0.0.0.0         4444       0.0.0.0          0            LISTENING    6100  nc.exe         2026-06-01 14:30:00
0xfa8001234bc0  TCPv4  192.168.1.50    49200      13.107.42.14     443          CLOSED       3100  chrome.exe     2026-06-01 10:15:00
0xfa8001234de0  UDPv4  0.0.0.0         5355       *                *            -            1024  svchost.exe    2026-06-01 10:00:15

Cada columna aporta informacion forense:

Proto. TCPv4, TCPv6, UDPv4, UDPv6. El protocolo indica el tipo de comunicacion.

LocalAddr/LocalPort. La IP y puerto local del sistema investigado.

ForeignAddr/ForeignPort. La IP y puerto remoto. Para conexiones salientes, es el destino. Para LISTENING, sera 0.0.0.0:0.

State. El estado de la conexion TCP:

• LISTENING: el proceso esta esperando conexiones entrantes.
• ESTABLISHED: conexion activa bidireccional.
• CLOSE_WAIT: el remoto cerro, el local aun no.
• CLOSED: conexion terminada (estructura no reciclada).
• SYN_SENT: intento de conexion en progreso.
• TIME_WAIT: conexion cerrada esperando timeout.

PID/Owner. El proceso propietario de la conexion. Esto es la informacion mas valiosa: vincula actividad de red con procesos especificos.

Deteccion de comunicaciones C2

Las comunicaciones Command and Control son el canal que el atacante usa para controlar el sistema comprometido. Detectarlas en memoria requiere buscar patrones especificos.

Patron 1: procesos del sistema con conexiones externas inesperadas

Los procesos de Windows (svchost.exe, csrss.exe, wininit.exe) se conectan a servidores de Microsoft para actualizaciones y telemetria. Pero sus conexiones son a rangos IP de Microsoft bien documentados.

Si un svchost.exe tiene una conexion ESTABLISHED a una IP que no pertenece a Microsoft, Amazon, Google u otros proveedores legitimos, es una senal de C2.

vol -f memory.raw windows.netscan | grep ESTABLISHED

Para cada conexion sospechosa, verifica la IP destino en una base de datos de reputacion o de IOCs (MalwareBazaar, ThreatFox, OTX).

Patron 2: puertos de destino inusuales

El malware usa frecuentemente:

• Puerto 443 (HTTPS): la opcion mas comun porque se mezcla con trafico legitimo.
• Puertos 8080, 8443, 8888: servidores web alternativos.
• Puerto 4444: puerto por defecto de Metasploit y muchos RATs.
• Puerto 1234, 5555, 9999: puertos "redondos" que el operador no cambio del default.
• Puertos muy altos (50000 o superior): intentos de pasar desapercibidos.

Patron 3: puertos en escucha que no deberian existir

Un LISTENING en un puerto que el sistema no deberia exponer indica un backdoor o reverse shell:

TCPv4  0.0.0.0  4444  0.0.0.0  0  LISTENING  6100  nc.exe

Un listener de netcat en un servidor de produccion es evidencia directa de compromiso.

Patron 4: multiples conexiones desde un mismo proceso

Un proceso que mantiene conexiones a varias IPs externas simultaneamente puede estar:

• Exfiltrando datos a multiples servidores de staging.
• Comunicandose con infraestructura C2 redundante (failover).
• Participando en una botnet con multiples nodos de control.

Patron 5: conexiones a la red interna desde procesos sospechosos

Conexiones al puerto 445 (SMB), 135 (RPC), 3389 (RDP) o 5985 (WinRM) hacia otros hosts internos indican movimiento lateral:

TCPv4  192.168.1.50  49833  10.0.0.25  445  ESTABLISHED  4321  malware.exe

El atacante esta usando SMB para acceder a otro sistema de la red.

Correlacion red-procesos

La potencia real del analisis de red en memoria es la correlacion directa con procesos. En logs de red tradicionales, solo ves IPs y puertos. En memoria, ves IPs, puertos Y el proceso responsable.

Flujo de correlacion:

1. Ejecutar netscan y filtrar conexiones ESTABLISHED a IPs externas.
2. Para cada conexion sospechosa, anotar el PID.
3. Ejecutar cmdline con ese PID para ver la linea de comandos.
4. Ejecutar dlllist con ese PID para ver que DLLs tiene cargadas.
5. Ejecutar malfind con ese PID para verificar si tiene codigo inyectado.
6. Buscar la IP destino en bases de datos de IOCs.

Ejemplo completo:

# Paso 1: conexiones sospechosas
vol -f memory.raw windows.netscan | grep ESTABLISHED | grep -v "10\.\|192\.168\.\|172\."

# Resultado: PID 5700 (powershell.exe) conectado a 185.100.87.202:443

# Paso 2: linea de comandos
vol -f memory.raw windows.cmdline --pid 5700
# Resultado: powershell.exe -nop -w hidden -enc SQBFAFg...

# Paso 3: DLLs cargadas
vol -f memory.raw windows.dlllist --pid 5700

# Paso 4: codigo inyectado
vol -f memory.raw windows.malfind --pid 5700

# Paso 5: verificar IP en threat intel
# Buscar 185.100.87.202 en MalwareBazaar, ThreatFox, OTX

Analisis de DNS en memoria

Las consultas DNS no se almacenan de forma estructurada en las estructuras de red del kernel. Sin embargo, hay varias formas de encontrar evidencia de DNS en memoria:

Cache DNS del sistema. Windows mantiene un cache de DNS resuelto. El plugin dnsresolvercache de la comunidad puede extraerlo:

vol -f memory.raw windows.dnsresolvercache

Esto muestra dominios resueltos y las IPs asociadas, lo que puede revelar dominios C2 que ya no estan en la tabla de conexiones porque la conexion se cerro.

Strings en memoria de procesos de red. Buscar dominios en los strings de procesos como svchost.exe (que aloja el servicio DNS Client) o del proceso sospechoso:

vol -f memory.raw windows.strings --pid 5700 | grep -i "\.com\|\.net\|\.org\|\.ru\|\.cn"

Trafico UDP al puerto 53. Las consultas DNS son UDP al puerto 53. Si el dump se capturo mientras habia actividad DNS, puede haber sockets UDP visibles en netscan.

Deteccion de tuneling DNS

Algunos malware usan DNS como canal C2 (DNS tunneling). Las consultas DNS contienen datos codificados en subdominios largos, y las respuestas contienen comandos.

Indicadores en memoria:

• Multiples conexiones UDP al puerto 53 desde un proceso no estandar (no svchost.exe).
• Strings en memoria del proceso con subdominios inusualmente largos: a3f2b1c4d5e6f7.evil.com.
• DLLs de resolucion DNS cargadas en procesos que no deberian resolver nombres.

IPv6 y conexiones duales

No olvides las conexiones IPv6. Muchos analistas filtran solo TCPv4 y pierden conexiones maliciosas sobre IPv6:

vol -f memory.raw windows.netscan | grep TCPv6 | grep ESTABLISHED

Un atacante puede preferir IPv6 precisamente porque sabe que muchos defensores lo ignoran en sus filtros.

Conexiones cerradas: evidencia historica

Las conexiones con estado CLOSED o TIME_WAIT en netscan son evidencia historica. La conexion ya no esta activa, pero la estructura de datos del kernel aun no fue reciclada.

Esto es valioso porque:

• Muestra conexiones que existieron durante la ventana de actividad maliciosa.
• Puede revelar fases anteriores del ataque (descarga del payload, reconocimiento de red).
• Los timestamps de creacion ayudan a construir la linea temporal del incidente.

Sin embargo, hay que tener cuidado: las estructuras recicladas pueden contener datos parcialmente sobrescritos, produciendo falsos positivos con IPs o puertos incorrectos.

Caso practico: reconstruccion de actividad de red de un incidente

Dump de un servidor comprometido. Ejecutamos netscan y filtramos:

Proto   LocalAddr       LocalPort  ForeignAddr      ForeignPort  State        PID   Owner
TCPv4   10.0.1.100      49200      93.184.216.34    443          CLOSED       7800  certutil.exe
TCPv4   10.0.1.100      49350      185.100.87.202   443          ESTABLISHED  5700  powershell.exe
TCPv4   10.0.1.100      49400      10.0.1.25        445          ESTABLISHED  5700  powershell.exe
TCPv4   10.0.1.100      49401      10.0.1.30        445          ESTABLISHED  5700  powershell.exe
TCPv4   10.0.1.100      49402      10.0.1.35        3389         CLOSED       5700  powershell.exe
TCPv4   0.0.0.0         8080       0.0.0.0          0            LISTENING    5700  powershell.exe

Reconstruccion de la linea temporal:

1. certutil.exe descargo algo desde 93.184.216.34:443. certutil es un LOLBin (Living Off The Land Binary) frecuentemente abusado para descargar payloads. La conexion esta CLOSED, ya termino.

2. PowerShell establecio C2 con 185.100.87.202:443. Conexion ESTABLISHED, activa en el momento del dump.

3. Movimiento lateral via SMB a 10.0.1.25 y 10.0.1.30 (puerto 445). El atacante esta accediendo a otros servidores.

4. Intento de RDP a 10.0.1.35:3389. Conexion CLOSED, puede haber fallado o completado.

5. Listener en puerto 8080 desde PowerShell. El atacante abrio un puerto para recibir conexiones, posiblemente un reverse proxy o un web shell.

Esta reconstruccion, combinada con el analisis de procesos y cmdline, proporciona un panorama completo del incidente que ningun log individual podria ofrecer.

Limitaciones del analisis de red en memoria

Conexiones efimeras. Las conexiones que se abren y cierran rapidamente pueden no dejar rastro si la estructura se reciclo antes de la captura.

Cifrado. Memoria muestra IPs, puertos y el proceso, pero no el contenido del trafico. Si la comunicacion es HTTPS, no veras las URLs ni los datos transmitidos (aunque strings del proceso puede revelar URLs en texto plano si el malware no cifra su propia memoria).

Falsos positivos en estructuras recicladas. Datos parciales de conexiones anteriores pueden mezclarse con datos de conexiones nuevas, produciendo entradas con combinaciones de IP/puerto que nunca existieron juntas.

Volumen de datos. Un servidor activo puede tener miles de conexiones. El filtrado y priorizacion son esenciales para no perder tiempo en trafico legitimo.

Proximo paso

El siguiente articulo profundiza en la deteccion de codigo inyectado con malfind: analisis de VADs, regiones con permisos PAGE_EXECUTE_READWRITE, y como distinguir inyeccion real de falsos positivos.