Saltar a contenido

3.2.1.-Análisis de evidencias

3.2.1. Análisis de evidencias

En el punto anterior se ha trabajado cómo recopilar y conservar evidencias sin dañarlas. A partir de ahí empieza otro trabajo distinto: entender qué dicen esas evidencias y convertirlas en información útil para decidir los siguientes pasos.

En esta parte del tema vamos a centrarnos en cómo se analizan esas evidencias. La idea principal es sencilla: no se analiza “a ver qué sale”, sino para extraer hallazgos técnicos verificables a partir de datos objetivos.

Código Descripción
RA3 Investiga incidentes de ciberseguridad analizando los riesgos implicados y definiendo las posibles medidas a adoptar.
CEb Se ha realizado un análisis de evidencias.

Definición

El análisis de evidencias es el proceso técnico mediante el cual una persona analista estudia evidencias ya recopiladas, extrae hallazgos, contrasta hipótesis y construye una explicación parcial, trazable y reproducible de lo observado.

Alcance de este punto

En 3.1.1 y 3.1.2 se trabaja cómo obtener, preservar y almacenar evidencias. En 3.3.1 y 3.3.2 se aborda la investigación del incidente, sus modelos y la explicación global del caso. Aquí nos centramos en el CE 3.b: analizar la evidencia disponible para obtener hallazgos técnicos fiables.

1. Qué significa analizar evidencias

Analizar evidencias consiste en examinar información ya preservada para responder preguntas técnicas concretas:

  • qué actividad sospechosa aparece en los datos;
  • cuándo ocurrió;
  • en qué sistema o cuenta se observa;
  • con qué otros eventos se relaciona;
  • y qué indicios apuntan a compromiso real o a un falso positivo.

Dicho de forma sencilla, la recopilación responde a "qué datos debo guardar" y el análisis responde a "qué me están diciendo esos datos".

1.1. Qué aporta esta fase y qué no pretende cerrar

Esta fase debe permitir:

  • identificar actividad anómala o maliciosa;
  • localizar artefactos relevantes;
  • extraer [IoC] e indicios de comportamiento;
  • ordenar hechos en una línea temporal técnica;
  • y preparar una salida útil para la investigación posterior.

Esta fase no pretende, por sí sola:

  • determinar toda la autoría del incidente;
  • reconstruir necesariamente el caso completo de principio a fin;
  • justificar medidas estratégicas globales de la organización;
  • ni sustituir el informe final de investigación.

2. Qué evidencias se pueden analizar

En una investigación real rara vez existe una sola fuente. Lo normal es trabajar con varias evidencias y cruzarlas.

Tipo de evidencia Qué suele aportar Ejemplos habituales
Logs de sistema y servicios Secuencia de eventos y acciones registradas auth.log, Visor de eventos, logs web, DNS, proxy, firewall
Memoria Procesos activos, conexiones, módulos cargados, restos de ejecución Volcado RAM, memoria de un servidor o endpoint
Disco Ficheros, persistencia, cambios en el sistema, historiales Imagen forense, artefactos de usuario, binarios
Red Flujo de comunicaciones, resoluciones DNS, protocolos usados Capturas [PCAP], NetFlow, registros de IDS
Correo Vector de entrada, autenticación del remitente, adjuntos, URLs Cabeceras, mensaje original, sandbox de adjuntos
Artefactos de endpoint Huellas de ejecución, persistencia y actividad local Prefetch, tareas programadas, servicios, registro, historiales
Telemetría de seguridad Alertas y contexto ya correlacionado [SIEM], [EDR], IDS, antivirus

Idea práctica

Una sola evidencia rara vez explica un incidente entero. El valor aparece cuando varias fuentes apuntan a la misma secuencia de hechos.

3. Preparación del entorno de análisis

Antes de abrir un log, montar una imagen o cargar un volcado de memoria, hay que preparar el entorno con criterio. Un análisis técnicamente correcto puede quedar invalidado si se hace de forma desordenada o si altera la evidencia.

3.1. Principios básicos

  • No trabajar sobre el original salvo que no exista otra alternativa y esté justificado.
  • Documentar qué copia se analiza, con qué herramientas y en qué momento.
  • Aislar el entorno si existe riesgo de ejecutar malware o activar comunicaciones externas.
  • Mantener la trazabilidad entre la evidencia, la herramienta y el resultado obtenido.
  • Controlar fechas y zonas horarias, porque un análisis correcto con horas mal interpretadas genera conclusiones erróneas.

Error frecuente

Si dos fuentes usan zonas horarias distintas y no se normalizan, la línea temporal puede parecer incoherente aunque los datos sean correctos.

3.2. Entorno mínimo recomendable

Un laboratorio de análisis sencillo debería permitir, al menos:

  • montar imágenes en modo solo lectura;
  • abrir volcados de memoria sin alterar el original;
  • revisar capturas de red de forma aislada;
  • registrar notas, hallazgos y comandos ejecutados;
  • y exportar resultados para que otra persona pueda revisarlos.

Un esquema básico sería este:

flowchart LR
    A[Evidencias ya recopiladas] --> B[Validacion de copia y contexto]
    B --> C[Entorno de analisis aislado]
    C --> D[Revision por fuentes<br/>logs memoria disco red correo endpoint]
    D --> E[Extraccion de hallazgos]
    E --> F[IoC y artefactos tecnicos]
    E --> G[Linea temporal tecnica]
    F --> H[Contraste entre evidencias]
    G --> H
    H --> I[Salida del analisis]

3.3. Qué conviene registrar desde el principio

Desde el primer momento conviene anotar:

  • identificador del caso;
  • evidencia concreta que se está revisando;
  • hash o identificador de la copia recibida;
  • herramienta usada y versión;
  • filtros o consultas ejecutadas;
  • y hallazgos provisionales con su fuente exacta.

Eso evita dos problemas muy comunes: perder trazabilidad y no poder reproducir el análisis unos días después.

4. Cómo se analiza cada tipo de evidencia

No existe una receta única para todos los incidentes. Aun así, sí hay una idea común: cada fuente responde mejor a unas preguntas concretas.

4.1. Análisis de logs

Los logs suelen ser el punto de partida porque permiten ver qué ocurrió, cuándo y dónde quedó registrado. Son especialmente útiles para:

  • autenticaciones correctas o fallidas;
  • creación de procesos o servicios;
  • cambios de configuración;
  • actividad web;
  • consultas DNS;
  • conexiones salientes anómalas;
  • y errores que coinciden con el momento del incidente.

Un análisis de logs útil no consiste en leer línea por línea sin criterio. Lo habitual es:

  1. filtrar por rango temporal;
  2. localizar el activo, usuario, IP o servicio implicado;
  3. buscar eventos anómalos;
  4. y relacionarlos con otras fuentes.
# Ejemplo sencillo: buscar eventos de autenticacion fallida
rg "Failed password|authentication failure" auth.log

# Ejemplo sencillo: buscar actividad de PowerShell en eventos exportados
rg -i "powershell|encodedcommand|downloadstring" eventos-windows.txt

Qué puede aportar un log

Si en el firewall aparece una conexión saliente a una IP poco habitual a las 10:14, y en el endpoint aparece la ejecución de powershell.exe a las 10:13, ya existe una relación técnica que merece contraste.

4.2. Análisis de memoria

La memoria es clave cuando interesa saber qué estaba pasando en vivo en el sistema. Puede revelar información que quizá nunca llegue a escribirse en disco:

  • procesos en ejecución;
  • procesos ocultos o anómalos;
  • conexiones de red activas;
  • módulos cargados;
  • comandos lanzados;
  • y restos de código o cadenas sospechosas.

En incidentes con malware, intrusión remota o uso de herramientas nativas del sistema, la memoria suele aportar contexto muy valioso.

# Ejemplos orientativos con Volatility 3
vol -f memoria.raw windows.pslist
vol -f memoria.raw windows.netscan
vol -f memoria.raw windows.cmdline

Qué buscar en memoria

Conviene fijarse en procesos sin padre claro, nombres muy parecidos a procesos legítimos, rutas extrañas, conexiones hacia el exterior y cadenas que apunten a URLs, comandos o credenciales.

4.3. Análisis de disco

El disco permite revisar qué ha quedado persistente después de la actividad. Aquí interesan sobre todo:

  • binarios sospechosos;
  • scripts o documentos usados como vector de entrada;
  • mecanismos de persistencia;
  • historial de ejecución;
  • cambios en carpetas temporales;
  • y borrados o modificaciones significativas.

El análisis de disco suele responder a preguntas como estas:

  • ¿qué fichero se ejecutó?;
  • ¿desde qué ruta?;
  • ¿se instaló algo?;
  • ¿se creó una tarea o servicio?;
  • ¿hay rastro de compresión, exfiltración o borrado?;
  • ¿el usuario abrió un adjunto o descargó un binario?
# Ejemplo simple sobre una carpeta extraida de la evidencia
find evidencia-disco/ -type f -iname "*.ps1" -o -iname "*.vbs" -o -iname "*.exe"

# Buscar nombres o cadenas relacionadas con persistencia
rg -i "run key|scheduled task|startup|autorun" notas-analisis.txt

4.4. Análisis de red

La red ayuda a responder con quién se comunicó el sistema y de qué forma. Es útil para detectar:

  • dominios o IP no habituales;
  • tráfico hacia infraestructuras de mando y control;
  • movimientos laterales;
  • exfiltración;
  • protocolos inesperados;
  • o comunicaciones coincidentes con una alerta del host.

Con una captura [PCAP] o con registros de red podemos comprobar si un equipo:

  • resolvió un dominio sospechoso;
  • descargó un fichero;
  • mantuvo conexiones periódicas;
  • o intentó comunicarse con varios destinos tras ejecutar un proceso.
# Filtrar conversaciones HTTP o DNS en una captura
tshark -r trafico.pcap -Y "http or dns"

# Ver conversaciones por IP
tshark -r trafico.pcap -q -z conv,ip

4.5. Análisis de correo

Muchos incidentes empiezan en el correo, así que analizar este vector es más que leer el mensaje visible. Hace falta revisar:

  • cabeceras completas;
  • ruta del mensaje;
  • resultados SPF, DKIM o DMARC si están disponibles;
  • enlaces incluidos;
  • nombres reales y extensiones de adjuntos;
  • y relación entre la hora de entrega y la actividad posterior del endpoint.

Si una persona usuaria recibe un correo a las 09:01, abre un adjunto a las 09:03 y a las 09:04 aparece una ejecución sospechosa, ya tenemos una cadena técnica bastante sólida para seguir profundizando.

Received: from mail.example.net ...
From: soporte@empresa-segura.example
Reply-To: pago-urgente@otro-dominio.example
Subject: Factura pendiente
Attachment: factura_abril.pdf.exe

Cuidado con el nombre del archivo

Un adjunto llamado factura.pdf.exe puede parecer un PDF si la extensión real está oculta. El análisis debe fijarse en el tipo real del fichero, no solo en cómo se muestra al usuario.

4.6. Artefactos de endpoint

Los artefactos de endpoint son huellas que deja la actividad del sistema o de la persona usuaria. No siempre son tan visibles como un log principal, pero muchas veces permiten confirmar ejecución, acceso o persistencia.

Entre los artefactos más útiles suelen estar:

  • tareas programadas;
  • servicios nuevos o modificados;
  • claves de arranque automático;
  • historiales de navegación;
  • ficheros recientes;
  • accesos directos;
  • y rastros de ejecución de programas.

Su valor está en que ayudan a responder preguntas muy concretas:

  • ¿se llegó a ejecutar el binario?;
  • ¿hubo persistencia?;
  • ¿qué usuario lo lanzó?;
  • ¿desde qué ruta?;
  • ¿se abrió antes un documento o una URL relacionada?

5. IoC, artefactos y línea temporal técnica

Uno de los objetivos del análisis es extraer datos reutilizables para seguir trabajando el caso y para proteger otros sistemas.

5.1. Qué es un IoC y para qué sirve

Un [IoC] es un indicador observable que apunta a un posible compromiso. Por ejemplo:

  • un hash de fichero;
  • una IP;
  • un dominio;
  • una URL;
  • una ruta de persistencia;
  • o un asunto de correo usado en una campaña.

Los IoC son útiles, pero no deben tratarse como una conclusión cerrada. Un IoC sin contexto dice poco; un IoC correlacionado con logs, memoria o red aporta mucho más valor.

5.2. Construcción de la línea temporal técnica

La línea temporal técnica ordena eventos procedentes de distintas fuentes para entender la secuencia real. Suele incluir:

  • marca temporal normalizada;
  • fuente del dato;
  • activo o cuenta implicada;
  • evento observado;
  • y comentario analítico.
Hora normalizada Fuente Hallazgo
09:01:12 Correo Llega mensaje con adjunto sospechoso
09:03:47 Endpoint Se abre el fichero adjunto
09:04:10 Sistema Se ejecuta powershell.exe
09:04:13 Red Resolución DNS a dominio no habitual
09:04:18 Firewall Conexión saliente HTTPS a IP externa

Qué aporta la línea temporal

La cronología no adorna el análisis. Sirve para demostrar relaciones entre hechos que, por separado, podrían parecer aislados.

6. Contraste y validación de evidencias

Un análisis de calidad no se queda con la primera explicación posible. Tiene que contrastar.

6.1. Qué significa contrastar

Contrastar consiste en comprobar si un hallazgo aparece respaldado por otra fuente o si, por el contrario, puede deberse a:

  • ruido;
  • falsos positivos;
  • errores de hora;
  • eventos legítimos mal interpretados;
  • o herramientas que generan lecturas parciales.

Por ejemplo:

  • una alerta del [EDR] puede confirmarse con logs del sistema;
  • una conexión vista en red puede contrastarse con la memoria;
  • y un binario sospechoso en disco puede relacionarse con un correo o una descarga previa.

6.2. Preguntas útiles durante el contraste

Una persona analista debería hacerse preguntas como estas:

  • ¿qué otra fuente puede confirmar esto?;
  • ¿hay una explicación legítima alternativa?;
  • ¿la hora coincide en todas las evidencias?;
  • ¿estoy viendo causa, consecuencia o simple coincidencia?;
  • ¿el artefacto sigue presente solo en un equipo o aparece en más activos?

Buena práctica

Una conclusión técnica gana mucha fuerza cuando puede expresarse así: "este hallazgo aparece en la memoria, se refleja en el log del sistema y coincide con la conexión observada en red".

7. Qué salida debe producir el análisis

La salida del análisis no es "he revisado cosas". Debe convertirse en un resultado utilizable por el equipo.

7.1. Productos habituales del análisis

  • lista de hallazgos técnicos relevantes;
  • [IoC] confirmados o pendientes de contraste;
  • artefactos de endpoint significativos;
  • línea temporal técnica;
  • hipótesis reforzadas o descartadas;
  • sistemas, cuentas o servicios que merecen revisión adicional;
  • y evidencias que deben escalarse a la fase de investigación del incidente.

7.2. Cómo debe redactarse esa salida

La salida debería ser:

  • clara, para que otra persona pueda entenderla;
  • trazable, indicando siempre de dónde sale cada conclusión;
  • parcial cuando haga falta, sin afirmar más de lo que la evidencia permite;
  • y accionable, para apoyar investigación, contención o búsqueda en otros sistemas.

8. Ejemplo guiado de análisis

Supongamos este caso sencillo:

  • el [SIEM] alerta de una conexión saliente rara desde un portátil;
  • existe copia de logs del equipo;
  • se dispone de un volcado de memoria;
  • y el buzón de la persona usuaria contiene un correo sospechoso.

Una secuencia de análisis razonable podría ser:

  1. revisar la hora exacta de la alerta en el [SIEM];
  2. buscar en los logs del equipo qué proceso se ejecutó en ese intervalo;
  3. comprobar en memoria si ese proceso mantenía conexiones activas;
  4. revisar el correo para ver si el proceso puede relacionarse con un adjunto o enlace;
  5. extraer [IoC] y construir una línea temporal técnica inicial.

Fíjate en que aquí todavía no hemos cerrado toda la investigación. Lo que sí hemos hecho es transformar evidencias dispersas en una secuencia técnica con sentido, que ya permite seguir trabajando con más precisión.

9. Ideas clave para estudio

  • Analizar evidencias no es recopilar más datos, sino interpretar técnicamente datos ya preservados.
  • Cada tipo de evidencia responde mejor a unas preguntas: los logs muestran eventos, la memoria muestra actividad en vivo, el disco deja persistencia y la red muestra comunicaciones.
  • La calidad del análisis depende tanto de la herramienta como del método: entorno controlado, trazabilidad, normalización horaria y contraste.
  • Los [IoC] son útiles, pero su valor aumenta cuando se relacionan con otras evidencias.
  • La línea temporal técnica es una de las salidas más importantes del análisis.
  • El análisis de evidencias alimenta la investigación del incidente, pero no la sustituye.

Conclusión

El análisis de evidencias es el puente entre conservar datos y entender el incidente. Si está bien hecho, permite detectar actividad relevante, relacionar fuentes distintas, extraer [IoC], ordenar los hechos y producir una base técnica sólida para la investigación posterior. La idea clave que debes recordar es esta: una evidencia aislada puede sugerir; varias evidencias bien analizadas y contrastadas permiten demostrar con mucha más solidez.

Fuentes y referencias

Presentación

No hay una presentación Reveal.js específica para 3.2.1 Análisis de evidencias en el repositorio en este momento.