Adquisición forense: memoria y disco

Aviso legal y ético: este módulo tiene fines exclusivamente educativos, dentro de un laboratorio controlado (máquinas virtuales propias o entornos autorizados por escrito). La adquisición forense sobre sistemas de terceros sin autorización expresa constituye delito en la práctica totalidad de jurisdicciones (en España, arts. 197 y ss. del Código Penal sobre descubrimiento y revelación de secretos, y la Ley Orgánica de Protección de Datos si hay datos personales implicados). Toda evidencia digital destinada a un procedimiento judicial o disciplinario debe cumplir tres requisitos no negociables: integridad (la copia es idéntica bit a bit al original, demostrable mediante hash), cadena de custodia (documentación ininterrumpida de quién tuvo acceso a la evidencia, cuándo y qué hizo con ella) y repetibilidad (un tercero con las mismas herramientas debe poder llegar a las mismas conclusiones). Un solo error de procedimiento —montar un disco en modo escritura, apagar una máquina comprometida sin capturar memoria, olvidar documentar un hash— puede invalidar meses de investigación o hacer inadmisible la evidencia ante un tribunal. Trabaja siempre en modo laboratorio, con snapshots y máquinas virtuales que puedas destruir y recrear, y jamás sobre infraestructura de producción real sin autorización explícita y por escrito.

Qué aprenderás

Por qué el orden en que capturas evidencia importa tanto como la evidencia misma, y qué dice el RFC 3227 al respecto.
La diferencia entre live response (adquisición en caliente) y análisis post-mortem, y cuándo aplicar cada estrategia.
Cómo capturar memoria RAM en Windows (WinPMEM, DumpIt, Magnet RAM Capture) y en Linux (LiME, avml) con comandos reales.
Cómo obtener una imagen forense de disco con FTK Imager, dd, dc3dd y ewfacquire, y por qué el formato E01/EWF es preferible a un raw plano en la mayoría de casos.
Cómo hacer triage rápido con KAPE (targets y modules) y con herramientas de colección remota como Velociraptor y CyLR.
Qué son los write blockers (hardware y software) y por qué son obligatorios al trabajar sobre el disco original.
Cómo verificar la integridad de una adquisición mediante hashing antes/después y cómo documentar la cadena de custodia.

1. Por qué la fase de adquisición lo condiciona todo

En un caso de respuesta a incidentes o de forense digital, la fase de adquisición es el único momento en que interactúas directamente con la evidencia original. A partir de ahí, todo el análisis se realiza sobre copias. Si la adquisición se hace mal —sin write blocker, sin verificación de hash, alterando timestamps, apagando un sistema comprometido antes de capturar la memoria— el daño es irreversible. No hay forma de «deshacer» el arranque de un sistema Windows que ha modificado cientos de archivos de registro y logs de eventos, ni de recuperar una memoria RAM que se ha perdido al cortar la alimentación.

El estándar de referencia para el orden de captura es el RFC 3227 — «Guidelines for Evidence Collection and Archiving» (Brezinski & Killalea, IETF, 2002), que sigue siendo la cita canónica en cualquier certificación GCIH/GCFE/GCFA pese a su antigüedad, porque el principio que enuncia —capturar primero lo más volátil— no ha cambiado con la tecnología. Lo complementa el NIST SP 800-86 «Guide to Integrating Forensic Techniques into Incident Response», que detalla procedimientos y consideraciones legales para EE. UU. pero cuyo marco metodológico es perfectamente aplicable en cualquier jurisdicción.

2. El orden de volatilidad (RFC 3227)

La idea central es sencilla: cada tipo de dato tiene un «tiempo de vida» distinto tras un evento (apagado, reinicio, paso del tiempo). Debes capturar primero lo que desaparece antes. La tabla siguiente resume el orden descendente de volatilidad tal como lo define el RFC 3227, con las herramientas típicas para cada nivel.

Orden	Nivel de volatilidad	Qué capturar	Herramienta típica
1	Máxima — sobrevive segundos	Registros de CPU, caché, tabla de rutas, tabla ARP, tabla de procesos del kernel	`arp -a`, `netstat`, volcado de registros vía debugger de kernel (raro en IR estándar)
2	Muy alta — sobrevive mientras hay alimentación	Memoria RAM completa (procesos, conexiones de red activas, claves de cifrado en memoria, malware fileless)	WinPMEM, DumpIt, Magnet RAM Capture, LiME, avml
3	Alta — cambia constantemente	Estado de red: conexiones activas, sockets, tabla de enrutamiento, interfaces	`netstat -ano`, `ss -tupn`, capturas de tráfico (tcpdump/Wireshark) si procede
4	Media — procesos y sesiones en ejecución	Procesos en ejecución, DLLs cargadas, usuarios conectados, servicios activos, tareas programadas	`tasklist /v`, `pslist`, `ps aux`, KAPE (targets de live triage)
5	Baja — persiste tras apagado, pero mutable	Contenido del disco: sistema de archivos, ficheros temporales, swap/pagefile, hibernación	FTK Imager, dd, dc3dd, ewfacquire
6	Muy baja — remota, requiere terceros	Logs remotos: SIEM, servidor syslog centralizado, logs de firewall/proxy, autenticación en AD/Entra ID	Exportación desde SIEM (Splunk, Sentinel), `wecutil`, colección centralizada previa al incidente
7	Mínima — estable en el tiempo	Configuración física, topología de red, medios de backup, documentación de arquitectura	Inventario físico, diagramas de red, copias de UpdraftPlus/backup ya existentes

Un matiz importante que se pregunta a menudo en el examen GCIH: el orden de volatilidad no es una checklist estricta e inamovible, es un principio de priorización. Si tienes evidencia de que un atacante está exfiltrando datos activamente ahora mismo, capturar el estado de red (nivel 3) antes que completar la imagen de memoria puede estar justificado. El RFC 3227 lo dice explícitamente: el orden exacto depende del sistema y debe documentarse la justificación de cualquier desviación.

3. Live response vs. análisis post-mortem

Son dos estrategias de adquisición con supuestos y riesgos distintos, y elegir mal condiciona todo el caso.

Live response (adquisición en caliente) significa interactuar con el sistema mientras sigue encendido y en ejecución, para capturar el estado volátil (memoria, procesos, conexiones) antes de tocar nada más. Es obligatorio cuando:

Sospechas de malware fileless o que solo reside en memoria (Cobalt Strike beacon en memoria, inyección de proceso, PowerShell reflectivo).
Hay cifrado de disco completo (BitLocker, LUKS) y las claves solo están disponibles con el sistema desbloqueado y en RAM.
Necesitas evidencia de conexiones de red activas del atacante (C2, exfiltración en curso).
El coste de negocio de apagar el sistema es inasumible (servidor de producción crítico) y necesitas decidir con datos antes de aislarlo.

El riesgo del live response es la alteración de la evidencia: cada comando que ejecutas en el sistema comprometido modifica algo (crea procesos, escribe en el pagefile, actualiza timestamps de acceso). La mitigación estándar es usar un kit de live response con binarios estáticos, firmados y ejecutados desde medio externo (USB de solo lectura o red), nunca desde el propio disco del sistema comprometido, y documentar cada comando ejecutado con su hora exacta.

Análisis post-mortem (offline) significa apagar el sistema (o trabajar sobre una imagen ya extraída) y analizar una copia bit a bit sin que el sistema original se ejecute de nuevo. Es la opción preferida cuando:

El sistema ya está aislado o apagado y priorizas la integridad legal de la evidencia sobre la rapidez.
El caso probablemente terminará en un procedimiento judicial o disciplinario donde la repetibilidad estricta importa más que la velocidad.
No hay indicios de actividad de memoria relevante (por ejemplo, es un caso de exfiltración de ficheros por USB hace semanas, no un incidente activo).

En la práctica, un caso de respuesta a incidentes bien llevado combina ambos: live response inmediato para capturar memoria y estado volátil, seguido de imagen forense completa del disco para análisis post-mortem detallado. El error más común de analistas junior es apagar el sistema por reflejo («para que no siga haciendo daño») sin haber capturado la memoria antes: eso destruye para siempre la evidencia más volátil y a menudo la más incriminatoria.

4. Captura de memoria RAM

La memoria contiene lo que el disco no puede: procesos en ejecución con sus argumentos completos, claves de cifrado descifradas, contraseñas en texto claro que estaban en tránsito, malware inyectado en procesos legítimos que nunca toca disco, y el estado exacto de las conexiones de red en el momento de la captura. Es, con diferencia, la fuente de evidencia más rica en un incidente activo.

4.1 Windows — WinPMEM

WinPMEM (parte del proyecto Rekall/Velocidex, binario distribuido en GitHub como winpmem_mini_x64_rc2.exe o similar según versión) es la herramienta de referencia open source para capturar RAM en Windows. Genera un volcado en formato AFF4, que preserva metadatos y permite compresión.

# Ejecutar desde USB externo (nunca desde el disco del sistema comprometido)
E:winpmem_mini_x64_rc2.exe D:evidenciaCASO2026-014mem_host01.aff4

# Con hash SHA-256 automático y verbose
E:winpmem_mini_x64_rc2.exe --format aff4 --verbose D:evidenciaCASO2026-014mem_host01.aff4

# Comprobar la salida generada
certutil -hashfile D:evidenciaCASO2026-014mem_host01.aff4 SHA256

4.2 Windows — DumpIt (Magnet Forensics / Comae)

DumpIt es la opción más sencilla para primeros respondedores sin experiencia técnica profunda: doble clic, confirmación, y genera un volcado raw (.dmp o .raw) del mismo directorio donde se ejecuta.

# Ejecutar desde USB (interfaz interactiva, pide confirmación "y")
E:DumpIt.exe

# Versión con parámetros para automatizar en scripts de IR
E:DumpIt.exe /Q /O D:evidenciaCASO2026-014mem_host01.raw

4.3 Windows — Magnet RAM Capture

Gratuita, con interfaz gráfica, genera volcado raw (.raw) y calcula automáticamente MD5/SHA-1 al finalizar. Útil cuando el primer respondedor no es forense de formación y necesita un flujo guiado.

# Uso típico: interfaz gráfica -> seleccionar carpeta destino -> Start
# Genera automáticamente:
#   mem_host01.raw
#   mem_host01.raw.md5
#   mem_host01.raw.sha1

4.4 Linux — LiME (Linux Memory Extractor)

LiME se compila como módulo del kernel (.ko) específico para la versión exacta del kernel de la máquina objetivo — es su mayor limitación operativa: necesitas compilarlo contra los headers correctos, idealmente antes del incidente (kit de IR preparado por SO/kernel objetivo) o en un sistema con el mismo kernel.

# Compilación (en sistema idéntico o con headers del kernel objetivo)
git clone https://github.com/504ensicsLabs/LiME.git
cd LiME/src
make

# Carga del módulo y volcado a fichero local
sudo insmod lime-$(uname -r).ko "path=/mnt/usb/mem_host02.lime format=lime"

# Volcado vía red a un servidor de recolección (evita escribir en el disco objetivo)
sudo insmod lime.ko "path=tcp:4444 format=lime"
# En la máquina receptora:
nc -l -p 4444 > mem_host02.lime

# Descargar el módulo tras la captura
sudo rmmod lime

4.5 Linux — avml (Azure Volatile Memory Loader, Microsoft)

avml es un binario estático de Microsoft, sin dependencias de compilación contra el kernel, lo que lo hace mucho más práctico que LiME en un kit de IR portátil.

# Descarga del binario estático (preparar antes del incidente)
wget https://github.com/microsoft/avml/releases/latest/download/avml
chmod +x avml

# Captura básica
sudo ./avml /mnt/usb/mem_host03.lime

# Con compresión y exclusión de rangos no mapeados
sudo ./avml --compress /mnt/usb/mem_host03.lime.lz4

Regla de oro para cualquiera de estas herramientas: captura primero, analiza después, y jamás analices sobre el original. En cuanto termine el volcado, calcula el hash inmediatamente y anótalo en la cadena de custodia antes de mover el fichero a ningún otro sitio.

5. Imagen forense de disco

A diferencia de una copia normal de ficheros, una imagen forense captura el disco bit a bit, incluyendo espacio no asignado, ficheros borrados no sobrescritos, slack space y metadatos del sistema de ficheros. Es la única forma de garantizar que el análisis posterior (recuperación de borrados, timeline forense, carving) tiene toda la información disponible.

5.1 Write blockers: la primera línea de defensa

Antes de conectar el disco original a cualquier equipo, se debe interponer un write blocker, que impide físicamente (hardware) o a nivel de driver (software) cualquier operación de escritura hacia el disco fuente.

Write blockers hardware: dispositivos dedicados como Tableau T35689, WiebeTech Forensic UltraDock, o CRU WriteBlocker, que se conectan entre el disco y el puerto SATA/USB del equipo forense. Es la opción preferida en cualquier caso con destino judicial, porque el bloqueo ocurre a nivel eléctrico/firmware, fuera del alcance del sistema operativo.
Write blockers software: en Windows, la clave de registro HKLMSYSTEMCurrentControlSetControlStorageDevicePolicies con el valor DWORD WriteProtect = 1 fuerza modo de solo lectura para dispositivos USB a nivel de driver. Es una opción válida para triage rápido, pero menos defendible ante un tribunal que un bloqueador hardware certificado.

# Activar write-protect por software en Windows (PowerShell, admin)
New-Item -Path "HKLM:SYSTEMCurrentControlSetControlStorageDevicePolicies" -Force
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlStorageDevicePolicies" -Name "WriteProtect" -Value 1
# Revertir tras finalizar la adquisición:
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlStorageDevicePolicies" -Name "WriteProtect" -Value 0

5.2 FTK Imager (AccessData/Exterro)

FTK Imager es el estándar de facto en el sector para adquisición de disco con interfaz gráfica. Gratuito, soporta salida raw (dd), SMART (E01/AD1) y genera automáticamente un fichero de log con hashes MD5 y SHA-1 verificados.

# Flujo típico en FTK Imager:
# File > Create Disk Image > seleccionar Physical Drive (disco tras write blocker)
# Add > Image Type: E01
# Case Information: nº de caso, examinador, referencia de evidencia
# Destination: ruta local con espacio suficiente (>= tamaño del disco origen)
# Marcar "Verify images after they are created" (obligatorio)

# Versión de línea de comandos (FTK Imager CLI, para automatizar en IR)
FTKImager.exe D: E:evidenciaCASO2026-014disco_host01 --e01 --frag 2000 --compress 6

5.3 dd — la herramienta base en sistemas Unix/Linux

dd es la utilidad Unix más básica para copiar bit a bit, disponible en cualquier live-CD forense sin instalar nada. Su limitación: no calcula hash por sí sola, no gestiona sectores dañados con elegancia, y no incluye metadatos del caso.

# Imagen raw desde disco físico a fichero, con bloque de 4K (rendimiento razonable)
sudo dd if=/dev/sdb of=/mnt/evidencia/disco_host01.dd bs=4096 conv=noerror,sync status=progress

# Cálculo de hash inmediatamente después (obligatorio)
sha256sum /mnt/evidencia/disco_host01.dd > /mnt/evidencia/disco_host01.dd.sha256
sha256sum /dev/sdb   # comparar contra el hash calculado sobre el disco original si aún es accesible

5.4 dc3dd — dd forense con hashing integrado

dc3dd (desarrollado por el DoD Cyber Crime Center) es una versión de dd con extensiones forenses: hash en tiempo real durante la copia, log automático y verificación de progreso. Es preferible a dd plano siempre que esté disponible.

# Imagen con hash SHA-256 calculado durante la copia y log de la operación
sudo dc3dd if=/dev/sdb of=/mnt/evidencia/disco_host01.dd hash=sha256 log=/mnt/evidencia/disco_host01.log

# Con hash dual (MD5 + SHA-256) y verificación de sectores dañados
sudo dc3dd if=/dev/sdb of=/mnt/evidencia/disco_host01.dd hash=md5,sha256 
  errlog=/mnt/evidencia/disco_host01_errores.log log=/mnt/evidencia/disco_host01.log

5.5 ewfacquire — formato E01/EWF nativo en Linux

ewfacquire (parte de libewf) genera directamente el formato EWF/E01 desde Linux, sin depender de FTK Imager. Es la opción recomendada cuando el flujo de trabajo es Linux-first (por ejemplo, con SIFT Workstation).

# Instalación (Debian/Ubuntu, SIFT Workstation ya lo incluye)
sudo apt install ewf-tools

# Adquisición interactiva (pide nº de caso, examinador, descripción)
sudo ewfacquire /dev/sdb

# Adquisición no interactiva con metadatos completos en línea de comandos
sudo ewfacquire -c best -C "CASO2026-014" -D "Disco principal Host01" 
  -e "Analista: N. Torres" -m fixed -M physical -t /mnt/evidencia/disco_host01 
  -f encase6 /dev/sdb

5.6 raw/dd vs. E01/EWF: por qué el formato importa

La elección de formato no es cosmética: condiciona qué puedes demostrar después ante un perito contrario o un tribunal.

raw/dd: copia bit a bit sin ningún tipo de envoltorio. Ventaja: compatible con absolutamente cualquier herramienta forense, sin dependencias de librerías propietarias. Desventaja: no lleva metadatos embebidos (nº de caso, examinador, hash), no se comprime, y el hash debe gestionarse en un fichero externo que puede perderse o desvincularse de la imagen.
E01/EWF (Expert Witness Format, originado en EnCase): formato contenedor que incluye la imagen comprimida junto con metadatos del caso y hash embebido (CRC por bloque + hash MD5/SHA-1 del conjunto), lo que permite verificar la integridad de la imagen sin ficheros externos adicionales. Es el formato de facto exigido en la mayoría de protocolos periciales porque autocontiene la prueba de que no ha sido alterada.

Regla práctica: si el caso puede terminar en sede judicial, usa E01. Si es un triage interno rápido de SOC sin pretensión de admisibilidad legal, raw/dd con hash externo bien documentado es suficiente y más rápido de generar.

6. Triage rápido: KAPE, Velociraptor y CyLR

No siempre hay tiempo (ni necesidad) de imagen completa de disco. Cuando se trata de decidir en minutos si un host está comprometido, el triage dirigido a artefactos específicos es más eficiente.

6.1 KAPE (Kroll Artifact Parser and Extractor)

KAPE trabaja con dos conceptos: targets (qué artefactos copiar: registro, logs de eventos, prefetch, MFT, etc.) y modules (qué herramienta ejecutar sobre lo copiado, por ejemplo un parser de EVTX). Es gratuito (Kroll/Magnet Forensics) y el estándar de facto para triage en respuesta a incidentes por su velocidad.

# Copiar artefactos básicos de compromiso (registro, eventos, prefetch, MFT) desde un volumen montado
kape.exe --tsource E: --target KapeTriage --tdest D:evidenciaCASO2026-014kape_host01 --vhdx host01

# Ejecutar targets + módulos de parseo automático (EvtxECmd, RECmd, etc.) en un solo paso
kape.exe --tsource C: --target !SANS_Triage --tdest D:triage_out --mdest D:triage_parsed --module !EZParser

# Triage remoto sobre un disco ya montado como imagen E01
kape.exe --tsource F:disco_host01.E01 --target RegistryHives,EventLogs --tdest D:evidenciatriage_offline

6.2 Velociraptor

Velociraptor (Rapid7, open source) permite colección y triage a escala en decenas o cientos de endpoints simultáneamente mediante su propio lenguaje de consultas (VQL). Es la herramienta de elección cuando el incidente no está limitado a un único host.

# Desplegar el servidor Velociraptor
./velociraptor --config server.config.yaml frontend

# Ejecutar una colección de triage (Windows.KapeFiles.Targets) contra un cliente específico
./velociraptor query -v "SELECT * FROM Artifact.Windows.KapeFiles.Targets(Device='C:', VSSAnalysis=TRUE)"

6.3 CyLR (CylanceLIVE Response)

CyLR es un binario ligero, de un único ejecutable, pensado para desplegar vía EDR o script de forma masiva y silenciosa, recolectando los artefactos forenses clave (MFT, registro, logs de eventos, prefetch) en un ZIP comprimido.

# Ejecución local, salida comprimida al mismo directorio
CyLR.exe -od D:evidenciaCASO2026-014

# Salida directa a servidor SFTP de recolección (útil en despliegue masivo vía EDR)
CyLR.exe -u usuario -p clave -s recoleccion.empresa.local -op /evidencia/host01/

7. Verificación de integridad y cadena de custodia

Ninguna adquisición está completa sin verificación. El procedimiento estándar es calcular el hash antes de mover o copiar la evidencia (si es posible, sobre el disco/memoria original) y después de cada copia subsiguiente, comparando que coincidan exactamente.

# Windows: hash SHA-256 nativo sin herramientas de terceros
certutil -hashfile D:evidenciadisco_host01.E01 SHA256

# Linux: hash y comparación automática contra fichero .sha256 previamente generado
sha256sum -c disco_host01.dd.sha256

# Verificación integrada de una imagen E01 (comprueba el hash embebido en el propio contenedor)
ewfverify /mnt/evidencia/disco_host01.E01

La cadena de custodia es el documento (formulario físico o digital) que registra, sin huecos temporales, cada persona que ha tenido acceso a la evidencia, la fecha/hora exacta de cada transferencia, el propósito de cada acceso y el hash verificado en cada punto de control. Como mínimo debe incluir: identificación única de la evidencia (nº de caso + nº de ítem), descripción física (marca, modelo, nº de serie del disco/equipo), hash de adquisición, nombre completo y firma de quien adquiere, fecha/hora de inicio y fin de la adquisición, y un registro de cada transferencia posterior de custodia. Sin esta cadena documentada, incluso una imagen técnicamente perfecta puede ser impugnada con éxito por la defensa en un procedimiento judicial.

8. Laboratorio: adquirir memoria y disco de una VM víctima

Objetivo: practicar el flujo completo de adquisición sobre una máquina virtual de laboratorio (Windows 10/11 o Ubuntu Server, según disponibilidad), verificando integridad en cada paso.

Levanta una VM víctima aislada (VirtualBox/VMware, red interna sin salida a Internet) y toma un snapshot limpio antes de empezar.
Prepara un disco/carpeta compartida de «evidencia» simulando un USB externo, distinto del disco de la VM.
Captura de memoria: ejecuta WinPMEM (Windows) o avml (Linux) contra la VM en ejecución, guardando el volcado en la carpeta de evidencia. Calcula el hash SHA-256 inmediatamente tras la captura.
Apaga limpiamente la VM (o simula el hallazgo del sistema ya apagado) y adjunta el disco virtual (.vdi/.vmdk) a un entorno de análisis, tratándolo como si estuviera tras un write blocker.
Imagen de disco: genera una imagen E01 con FTK Imager o ewfacquire del disco de la VM víctima. Anota el hash que reporta la propia herramienta al finalizar.
Verificación: recalcula el hash de la imagen resultante con certutil/sha256sum o ewfverify y confirma que coincide con el reportado en el paso anterior.
Documenta una cadena de custodia mínima en un fichero de texto: caso, examinador, fecha/hora de cada paso, hashes de memoria y disco, y ubicación final de cada fichero de evidencia.
(Opcional, avanzado) Ejecuta KAPE con el target !SANS_Triage contra el disco de la VM y compara la rapidez del triage dirigido frente a la imagen completa.

9. Errores comunes

Apagar la máquina antes de capturar memoria. Es el error más costoso y más frecuente entre analistas junior: por reflejo de «contener el daño», se corta la alimentación o se hace un apagado normal, perdiendo para siempre procesos en memoria, conexiones activas y claves de cifrado. Regla: memoria primero, siempre, salvo justificación documentada en contrario.
No verificar el hash, o verificarlo solo una vez. El hash debe calcularse en el origen (si es posible) y en cada copia posterior. Un solo hash «al final» no demuestra que la cadena completa de copias sea íntegra.
Trabajar directamente sobre el disco/imagen original. El análisis (montaje, parsing, indexado) debe hacerse siempre sobre una copia de trabajo, nunca sobre la imagen maestra ni, mucho menos, sobre el disco físico original.
Omitir el write blocker «porque hay prisa». Basta con montar accidentalmente una partición en modo escritura para invalidar la imagen. El write blocker no es opcional cuando el disco original va a conectarse a cualquier equipo.
Ejecutar herramientas de captura desde el propio disco del sistema comprometido. Esto escribe en el disco objetivo (crea el propio proceso, actualiza el pagefile, modifica timestamps de acceso) contaminando la evidencia que aún no se ha capturado. Usa siempre medio externo de solo lectura.
Cadena de custodia incompleta o retroactiva. Documentar «de memoria» al día siguiente introduce errores e imprecisiones que un perito contrario explotará. Se documenta en el momento, con hora exacta.
Confundir triage con adquisición completa. KAPE/Velociraptor son excelentes para decidir rápido, pero no sustituyen una imagen forense completa si el caso puede escalar a un procedimiento formal.

10. Ejercicio

Sobre la VM víctima del laboratorio (o una nueva instancia si prefieres partir de cero):

Simula un compromiso simple: ejecuta un proceso con un nombre distintivo (por ejemplo, un script que se quede en bucle con un argumento identificable como -labcase2026) y abre una conexión de red saliente ficticia (por ejemplo, un nc -lvp 4444 en otra VM y una conexión desde la víctima).
Realiza la captura de memoria con la herramienta que corresponda a tu SO de laboratorio.
Sin analizar aún el volcado en profundidad (eso es contenido de un módulo posterior de análisis de memoria), usa una utilidad básica de búsqueda de cadenas (strings en Linux, o un visor hexadecimal) para confirmar que el argumento distintivo -labcase2026 aparece en el volcado de memoria. Esto demuestra que la captura ha preservado el estado del proceso en ejecución.
Genera la imagen de disco completa de la VM y verifica su hash.
Entrega (o guarda para ti) un documento de cadena de custodia con: identificación del caso, hashes de memoria y disco, hora de inicio/fin de cada captura, y la evidencia de que el argumento distintivo aparece en el volcado de memoria.

Preguntas frecuentes

¿Es obligatorio seguir el orden de volatilidad al pie de la letra en todos los casos?

No como checklist rígida, sino como principio de priorización. El propio RFC 3227 reconoce que el orden exacto depende del sistema y del contexto del incidente. Lo que sí es exigible es que, si te desvías del orden estándar (por ejemplo, priorizas el estado de red sobre la memoria porque hay exfiltración activa), documentes explícitamente por qué lo hiciste. Lo que nunca es defendible es no tener ningún criterio y actuar de forma improvisada.

¿Puedo usar dd en vez de dc3dd o ewfacquire si es lo único que tengo disponible?

Sí, dd es perfectamente válido y ampliamente aceptado, siempre que calcules y documentes el hash de forma independiente (con sha256sum antes y después de la copia). Lo que dd no te da por sí solo es el hash embebido ni los metadatos del caso que sí incluye un E01, así que en un caso con destino judicial es preferible dc3dd o ewfacquire cuando estén disponibles, precisamente porque reducen el margen de error humano al documentar la integridad.

¿Qué hago si el sistema tiene disco cifrado con BitLocker y está apagado cuando llego?

Si el sistema está apagado y cifrado con BitLocker sin que tengas la clave de recuperación, la imagen de disco por sí sola será inútil para el análisis (verás únicamente datos cifrados). Esta es precisamente una de las razones por las que el live response es crítico: si encuentras el sistema encendido y desbloqueado, la clave de cifrado de BitLocker reside en memoria y solo es recuperable capturando la RAM antes de apagar. Si ya está apagado sin clave disponible, tu única vía es solicitar la clave de recuperación (Azure AD/Entra ID, Active Directory, o la clave impresa/guardada por el usuario) antes de proceder con el análisis del disco.

¿KAPE sustituye a una imagen forense completa?

No. KAPE es una herramienta de triage dirigido: copia y parsea rápidamente los artefactos que sabes que necesitas (registro, logs de eventos, prefetch, MFT), lo cual es excelente para decidir en minutos si hay compromiso y con qué alcance. Pero si el caso puede escalar a un procedimiento disciplinario o judicial, necesitarás la imagen forense completa del disco, porque KAPE no captura el disco íntegro (espacio no asignado, ficheros no incluidos en sus targets, slack space). Lo habitual es usar KAPE para triage inicial rápido y, en paralelo o después, adquirir la imagen completa si el caso lo justifica.

¿Por qué la memoria capturada con LiME requiere compilar un módulo específico para cada kernel, y avml no?

LiME se implementa como módulo cargable del kernel de Linux (LKM), y los módulos del kernel deben compilarse contra la versión exacta (incluyendo parches de distribución) del kernel en ejecución, porque acceden a estructuras internas del kernel que cambian entre versiones. avml, en cambio, usa una interfaz de más bajo nivel (acceso directo a /dev/crash, /proc/kcore o mapeo directo de memoria física según el kernel disponga) que no requiere compilación específica, lo que lo hace mucho más portable para un kit de respuesta a incidentes donde no controlas de antemano la versión exacta del kernel objetivo. La contrapartida es que avml depende de que el kernel objetivo exponga alguna de esas interfaces, lo cual no está garantizado al 100% en todas las configuraciones (por ejemplo, kernels con /dev/crash deshabilitado).

«Order of volatility: When collecting evidence you should proceed from the volatile to the less volatile… The consequence of this is that data is collected in the following general order [from most volatile to least]: registers, cache; routing table, arp cache, process table, kernel statistics, memory; temporary file systems; disk; remote logging and monitoring data that is relevant to the system in question; physical configuration, network topology; archival media.»

— RFC 3227, «Guidelines for Evidence Collection and Archiving», Brezinski & Killalea, IETF, 2002.

Módulo 5: Adquisición forense: memoria y disco