Post actualizado el día octubre 27, 2026 by DeiviSanzPlay
Cuando un equipo comprometido sigue encendido y el reloj corre, la diferencia entre un informe pericial útil y un montón de logs inservibles está en el orden de las acciones. Esta lista de comprobación recoge los pasos que un analista con oficio ejecuta —y los errores que evita— durante las primeras horas de una investigación de ciberseguridad forense informática.
Antes de tocar nada: decisiones que condicionan todo
1. Delimita el alcance y el objetivo legal
¿Es una investigación interna, un requerimiento judicial o una notificación a la autoridad de protección de datos? La respuesta cambia qué puedes hacer con la evidencia. Si hay proceso penal, la cadena de custodia debe documentarse con más rigor que un ticket de soporte.
2. Congela el sistema, no lo apagues
Apagar un equipo con disco cifrado puede destruir claves en memoria. Suspender la ejecución (por ejemplo, con un volcado de memoria previo) es preferible a un apagado limpio. Excepción: si hay propagación activa a otros sistemas, aislar la red pesa más que preservar el estado.
3. Documenta la hora de cada acción con fuente fiable
Anota la hora del servidor NTP de referencia, no la de tu reloj de muñeca. Las discrepancias de zona horaria son la causa número uno de incoherencias en informes que se caen en juicio.
Recogida de evidencia volátil y no volátil
4. Volcado de memoria RAM
Aquí viven procesos maliciosos sin fichero en disco, claves de cifrado y conexiones activas. Herramientas como WinPmem, LiME o AVML generan la imagen; verifica el hash del volcado al terminar.
5. Captura del estado de red
Antes de desconectar, registra conexiones establecidas, tablas ARP y caché DNS. Un comando trivial como netstat -ano o ss -tupn puede aportar el indicador de compromiso que falta.
6. Imagen forense del disco con bloqueo de escritura
Usa un puente write-blocker físico. En entornos virtuales, una instantánea del hipervisor es admisible si documentas la cadena de custodia. Calcula SHA-256 de origen y destino y compáralos antes de continuar.
7. Preserva logs centralizados antes de que roten
Exporta de inmediato los eventos de SIEM, firewall, proxy y directorio activo. La retención por defecto de muchos sistemas (7 o 30 días) es más corta de lo que tarda un incidente en detectarse.
Análisis sin contaminar
8. Trabaja siempre sobre copias
Monta la imagen en modo lectura con herramientas como Autopsy, FTK Imager o Sleuth Kit. Nunca arranques el sistema original para «ver qué pasa»: altera timestamps y artefactos de ejecución.
9. Correlaciona artefactos, no confíes en uno solo
Un evento de arranque de Windows sin fichero asociado, un servicio creado minutos antes del incidente y una conexión saliente al mismo dominio forman una hipótesis sólida. Un único indicador aislado no sostiene una conclusión.
10. Reconstruye la línea temporal
Normaliza todas las marcas de tiempo a UTC y ordénalas. La superposición de MFT, registro de eventos y logs de aplicaciones suele revelar el vector de entrada real, que a menudo no es el que parecía al principio.
Cierre: lo que muchos checklists olvidan
11. Registra las limitaciones del análisis
Si el disco estaba cifrado y no había claves, dilo. Si faltan logs de un segmento temporal, dilo. Un informe que reconoce sus lagunas es más creíble que uno que promete certezas absolutas.
12. Define acciones de contención y lecciones aprendidas
Rotación de credenciales, revisión de reglas de detección y ajuste de retención de logs. Sin este paso, la investigación forense se convierte en un trámite y no en una mejora real de la postura de seguridad.
Errores que he visto repetirse
Ejecutar antivirus sobre el equipo comprometido antes de la imagen: el motor de limpieza borra el binario malicioso y con él la prueba. Otro clásico: abrir el navegador en la máquina afectada para buscar el dominio sospechoso, alterando la caché DNS y las marcas de acceso. Y uno menos evidente: copiar ficheros con el explorador de Windows a un USB, lo que modifica los timestamps de acceso del origen.
Dónde no llega la forense tradicional
En entornos cloud nativos (contenedores efímeros, funciones serverless) la imagen de disco pierde sentido: la evidencia está en los logs del proveedor y en las APIs de auditoría. Tampoco resuelve casos de exfiltración por canales legítimos (correo corporativo, SaaS) si no había monitorización de salida. Y no sustituye a un análisis de malware profundo cuando el objetivo es atribuir el ataque a un grupo concreto: eso requiere inteligencia de amenazas adicional.
Según documentación oficial de organismos como NIST (guía SP 800-86) y las buenas prácticas difundidas por comunidades de respuesta a incidentes, la clave está en preservar antes de analizar y en documentar cada paso. Ningún checklist garantiza resultados: garantiza que, si algo sale mal, puedas demostrar qué hiciste y por qué.
Perfiles verificables: Sitio web
Publicado el 27 de October de 2026. Última revisión: 27 de October de 2026.
