Resumen ejecutivo
Un servidor comprometido por un grupo de ransomware. 192 GB de memoria RAM que analizar, logs incompletos —con tramos donde directamente no había registros— y una herramienta forense que se negaba a listar los procesos por un error indeterminado. Manuel Moreno cuenta cómo se resuelve un caso así en la práctica: desde las reglas básicas que hacen admisible una evidencia en tribunales, hasta la ingeniería inversa del propio archivo de volcado que terminó en un parche al código de Volatility 3. Y con una restricción que define todo el trabajo forense profesional: bajo acuerdos de confidencialidad no se puede enviar la evidencia a ningún servicio de IA en la nube. Su respuesta: modelos ejecutándose localmente, con las herramientas construidas —esas sí— con ayuda de modelos de frontera.
1. Las reglas que hacen válida una evidencia
La computación forense es la aplicación de técnicas científicas y analíticas a infraestructuras tecnológicas para identificar, preservar, analizar y presentar datos válidos dentro de un proceso legal. Esa última parte —el proceso legal— es la que impone todo el rigor.
Los primeros pasos no son negociables: asegurar la cadena de custodia, fotografiar el proceso, obtener copias respetando el orden de volatilidad —RAM, luego conexiones de red, luego procesos en ejecución, y al final el disco—, usar bloqueador de escritura para la copia de disco (imprescindible si la evidencia va a juicio) y procesar todo calculando los hashes de cada artefacto recolectado.
La regla del forense: si está prendido, déjalo prendido; si está apagado, déjalo apagado — con la consecuencia dolorosa de que en el segundo caso ya no habrá memoria RAM que recuperar. Y la regla de oro que atraviesa todo el oficio: nunca se trabaja sobre la evidencia original.
La razón de tanta ceremonia es práctica: la respuesta al incidente y la creación de imágenes forenses es el paso más importante de toda la investigación. Fallar ahí puede invalidar o hacer inadmisible todo lo que se recoja después — o, en el mejor de los casos, darle un dolor de cabeza serio a los abogados.
2. Por qué la memoria RAM lo cambia todo
El análisis de memoria es clave en respuesta a incidentes porque la RAM contiene información volátil que desaparece al apagar el equipo, pero que revela lo que el disco nunca mostrará: procesos maliciosos activos o recién terminados, malware sin archivos en disco (fileless), actividad en tiempo real —conexiones, comandos, credenciales en uso—, evidencia que jamás se escribió en disco y hasta llaves de cifrado.
El proceso tiene tres etapas. Adquisición: obtener el volcado con herramientas especializadas, siempre con cadena de custodia y hash. Análisis: cargarlo en frameworks como Volatility 2 o 3, o en suites comerciales, para explorar procesos, conexiones y artefactos de usuario. Correlación: cruzar la RAM con logs, disco y red para responder las preguntas que importan — ¿qué malware corría, qué hizo, cómo persistía?
Sobre herramientas, Moreno es pragmático: en la práctica, la combinación más usada en respuesta a incidentes es una suite comercial más Volatility o MemProcFS — la primera entrega reportes claros para gerencias y jueces; la segunda, el análisis técnico profundo.
3. El caso: 192 GB y ninguna respuesta
El escenario real que estructura la charla: un servidor Oracle Linux con kernel UEK comprometido por un grupo de ransomware. Las condiciones del trabajo:
- 192 GB de RAM que analizar.
- Los logs no contaban toda la historia — había tramos donde directamente no existían registros.
- Volatility fallaba con un error indeterminado y no listaba los procesos.
- Por acuerdos de confidencialidad, nada podía enviarse a servidores en la nube ni de terceros: todo el procesamiento debía ocurrir dentro del perímetro.
Para analizar memoria de Linux, Volatility necesita un perfil con la versión exacta del kernel del servidor comprometido. Eso obligó a montar un servidor réplica: una máquina virtual con la misma distribución, el mismo kernel —la parte más laboriosa del trabajo— y la compilación del perfil sobre esa réplica. Todo hecho, todo correcto… y aun así, Volatility seguía sin listar procesos.
4. Ingeniería inversa del propio volcado
Aquí la charla se vuelve un relato de investigación técnica poco común. Descartada la vía normal, quedaba strings — buscar cadenas de texto sin estructura, lo que Moreno describe como «cazar con un rifle a 10.000 kilómetros de distancia».
La alternativa fue diagnosticar el archivo mismo. Todo formato tiene números mágicos: una secuencia específica de bytes al inicio que funciona como firma e indica al programa cómo interpretar el contenido y qué analizador usar. Comparando la estructura esperada del formato LiME contra la del volcado real, apareció la anomalía: segmentos fantasma — encabezados que no correspondían a la estructura normal y que hacían fracasar la carga.
Con scripts propios de análisis, el equipo identificó el patrón de esos segmentos, determinó su causa raíz y modificó la función de carga de segmentos en el código de Volatility 3 para manejarlos correctamente. El resultado: la herramienta volvió a funcionar sobre esa evidencia y el análisis forense pudo continuar. Esa es la diferencia entre usar una herramienta y entenderla.
5. IA local: la única opción cuando hay un NDA de por medio
La segunda parte de la charla aborda el problema que enfrenta cualquier profesional forense que quiera usar inteligencia artificial. La información de estos casos corresponde en su gran mayoría a investigaciones privadas o cubiertas por acuerdos de no divulgación. Traducido: no se puede abrir un asistente comercial y pedirle «analízame estos logs». Hacerlo sería enviar los datos del cliente a un proveedor extranjero.
La solución de Moreno separa dos usos de la IA que suelen confundirse:
| Para construir las herramientas | Para procesar la evidencia |
|---|---|
| Se pueden usar modelos de frontera en la nube: aquí no hay datos del cliente, solo código y lógica de análisis. | Exclusivamente IA local, dentro del perímetro. La evidencia nunca sale de la infraestructura propia. |
En su implementación usa un modelo abierto de tamaño medio con ventana de contexto extendida, ejecutándose localmente, integrado a Volatility mediante un proyecto que publicó en abierto. Y una consideración de diseño que vale para cualquiera que monte algo así: el modelo se puede cambiar fácilmente cuando aparezcan opciones mejores — la arquitectura no queda atada a un proveedor, lo que da flexibilidad y velocidad.
6. El equipo que hace falta
Vale la pena rescatar cómo se organiza una respuesta a incidentes seria, porque suele imaginarse como el trabajo de una sola persona frente a un terminal. Se necesitan al menos seis especialidades: comandante del incidente, primeros respondedores, líder forense, administración de sistemas, redes, ingeniería inversa y análisis de malware y caza de amenazas.
El comandante del incidente lidera el proceso completo: define la estrategia, asigna roles, determina qué evidencias se recolectan y qué triaje se hace en las primeras máquinas, analiza el riesgo para el retorno seguro a operaciones, orquesta el trabajo entre equipos internos, consultores externos y el equipo de respuesta, y —cuando corresponde— asesora en el proceso de negociación. Los primeros respondedores activan el protocolo, generan las notificaciones iniciales, ejecutan el triaje en los equipos sospechosos y, crucialmente, aseguran que la evidencia digital no sea destruida por algún proceso de restauración del área de tecnología — un riesgo real y frecuente.
Y todo eso se sostiene en las cinco fases clásicas: preparación (plan, roles, capacitación y simulacros), identificación, contención, erradicación y recuperación.
7. Conclusiones
Tres ideas para llevarse. Primero, en forense la validez legal manda sobre la eficiencia técnica: la cadena de custodia, el orden de volatilidad y el hash no son burocracia — son lo que hace que el trabajo sirva de algo. Segundo, las herramientas fallan y hay que saber por qué: este caso se resolvió leyendo la estructura binaria del volcado y parchando el framework, no cambiando de producto. Tercero, y es la lección más transferible: la confidencialidad no es un obstáculo para usar IA, es una restricción de arquitectura — modelos locales para la evidencia, modelos de frontera para construir el instrumental.
Para la región, el mensaje es doblemente útil: en LATAM buena parte del trabajo forense ocurre bajo acuerdos estrictos y con presupuestos que no dan para suites comerciales completas. Volatility más un modelo local corriendo en hardware propio es una combinación viable, legalmente defendible y al alcance de un equipo pequeño.
Referencias
- Moreno Leiva, M. (2026). Forensic con IA en 2026 [presentación]. I Congreso IA-LATAM. PDF de la charla.
- Moreno Leiva, M. Volatility Local LLM [repositorio]. github.com/GlobalsecureAcademy/Volatility-Local-LLM.
- Herramientas citadas: Volatility 2 y 3 · MemProcFS · AVML (adquisición de memoria en Linux) · dwarf2json · suites forenses comerciales de uso policial.
- Formato LiME (Linux Memory Extractor), estándar de volcado de memoria usado en el caso analizado.
Sobre el autor
Manuel Moreno Leiva es CEO e Incident Commander en GlobalSecure (Chile), especialista en respuesta a incidentes, investigación forense digital y peritaje. Es creador de varias certificaciones profesionales de seguridad ofensiva y defensiva, y speaker internacional con ponencias en Ekoparty (Argentina), Ground Zero Summit (India), Microsoft TechDays (Chile) y OWASP LATAM Tour, entre otros. Entre sus credenciales figuran CCISO, CEH, CHFI, ECSA, OPST y auditor líder ISO 27001, además de formación en Black Hat USA en tácticas adversarias, sistemas de control industrial y pentesting personalizado. LinkedIn
Artículo elaborado por la Comunidad IA LATAM a partir de la presentación oficial de la charla. Esta charla aún no cuenta con video individual publicado en el canal, por lo que el artículo se basa exclusivamente en el material de la presentación. Los detalles del caso se presentan de forma anonimizada, conforme a los acuerdos de confidencialidad que rigen el trabajo forense.