DevOps Nightmare: una cadena DFIR pensada para leer compromiso, persistencia y exfiltración
Un paquete forense donde reconstruir una intrusión entera cruzando auth.log, syslog y un pcap, del acceso inicial a la exfiltración.
Avanzado · Linux
URL del reto: labs.thehackerslabs.com/machines/155
Por qué la diseñé
DevOps Nightmare es una máquina para reconstruir una intrusión a partir de evidencias dispersas, cruzando autenticación, actividad de sistema, tráfico de red y rastros de exfiltración. La planteé como una cadena coherente donde cada artefacto responde a una fase del ataque, no como pruebas aisladas. La monté para que la resolución premie leer el incidente con criterio más que memorizar comandos.
La secuencia reproduce errores que no son exclusivos de un CTF, credenciales expuestas, ejecución de un payload traído desde fuera, un listener sin autorizar y una transferencia interna que termina saliendo del entorno. El valor está en entender por qué la cadena tiene sentido y qué evidencia deja cada fase.
La máquina de un vistazo
Esto se lee, no se ataca. Es un paquete de evidencias con un auth.log, un syslog, una captura network.pcap y una base de datos de contexto. Con esas fuentes hay que reconstruir la historia entera, acceso inicial por credenciales, descarga de un payload, persistencia con un listener, salto a un servidor interno y exfiltración de un fichero sensible.
Cómo la monté, paso a paso
El acceso inicial, enterrado en el ruido del auth.log
En el auth.log metí mucho tráfico legítimo, accesos válidos por clave pública, para que no hubiera un log limpio. La pista buena aparece al apartar ese ruido, un Failed password seguido de un Accepted password para el mismo usuario, developer1, desde la misma IP y en una ventana muy corta. No hacía falta una fuerza bruta masiva, bastaba una transición mínima entre falló y entró. Quería enseñar que el acceso inicial pocas veces es una firma espectacular, y que verlo depende más de filtrar bien el ruido que de buscar indicadores complejos.
La descarga del payload, en el syslog
La siguiente evidencia lleva a lo que hizo el intruso después de entrar. En el syslog dejé una línea de wget con la URL en Base64, que decodificada apunta a un script servido desde un dominio externo. La codificación no pretende ser malware avanzado, enseña otra cosa, que muchos indicadores no están ocultos, solo empaquetados lo justo para que una revisión superficial los pase por alto. Y representa un patrón muy común, tras entrar, el atacante trae un script desde fuera y se apoya en utilidades del propio sistema.
La persistencia que solo se ve cruzando red y sistema
La persistencia no la dejé resuelta en un único log. Primero aparece como anomalía en la captura, una conexión en un puerto alto fuera de lo esperado, el 54321, y solo después se confirma en el syslog con un listener abierto en ese puerto. Quería forzar la lectura cruzada, la persistencia rara vez se descubre por una firma inequívoca, se descubre juntando dos hechos discretos, un patrón de red raro y un rastro local que explica quién abrió el canal.
El movimiento lateral, con el nombre en otra fuente
Después empujé la investigación hacia dentro de la red. En la captura se ve una conexión saliente hacia una IP interna, y el nombre de ese activo no está en el pcap, está en el syslog, en una línea de firewall que añade dbmaster01 a una whitelist. Quería enseñar dos cosas, que el movimiento lateral no siempre deja el nombre en la captura y hay que buscarlo en otra fuente, y que un atacante con un punto de apoyo salta a un servidor de base de datos accesible en cuanto lo detecta, porque es un activo de más valor.
La exfiltración, leída del propio payload
El cierre identifica qué salió del entorno. En el payload de una transferencia desde el servidor interno hacia la IP atacante dejé el nombre del fichero robado en hexadecimal, que reconstruido da un dump de base de datos comprimido. Quería que se viera que la exfiltración no siempre exige reconstruir el archivo entero, a veces basta con recuperar un prefijo, un nombre o unos metadatos del flujo para saber qué salió y desde dónde, sobre todo cuando la captura es parcial.
Qué quería enseñar
DevOps Nightmare es una cadena de fallos y evidencias, no una sucesión de adivinanzas. Obliga a relacionar acceso inicial, ejecución posterior, persistencia, movimiento lateral y exfiltración bajo una lógica reconocible en un incidente. Una investigación sólida depende de leer contexto, tiempos y relaciones entre artefactos, no de encontrar una bala de plata en un solo archivo.
| Fase | Qué enseña | Error que representa |
|---|---|---|
| Acceso inicial | Correlar fallo y éxito de autenticación | Credenciales comprometidas en una cuenta con SSH |
| Descarga de payload | Rastrear la ejecución posterior al login | Descarga y ejecución de contenido externo sin control |
| Persistencia | Validar una anomalía de red con el sistema | Listener no autorizado en un puerto alto |
| Movimiento lateral | Relacionar tráfico interno con metadatos del entorno | Segmentación insuficiente entre sistemas internos |
| Exfiltración | Sacar indicadores del archivo desde un payload parcial | Poca visibilidad sobre las salidas de datos |
Cuando varias debilidades pequeñas conviven en el mismo entorno, el impacto lo marca su combinación, no cada fallo por separado.