¿Qué es un Cold Boot Attack?
Un Cold Boot Attack es una técnica de ataque físico que aprovecha que los módulos de RAM retienen su contenido durante unos segundos (o minutos) después de apagar el equipo. Un atacante puede reiniciar el sistema con un SO desde un USB y volcar la RAM antes de que se borre, recuperando claves de cifrado, contraseñas o datos sensibles.
Este lab simula esa situación: el sistema sufrió un apagado inesperado y el SO preservó automáticamente tres volcados de memoria. Parte de la flag quedó fragmentada en esos dumps — debes recuperarla usando herramientas de análisis forense.
Objetivo
Recuperar los tres fragmentos de la flag embebidos en los volcados de memoria y ensamblarlos manualmente para obtener la flag completa.
Flujo de ataque
Solución paso a paso
Escaneamos el objetivo con nmap:
nmap -sV -p 8080 <LAB_IP>
# Output esperado:
PORT STATE SERVICE VERSION
8080/tcp open http SimpleHTTP/0.6 Python/3.9
Solo hay un servicio: el servidor web en el puerto 8080.
Accedemos al servicio web:
curl http://<LAB_IP>:8080/
La página muestra un monitor de temperatura de CPU con una advertencia crítica:
⚠ WARNING: Abnormal shutdown detected on last boot
Memory integrity check: FAILED
3 core dumps preserved → /debug/
Accedemos al directorio de debug:
curl http://<LAB_IP>:8080/debug/
Vemos tres ficheros disponibles para descarga. Los descargamos todos:
wget http://<LAB_IP>:8080/debug/coredump.1 wget http://<LAB_IP>:8080/debug/coredump.2 wget http://<LAB_IP>:8080/debug/coredump.3
Cada fichero pesa ~200 KB. Son ficheros binarios con contenido de memoria simulado.
strings extrae todas las cadenas de texto imprimibles de un fichero binario (por defecto, mínimo 4 caracteres ASCII consecutivos).
strings coredump.1
Entre el ruido de strings del sistema (rutas de librerías, mensajes del kernel) aparece el primer fragmento:
GhostLabs{c0ld_
strings coredump.1 | grep -i ghostPrimero intentamos con strings:
strings coredump.2
No aparece ningún fragmento de la flag. El fragmento está almacenado con un byte \x00 entre cada carácter — strings lo ignora porque necesita bytes imprimibles consecutivos y los nulls rompen la cadena.
Usamos hexdump -C, que muestra el volcado hexadecimal con la representación ASCII en la columna derecha:
hexdump -C coredump.2 | less
En la columna ASCII de la derecha verás el fragmento con puntos entre cada carácter (los puntos son los bytes \x00):
00012f00 62 00 30 00 30 00 74 00 5f 00 6d 00 33 00 6d 00 |b.0.0.t._.m.3.m.| 00012f10 30 00 72 00 79 00 5f 00 00 00 00 00 00 00 00 00 |0.r.y._......... |
Leyendo solo los bytes imprimibles de la columna derecha obtenemos el segundo fragmento:
b00t_m3m0ry_
hexdump -C coredump.2 | grep "62 00 30" — busca la secuencia hex de b\x00strings coredump.3
Entre el ruido aparece el tercer y último fragmento:
f0r3ns1cs}
Concatenamos los tres fragmentos en orden:
| Origen | Fragmento | Técnica |
|---|---|---|
| coredump.1 | GhostLabs{c0ld_ | strings |
| coredump.2 | b00t_m3m0ry_ | hexdump -C |
| coredump.3 | f0r3ns1cs} | strings |
Referencia de herramientas
strings — extrae cadenas de texto imprimibles de ficheros binarios:
strings <fichero> # mínimo 4 chars consecutivos (defecto) strings -n 6 <fichero> # mínimo 6 chars strings <fichero> | grep -i ghost # filtrar por palabra clave
hexdump -C — volcado hexadecimal con columna ASCII a la derecha. Los bytes no imprimibles aparecen como .:
hexdump -C <fichero> # volcado completo hexdump -C <fichero> | less # paginar hexdump -C <fichero> | grep "patrón hex"
strings lo ignora pero hexdump -C lo hace visible.Remediación
# 1 — Nunca exponer endpoints de diagnóstico sin autenticación # /debug/, /status/, /admin/ deben requerir credenciales o estar en red privada # 2 — Los volcados de memoria pueden contener credenciales y claves # Nunca almacenarlos en rutas accesibles desde la web # Cifrarlos si deben conservarse para análisis # 3 — Cifrar el disco completo evita que un Cold Boot Attack real # recupere datos útiles del volcado de RAM