En la nube no hay un disco que clonar ni un servidor que precintar: la evidencia son registros de auditoría con retención limitada que el propio atacante puede desactivar. Reconstruir un acceso no autorizado en AWS consiste en correlacionar qué identidad llamó a qué API, con qué credencial y desde dónde, y hacerlo antes de que esos registros expiren.
Decirlo por adelantado evita expectativas equivocadas y es parte del deber de objetividad del perito (art. 335.2 LEC).
Fundamentalmente CloudTrail, que registra las llamadas a la API de gestión: qué identidad ejecutó cada acción, con qué credencial, desde qué dirección IP y con qué agente de usuario. A eso se suman los VPC Flow Logs, que documentan las conexiones pero no su contenido; los hallazgos de GuardDuty; los registros de acceso a S3 si estaban activados; y AWS Config, que permite ver cómo cambió la configuración de cada recurso a lo largo del tiempo. Lo determinante es cómo estaba configurado todo eso antes del incidente: en un forense de nube, la evidencia disponible se decide meses antes de que ocurra nada.
No necesariamente, y el propio intento suele ser revelador. Detener un rastro o modificar sus selectores de eventos es a su vez una llamada a la API que queda registrada hasta ese instante, con la identidad y la dirección IP que la ejecutó. Si el rastro escribía en un bucket con retención o, mejor, en una cuenta separada, lo ya escrito permanece aunque después se borre la configuración. Quedan además fuentes independientes que el atacante rara vez cubre por completo: Flow Logs, hallazgos de GuardDuty, registros de facturación y trazas de la propia aplicación. El informe refleja la interrupción como un hecho y acota la ventana ciega resultante.
Combinando el análisis estático de los permisos con la traza real de acciones. Por un lado se reconstruyen las políticas efectivas de la identidad comprometida en el momento del incidente y se identifican las rutas que permitían ampliarlos: crear una nueva versión de una política gestionada, adjuntar políticas adicionales, modificar una relación de confianza para asumir un rol más privilegiado o pasar un rol a un servicio de cómputo. Por otro, se comprueba en los registros cuáles de esas acciones se ejecutaron efectivamente y en qué orden. Una ruta teóricamente posible no acredita un abuso; el registro de su ejecución sí lo hace.
El método es el mismo y las fuentes son equivalentes, aunque cambien los nombres y el detalle de cada una: registros de actividad y de auditoría, registros de flujo de red, servicio propio de detección de amenazas y un modelo de identidad con sus propias rutas de escalada. Tampoco cambian las limitaciones estructurales: retención finita, registro de eventos de datos habitualmente desactivado por defecto y un modelo de responsabilidad compartida que deja la capa del proveedor fuera del alcance del cliente. En entornos híbridos, el grueso del trabajo consiste en unir esa traza con la del directorio corporativo y la de los equipos locales.
Consulta inicial confidencial y sin compromiso. Le diremos con franqueza si hay prueba que obtener y cómo.
contacto@peritiaforense.com