Cubadebate

Esta semana, mientras preparábamos esta entrega sobre el rastro invisible en la nube y las redes, el mundo de la ciberseguridad se sacudía con una noticia que ilustra a la perfección por qué el análisis forense y la actualización constante son dos caras de la misma moneda. PHP, el lenguaje que sostiene cerca del 70% de los sitios web del planeta, ha liberado parches de emergencia para dos vulnerabilidades críticas de ejecución remota de código (CVE-2026-109618 y CVE-2026-109619), calificadas con una severidad de 9.2 sobre 10.

El detalle es revelador: los detalles técnicos se filtraron antes de lo previsto, los exploits circularon en cuestión de horas y Cloudflare confirmó intentos de ataque masivos casi de inmediato. En un escenario así, el forense de cloud y redes no tiene margen para la improvisación. Los logs de CloudTrail o de Zeek que mencionaremos en este artículo se convierten en la única oportunidad de reconstruir si un servidor fue comprometido antes de que el parche estuviera disponible. La lección es incómoda, pero necesaria: en la nube, la ventana entre la publicación de un parche y su explotación masiva se mide en horas, no en días. Estar actualizado no es una buena práctica; es la diferencia entre tener una evidencia que analizar y tener que explicar por qué no hay nada que analizar.

Ahora bien mis queridos lectores, a lo largo de esta serie hemos construido un mapa del crimen digital. Empezamos en la escena del cibercrimen, interrogamos a Windows, descubrimos que nuestro móvil es un confidente y aprendimos a leer los susurros de Linux. En todas esas entregas, el forense tenía algo físico: un disco, un teléfono, un servidor. Hoy llegamos al territorio donde esa premisa se desmorona. Bienvenidos al análisis forense en entornos cloud y redes corporativas.

Aquí, la evidencia no está en un dispositivo que puedas desconectar y llevar al laboratorio. Está en los servidores de Amazon, Microsoft o Google. Está en los logs, que se rotan cada semana. Está en el tráfico que atraviesa switches y firewalls. El forense ya no es un científico de laboratorio; es un negociador de datos que debe lidiar con la volatilidad, la jurisdicción y la cadena de custodia en un entorno que no controla.

El fin del paradigma del "Disco Duro"

Durante décadas, el análisis forense se basó en una premisa sencilla: incautar el almacenamiento, escribir-protection, hacer una imagen bit a bit y verificar el hash. En la nube, nada de eso es posible. La infraestructura es compartida, el proveedor no te va a entregar el disco físico y, técnicamente, no existe una "imagen" del mismo modo que en un ordenador personal.

Esto obliga a un cambio de mentalidad radical. La integridad de la evidencia ya no se garantiza mediante un bloqueador de escritura, sino mediante documentación rigurosa. ¿Qué cuenta realizó la exportación? ¿A través de qué API o interfaz? ¿Con qué parámetros y en qué fecha? El forense debe crear un registro tan detallado que cualquier experto pueda reproducir la recolección y obtener exactamente el mismo resultado. La cadena de custodia ya no empieza en la incautación, sino en la primera llamada a la API.

Los logs son el nuevo disco duro (y caducan)

Si en Linux decíamos que los logs eran el diario del sistema, en la nube son la única prueba que existe. El contenido de un archivo puede estar cifrado o ser irrelevante; lo que realmente importa es quién accedió, desde dónde, cuándo y qué hizo con él. Esa información vive en los registros de auditoría del proveedor: CloudTrail en AWS, los registros de auditoría de Azure, o los logs de actividad de Google Cloud.

Pero aquí llega el primer gran desafío: la retención. Los proveedores cloud no guardan estos logs para siempre. En muchos casos, la retención por defecto es de semanas o, como máximo, unos meses. Si una organización descubre un incidente tres meses después de que ocurriera, es muy probable que los registros que explicarían qué pasó ya no existan. Los forenses de la nube deben trabajar contra el reloj, y las empresas deben configurar políticas de retención extendida antes de que ocurra el desastre. En la nube, el tiempo no es oro; el tiempo es evidencia.

La recolección en la nube: API, no bisturí

El forense de entornos cloud no usa herramientas de imagen de disco como FTK Imager o dd. Usa herramientas nativas del proveedor. Para investigar una instancia comprometida en AWS, el flujo es casi quirúrgico: primero se captura la memoria volátil (antes de cualquier apagado), luego se toman instantáneas (snapshots) de los volúmenes EBS, se recopilan los metadatos de la instancia y, finalmente, se aísla la instancia para que no pueda comunicarse con el resto de la red.

Amazon ofrece soluciones como el Automated Forensics Orchestrator, que automatiza este proceso: detecta un evento de seguridad, aísla la instancia comprometida, captura las imágenes de disco y memoria, y genera un informe forense para el equipo de respuesta. Es la industrialización del forense cloud. Sin embargo, el forense sigue siendo necesario para interpretar lo que esas instantáneas contienen. La automatización recoge los datos; el humano les da sentido.

Redes corporativas: El testigo que todo lo ve (si está configurado)

Ahora bajemos de la nube a la red corporativa. Aquí el forense se enfrenta a un entorno que, a diferencia de un dispositivo personal, está diseñado para la visibilidad y el control. Firewalls, switches, proxies, sistemas de detección de intrusiones (IDS). Todos ellos generan datos. El problema es que generan demasiados datos, y la mayoría no son útiles hasta que ocurre un incidente.

El análisis forense de red se basa en tres pilares: logs de flujo, logs de eventos y, cuando es posible, captura de paquetes completa (PCAP). Los logs de flujo (como NetFlow o VPC Flow Logs) te dicen quién habló con quién, cuánto y cuándo. Los logs de eventos (como los de un firewall o un sistema EDR) te dicen qué reglas se dispararon o qué procesos se ejecutaron. Pero, la captura de paquetes es el santo grial: te permite reconstruir una sesión completa, ver el contenido de una transferencia de datos o confirmar si una conexión sospechosa era realmente maliciosa.

Herramientas como Zeek (antes Bro) se han convertido en el estándar de facto para la monitorización forense de redes. Zeek no solo captura paquetes; genera logs estructurados de conexiones, consultas DNS, sesiones HTTP, transferencias de archivos SMB y un largo etcétera. Para un forense, tener los logs de Zeek de una red corporativa es como tener una grabación de seguridad de todos los movimientos que ocurrieron en el edificio. La diferencia es que, en lugar de rostros, ves direcciones IP, puertos y protocolos.

La correlación: El arte de unir los puntos

El verdadero poder del forense en entornos cloud y de red no está en una sola fuente de datos, sino en la correlación. Un evento aislado en un log de firewall puede ser ruido. Un proceso sospechoso en un endpoint puede ser un falso positivo. Pero si el firewall muestra una conexión saliente a una IP extraña en el mismo minuto en que Sysmon registró la ejecución de un script de PowerShell, y Zeek capturó una transferencia de datos cifrados hacia esa misma IP, entonces tienes un caso.

Este es el trabajo diario del analista de respuesta a incidentes: pivotar entre fuentes. Del log de CloudTrail a la instantánea del disco. De la alerta del IDS al PCAP. Del evento de Sysmon en el endpoint a la sesión SMB capturada por Zeek. La evidencia en la nube y en la red está fragmentada por diseño. El forense es el hilo que la une.

El elefante en la habitación: La legalidad y la jurisdicción

No podemos cerrar este artículo sin abordar el desafío que hace que muchos casos se caigan antes de empezar: la ley. Los datos en la nube no entienden de fronteras. Un usuario en España puede tener su cuenta de Microsoft en servidores de Irlanda, sus datos de Google en Estados Unidos y su CRM en Australia. Si necesitas acceder a esos datos para una investigación, ¿a qué ley te acoges? ¿Qué juez autoriza la intromisión?

Además, existen varias leyes en distintos países, que limitan severamente lo que un proveedor puede entregar en un litigio civil. En muchos casos, la vía más efectiva no es la citación judicial al proveedor (que puede tardar meses y entregar muy poco), sino obtener el consentimiento del titular de la cuenta o, en el caso de una empresa, actuar a través de la propia tenencia administrativa de la organización. El forense cloud debe tener, además de conocimientos técnicos, un asesor legal al lado. La evidencia más brillante es inútil si un juez la declara inadmisible por haberse obtenido de forma incorrecta.

Forense como arquitecto de la verdad

Hemos llegado al final de este recorrido. Empezamos con un forense llegando a una escena del crimen digital. Hoy lo dejamos frente a una pantalla, revisando logs de auditoría de tres proveedores distintos, correlacionando flujos de red y lidiando con abogados. El análisis forense en la nube y en redes corporativas es la disciplina más joven y, probablemente, la más compleja de todas.

Ya no se trata de encontrar una huella dactilar en un teclado. Se trata de reconstruir una identidad digital a partir de fragmentos dispersos por medio mundo. El forense de la nube no es un arqueólogo; es un arquitecto que construye un caso sólido sobre cimientos de logs, las API y los metadatos.

En esta serie nos hemos referido al mundo forense digital. La ciberseguridad no es solo prevenir; es, sobre todo, saber qué pasó cuando la prevención falla. Y en ese arte, los forenses son los últimos guardianes de la verdad. Por hoy es todo. Nos despedimos aquí en Código Seguro. Nos vemos el próximo viernes.