NexaCorp DFIR: INC-2026-001 - Compromiso de Infraestructura Linux

Investigación DFIR e ingeniería de detección sobre una intrusión simulada contra la infraestructura de NexaCorp. Realizada como un encargo individual de 4 días (bootcamp Blue & Red Team de BeCode Bruselas, Misión 01). El entregable es un informe de hallazgos de 54 páginas (PDF) más 7 reglas de Suricata validadas que detectan el incidente capturado en el replay de PCAP.

Este repositorio documenta un encargo de analista SOC realizado como parte del Bootcamp de Ciberseguridad de BeCode (promoción 2025-2026). Reconstruye una intrusión completa a partir de evidencia de red y registros, y entrega un conjunto validado de reglas de detección de Suricata. Es el primer incidente de la serie NexaCorp DFIR.

Contenido

• Aviso operativo
• De un vistazo
• Contexto del encargo
• Resumen ejecutivo
• Resumen de la cadena de ataque
• Cómo leer este informe
• Metodología
• Herramientas utilizadas
• Resumen de hallazgos
• Ingeniería de detección
• Estructura del repositorio
• Reproducibilidad
• Limitaciones conocidas
• Serie NexaCorp DFIR
• Agradecimientos
• Acerca de
• Licencia

Aviso operativo

Esto es un encargo de laboratorio contra infraestructura ficticia. NexaCorp es un cliente ficticio utilizado como escenario para la Misión 01 de BeCode Bruselas. El host comprometido es una VM Metasploitable 2 intencionalmente vulnerable para formación en seguridad, y el implante Caldera Sandcat forma parte del laboratorio que enseña al analista cómo es el tráfico de beacon de un intruso real. Ninguna organización, red o persona real fue atacada.

Todas las direcciones IP, nombres de host e indicadores de compromiso publicados en este informe (172.16.50.10, 192.168.10.10, 10.40.0.200, blue11, mesdec, etc.) son artefactos locales de laboratorio, no inteligencia de amenazas del mundo real. No los alimentes a un SIEM como IOCs.

Publicación autorizada por el coach de laboratorio de BeCode (Thomas B.) el 2026-05-17. La Declaración de Confidencialidad completa aparece en el informe de hallazgos (sección "Distribución y Clasificación").

De un vistazo

Contexto del encargo

Escenario (ficticio). NexaCorp, un cliente corporativo de tamaño mediano, contactó al equipo azul de BeCode Corp después de que su monitoreo interno señalara tráfico saliente inesperado desde uno de sus servidores Linux internos. Su firewall registró el tráfico pero no generó ninguna alerta accionable. La dirección necesitaba una determinación antes de decidir sobre la divulgación y la notificación regulatoria.

Mandato. Investigar la ventana del incidente sospechado, caracterizar la vía de entrada del atacante y su actividad posterior a la explotación, evaluar lo que la pila de detección existente capturó (y omitió), y entregar un plan de remediación priorizado. Una segunda fase añadió ingeniería de detección: producir reglas IDS de red listas para desplegar que detectaran una recurrencia en tiempo real.

Paquete de evidencia recibido del cliente.

Contexto educativo. Este encargo se entregó durante el bootcamp Blue & Red Team de BeCode Bruselas (noviembre de 2025 a septiembre de 2026) como Misión 01: una investigación individual y con tiempo limitado que simula un encargo real de consultoría DFIR. La infraestructura de laboratorio, la identidad de NexaCorp y los valores IOC son deliberadamente ficticios. La metodología, las herramientas y el formato del informe siguen estándares del mundo real (NIST SP 800-61r2, SANS PICERL, MITRE ATT&CK).

Resumen ejecutivo

📄 El informe completo de hallazgos de 54 páginas es el entregable canónico. Descargar el PDF (215 KB) o explorar la fuente Markdown para búsqueda con grep y citas.

En la noche del 2026-05-09 a las 22:53 UTC, un atacante externo (172.16.50.10) comprometió un servidor interno de NexaCorp (192.168.10.10) explotando CVE-2011-2523, el backdoor presente en vsftpd 2.3.4 (una compilación documentada públicamente como comprometida desde julio de 2011). Una única petición FTP USER que terminaba con :) activó un shell root bind sin autenticación en TCP/6200. El atacante ejecutó 8 comandos de reconocimiento en una sesión de 20 segundos (sin persistencia, sin exfiltración, sin movimiento lateral a través de este vector de acceso) y se desconectó.

Independientemente, se descubrió que el mismo host ejecutaba un agente MITRE Caldera "Sandcat" preexistente en /opt/caldera/sandcat (root, demonizado) haciendo beacon cada 40-50 segundos en HTTP en claro hacia 10.40.0.200:8888 durante toda la ventana capturada. Esta es la "conexión saliente inusual" originalmente señalada por el cliente e indica un compromiso previo no representado en el paquete de evidencia (el implante ya estaba activo en la primera trama del PCAP).

El SIEM Wazuh existente ingirió 397 eventos del host objetivo pero solo generó 4 alertas de alta severidad (1,0% del total), todas clasificadas como fuerza bruta genérica (MITRE T1110). Ninguna identificó la carga útil del exploit CVE-2011-2523, el shell bind en TCP/6200 ni el canal C2 de Caldera: el byte del exploit (USER baduser:)) nunca es registrado por el propio vsftpd, y el SIEM no tenía telemetría de red para ver el resto. Las 7 reglas de Suricata entregadas en la Fase 2 cierran las tres brechas.

IOCs principales (limitados al laboratorio, no los alimentes a un SIEM real):

Resumen de la cadena de ataque

El incidente capturado tiene dos ramas distintas, reconstruidas a partir del PCAP:

1. Servicio expuesto: vsftpd 2.3.4, una compilación con un backdoor documentado públicamente (CVE-2011-2523), era accesible en la red interna (Hallazgo I1).
2. Exploit: una única petición FTP USER que terminaba con :) activó el backdoor (Hallazgo I3).
3. Shell root bind: se abrió un shell root sin autenticación en TCP/6200; el atacante ejecutó 8 comandos de reconocimiento en una sesión de 20 segundos y luego se desconectó, sin persistencia ni exfiltración a través de este vector (Hallazgo I4).
4. C2 paralelo (preexistente): de forma independiente, un implante MITRE Caldera Sandcat ya estaba haciendo beacon en HTTP en claro hacia 10.40.0.200:8888 durante toda la ventana, evidencia de un compromiso previo no representado en el paquete de evidencia (Hallazgo I5).

Cómo leer este informe

El repositorio está organizado para que puedas entrar en la profundidad adecuada según tu rol:

Entregable canónico: el PDF en reports/. La fuente Markdown tiene contenido idéntico, mantenida en el repositorio para facilitar la búsqueda y el control de versiones.

Rastro de la investigación: notes/journal.md es el cuaderno de trabajo del analista (hipótesis probadas y refutadas, inventario de evidencia, estado del plan). Complementa el informe formal mostrando cómo se alcanzaron las conclusiones, no solo las conclusiones en sí.

Conjunto de reglas de detección: detection/lab.rules contiene las 7 reglas de Suricata con justificación completa por palabra clave en comentarios en línea. detection/README.md documenta el flujo de trabajo de validación de despliegue y replay utilizado para confirmar que cada regla se activa en el incidente capturado.

Metodología

El encargo sigue tres marcos de referencia estándar de la industria combinados.

NIST SP 800-61r2: Guía de Manejo de Incidentes de Seguridad Informática

El modelo de 4 fases de NIST (Preparación, Detección y Análisis, Contención / Erradicación / Recuperación, Actividad posterior al incidente) proporciona la estructura de alto nivel. En este encargo, la Fase 1 del entregable se corresponde con "Detección y Análisis" de NIST (forensia de PCAP, correlación de SIEM, reconstrucción de la línea temporal del atacante). La Fase 2 se corresponde con "Lecciones aprendidas" de NIST, traducida en controles preventivos (las 7 reglas de Suricata y la lista priorizada de recomendaciones en la sección 7 del informe).

SANS PICERL: flujo de investigación táctica

PICERL (Preparación, Identificación, Contención, Erradicación, Recuperación, Lecciones aprendidas) es el Proceso de Respuesta a Incidentes de SANS. Aplicado en este encargo:

MITRE ATT&CK: mapeo de técnicas

Cada hallazgo se mapea a una o más técnicas de MITRE ATT&CK para permitir al cliente correlacionar este incidente con su modelo de amenazas existente. 14 técnicas distintas se referencian en los 10 hallazgos:

• Reconocimiento: T1595.002, T1592.002, T1589
• Acceso inicial: T1190 (Explotación de aplicación expuesta vía CVE-2011-2523)
• Ejecución: T1059.004 (Shell de Unix)
• Descubrimiento: T1033, T1082, T1087.001, T1083, T1016, T1049, T1046
• Acceso a credenciales: T1110 (Fuerza bruta)
• Comando y control: T1071.001, T1102 (beacon de Caldera Sandcat)
• Escalada de privilegios: T1078.003, T1548.003 (actividad sudo sospechosa)

La tabla completa de técnicas por hallazgo está en la sección 4 del informe (IOCs) y los análisis detallados por hallazgo en las secciones 3 y 5.

Reproducibilidad

Cada afirmación del informe es trazable a un artefacto del paquete de evidencia, con el filtro exacto de tshark, la consulta de Wazuh o el comando de replay de Suricata necesario para reproducirla. Consulta el Anexo A (Comandos de reproducibilidad) del informe y la sección Reproducibilidad más abajo para un inicio rápido.

Herramientas utilizadas

Forensia de red

• tshark: CLI de Wireshark para triaje de PCAP, reconstrucción de flujos TCP (-z follow,tcp,ascii), filtrado de protocolos y extracción de campos
• tcpreplay y tcprewrite: replay de PCAP sobre una interfaz de monitoreo en vivo para validación de reglas de Suricata, con ajuste de MTU para la ens19 del laboratorio (1450 bytes)
• Decodificadores Base64: reconstrucción de las cargas útiles C2 de Caldera Sandcat (cuerpo del beacon y respuesta del operador)

IDS de red / ingeniería de detección

• Suricata 6.0.4 (modo afpacket, un solo hilo, Hyperscan deshabilitado en el laboratorio): se redactaron, validaron y ajustaron las 7 reglas de este entregable
• suricata -T: validación de configuración y reglas durante el despliegue y ajuste
• kill -USR2 $(pgrep suricata): recarga de reglas en vivo durante el ajuste iterativo

SIEM y telemetría del host

• Wazuh (manager + dashboard): correlación de eventos, análisis de distribución de severidad, consulta de reglas (rule.id 11452, 5551, etc.), exportación CSV de 397 eventos
• Utilidades de texto estándar de Linux (grep, awk, jq): minería de registros y análisis de JSON

Contexto de emulación de adversario (referenciado, no operado)

• MITRE Caldera (agente Sandcat): presente en el host objetivo como el implante C2 preexistente simulado que se está caracterizando

Marcos de referencia

• NIST SP 800-61r2: Guía de Manejo de Incidentes de Seguridad Informática
• SANS PICERL: flujo de investigación táctica
• MITRE ATT&CK: atribución de técnicas
• Aviso CVE-2011-2523: referencia del backdoor de vsftpd 2.3.4

Resumen de hallazgos

Los 10 hallazgos (I1 a I10) están documentados en detalle en el informe de hallazgos. Cada entrada incluye evidencia, comandos de reproducibilidad, mapeo MITRE ATT&CK y orientación de remediación.

Distribución de severidad: 3 CRÍTICOS / 3 ALTOS / 2 MEDIOS / 2 BAJOS

Orden de lectura recomendado: comienza con I1 (el servicio vulnerable), luego I3 y después I4 (la cadena de explotación real), y luego I5 (el implante C2 paralelo y no relacionado). I2 e I6 proporcionan el contexto de reconocimiento. I7 a I10 son los hallazgos de postura defensiva (lo que el monitoreo vio frente a lo que omitió).

Ingeniería de detección

La Fase 2 del encargo produjo 7 reglas de Suricata (SID 9000001 a 9000007) que cubren el incidente capturado desde tres ángulos: la firma del exploit, el shell posterior al exploit y el canal C2 paralelo. Cada regla se valida mediante replay de PCAP sin conexión contra una instancia de Suricata 6.0.4 en la estación de trabajo del SOC.

Las 7 reglas

Resumen de validación

La diferencia entre 40 y 314 refleja una limitación deliberada en las reglas 9000003, 9000004, 9000005 y 9000006 para dar a los analistas del SOC una vista operativa limpia, preservando al mismo tiempo el flujo de alertas crudas en eve.json para análisis forenses en profundidad.

Decisiones de diseño destacadas

Cuatro correcciones iterativas durante el despliegue están documentadas en detection/README.md. Lecciones clave:1. Detección HTTP independiente del puerto. Las reglas 9000004 y 9000005 (Caldera) se escribieron inicialmente con las palabras clave alert http y http.uri, que solo activan el analizador HTTP de Suricata en el puerto 80. Caldera C2 se ejecuta en el puerto 8888, por lo que el analizador se omitía y las reglas nunca se disparaban. Corrección: reescribir en modo TCP+content (alert tcp ... content:"POST /beacon"; content:"Go-http-client/1.1";) que coincide con los bytes HTTP brutos independientemente del puerto. 2. flow:established no es fiable durante la reproducción de PCAP. Un handshake TCP capturado fuera de la ventana de reproducción deja la máquina de estados del flujo en un estado indeterminado. Eliminar flow:established de las reglas de Caldera hace que coincidan tanto en modo en vivo como en reproducción. 3. Dirección de flujo explícita para reglas solo SYN. La regla 9000003 (puerto 6200) generó SC_WARN_POOR_RULE: SYN-only ... w/o direction specified. Se corrigió añadiendo flow:to_server,not_established. 4. HOME_NET vs en laboratorios solo RFC1918. Cuando el atacante, el objetivo y el C2 están todos en espacio privado, queda vacío y las reglas de la forma nunca coinciden. Corrección de laboratorio: usar en ambos campos. Corrección de producción: restringir solo al segmento protegido.

Consideraciones sobre falsos positivos

El análisis de falsos positivos por regla está documentado en la sección 8.5 del informe. La mayoría de las reglas conllevan un riesgo insignificante en un entorno bien delimitado; las reglas 9000005 (cabecera de servidor aiohttp) y 9000006 (curl/Wget en rutas de administración) requieren ajuste si existen servicios internos Python benignos o scripts administrativos.

Estructura del repositorio```text

NexaCorp-DFIR-INC-2026-001/ ├── README.md (this file) ├── LICENSE (MIT) ├── .gitignore ├── .github/ │ └── workflows/ │ └── ci.yml markdownlint + typography + Suricata rule check ├── reports/ │ ├── INC-2026-001_Findings_Report.pdf canonical 54-page deliverable │ └── INC-2026-001_Findings_Report.md same content, Markdown source ├── detection/ │ ├── lab.rules 7 Suricata rules (SID 9000001-9000007) │ └── README.md deploy + replay validation workflow ├── evidence-summary/ │ └── ioc-summary.md indicators of compromise (SIEM-ingestible) ├── methodology/ │ ├── attack-timeline.md incident timeline (UTC) │ └── attck-mapping.md MITRE ATT&CK mapping table └── notes/ └── journal.md analyst investigation journal (hypotheses, plan, IOCs, timeline)

**Clasificaciones de archivos:**

| Ruta | Rol | Audiencia |
|---|---|---|
| `reports/*.pdf` | Entregable canónico, informe formal | Cliente, reclutador, auditor |
| `reports/*.md` | Mismo contenido, fuente compatible con grep | Cualquier persona que cite o haga diff |
| `detection/lab.rules` | Conjunto de reglas Suricata listo para producción | SOC / ingeniero de detección |
| `detection/README.md` | Guía de despliegue + validación mediante reproducción | Onboarding de ingeniero de detección |
| `evidence-summary/ioc-summary.md` | Indicadores de compromiso, por categoría | SOC / caza de amenazas |
| `methodology/attack-timeline.md` | Cronología del incidente (UTC) | Profesional de DFIR |
| `methodology/attck-mapping.md` | Tabla de mapeo MITRE ATT&CK | DFIR / ingeniero de detección |
| `notes/journal.md` | Cuaderno de trabajo de la investigación | Profesional de DFIR que estudia el método |
| `.github/workflows/ci.yml` | Validación automatizada de markdownlint, tipografía y reglas Suricata (`suricata -T`, se ejecuta cuando `detection/*.rules` está presente) al hacer push | CI |

## Reproducibilidad

Cada afirmación del informe de hallazgos es trazable a un artefacto del paquete de evidencia. El PCAP en sí no se redistribuye (propiedad del laboratorio BeCode), pero los comandos y las consultas están documentados para que cualquiera que tenga su propia copia pueda reproducir el análisis.

### Reproducir los hallazgos clave (análisis de PCAP)

Requiere `tshark` (CLI de Wireshark) y el `attack.pcap` original:```bash
# 1. PCAP overview
tshark -r attack.pcap -q -z io,stat,0

# 2. TCP conversations (reveals attacker, target, C2)
tshark -r attack.pcap -q -z conv,tcp | head -30

# 3. Confirm vsftpd 2.3.4 banner exposure (Finding I1)
tshark -r attack.pcap -Y "ftp && ip.src == 192.168.10.10" \
  -T fields -e frame.time -e ftp.response.code -e ftp.response.arg | head -5

# 4. Find the CVE-2011-2523 exploit payload (Finding I3)
tshark -r attack.pcap -Y 'ftp.request.command == "USER"' \
  -T fields -e frame.time -e ftp.request.arg

# 5. Reconstruct the root shell session on TCP/6200 (Finding I4)
tshark -r attack.pcap -q -z follow,tcp,ascii,70

# 6. Reconstruct the Caldera C2 beacon (Finding I5)
tshark -r attack.pcap -q -z follow,tcp,ascii,6 | head -50

Reproducir validación de reglas (reproducción de Suricata)

Requiere Suricata 6.0.x, tcpreplay, y una interfaz monitoreada (ens19 en el laboratorio; sustituye por la tuya):```bash

1. Install the ruleset

sudo cp detection/lab.rules /etc/suricata/rules/learner/lab.rules

2. Hot-reload Suricata without restart

sudo kill -USR2 $(pgrep -f suricata) sleep 5

3. Clear the alert log for a clean baseline

sudo truncate -s 0 /var/log/suricata/fast.log

4. Replay the PCAP at top speed

sudo tcpreplay --intf1=ens19 --topspeed attack_mtu.pcap

5. Count alerts per rule (expect 7 distinct SIDs)

sudo grep -oE '[1:[0-9]+:' /var/log/suricata/fast.log | sort | uniq -c | sort -rn

I don't see any content to translate—the input after "INPUT:" is empty. If you resend the chunk text, I'll translate it into Spanish following all the formatting rules.```text
     30 [1:9000002:    (vsftpd banner repeated per session)
      3 [1:9000007:    (FTP USER enumeration threshold)
      3 [1:9000006:    (HTTP admin path enumeration)
      1 [1:9000005:    (Caldera C2 response)
      1 [1:9000004:    (Caldera Sandcat beacon, throttled)
      1 [1:9000003:    (Backdoor port 6200 SYN)
      1 [1:9000001:    (vsftpd USER smiley exploit)

Las 7/7 reglas se disparan correctamente. El paquete de evidencia completo (fast.log, eve.json, configuración de throttling, instantánea de la versión de Suricata) se enumera en el Anexo E del informe de hallazgos.

Limitaciones conocidas

• El paquete de evidencia comienza a mitad del incidente. El PCAP comienza el 2026-05-09 a las 20:08 UTC, pero el agente Caldera Sandcat ya está haciendo beaconing activamente en la trama 1. El compromiso inicial que instaló el implante ocurrió antes y no está representado en los datos. Las conclusiones sobre la actividad previa al implante se extrapolan de los campos full_log de Wazuh, no se observan directamente.
• Los registros de auditoría del host no se superponen con la ventana de ataque. Los auth.log y syslog locales comienzan ~5 horas después de que finaliza el PCAP, siendo la primera entrada syslogd restart (probablemente reinicio de la VM). No se proporcionaron archivos de registro rotados. Esto está documentado como Hallazgo I10.
• El alcance fue forense + ingeniería de detección, no respuesta en vivo. La contención, erradicación, adquisición forense (imagen de memoria, imagen de disco) y enumeración de persistencia están documentadas como recomendaciones P0 en el informe, pero no se ejecutaron: el compromiso no tuvo acceso en vivo al host. Se requeriría un compromiso de seguimiento para cerrar esos ciclos.
• Las 7 reglas de Suricata detectan esta firma específica del incidente. Un atacante sofisticado puede evadirlas cambiando el patrón de bytes del exploit (terminadores alternativos de byte nulo en el argumento USER), recompilando Caldera con un User-Agent diferente, o moviendo el C2 a HTTPS cifrado (el análisis de metadatos TLS como JA3/JA4 sería el plan de respaldo). Las reglas son apropiadas para el escenario de amenaza capturado; la estrategia de detección a largo plazo debería añadir detecciones basadas en comportamiento y metadatos.
• Brecha de ingesta de Wazuh durante la investigación. La canalización de ingesta de registros del SIEM estuvo temporalmente no disponible hasta el 2026-05-11 a las 11:39 UTC (a mitad de la investigación, restaurada por el coach del laboratorio). Las 4 alertas de alta severidad aparecen por tanto en el panel con (11 de mayo 13:17-13:28) en lugar de las marcas de tiempo reales del incidente (9 de mayo 21:00-22:53), lo que distorsiona el momento aparente de los eventos de correlación.

Serie DFIR de NexaCorp

• INC-2026-001: este repositorio
• INC-2026-002: escalación de privilegios y persistencia (Tor SSH, SUID, cuenta backdoor)
• INC-2026-003: evaluación transversal de incidentes del mes 1
• INC-2026-004: inyección SQL (portal web)
• INC-2026-005: inyección de comandos del SO y web shell (portal web)
• INC-2026-006: XSS almacenado y secuestro de sesión (portal web)
• INC-2026-007: IDOR y control de acceso roto (NexaPortal); proyecto final del mes 2
• INC-2026-008: reconocimiento de AD y Kerberoasting (primer incidente del mes 3)

Agradecimientos

• Thomas B. (coach de laboratorio de BeCode): diseño del escenario, corrección de la ingesta de Wazuh a mitad de la investigación, autorización de publicación para uso en portafolio.
• MITRE por el framework Caldera que impulsó el implante C2 simulado, y por la base de conocimiento ATT&CK utilizada para mapear cada hallazgo.
• Proyecto Suricata por el motor que hizo posible desplegar las 7 reglas en menos de 30 minutos.

Acerca de

Compromiso DFIR en solitario entregado durante el bootcamp Blue & Red Team de BeCode Brussels (noviembre de 2025 a septiembre de 2026), Misión 01, el 2026-05-15.

Autor: Johan-Emmanuel Hatchi (LinkedIn).

Abierto a oportunidades de prácticas en ciberseguridad a partir de septiembre de 2026 en Bélgica. Buscando roles de SOC / DFIR / ingeniería de detección donde este tipo de trabajo de investigación de extremo a extremo (forense de PCAP, correlación SIEM, redacción de reglas IDS, informes formales al cliente) esté dentro del alcance.

Licencia

MIT, 2026 Johan-Emmanuel Hatchi.

Las reglas de Suricata en detection/lab.rules y el texto del informe se publican bajo la misma licencia MIT: libres de copiar, adaptar y redistribuir con atribución. El PCAP, la infraestructura del laboratorio y los briefings del compromiso siguen siendo propiedad de BeCode Brussels y no se redistribuyen.