El equipo de seguridad de Amazon documenta metodologías de investigación forense en CloudTrail a partir de escenarios de acceso no autorizado, minería de criptomonedas y abuso de servicios de IA
Amazon Web Services publicó una guía técnica de respuesta a incidentes que documenta cómo su equipo interno de seguridad (AWS Security Incident Response Team, SIRT) investiga actividad sospechosa en entornos de nube a través del análisis de logs de CloudTrail. La publicación, difundida a través del blog oficial de seguridad de AWS, se estructura alrededor de tres escenarios reales de compromiso: acceso no autorizado entre cuentas con implicancias de ransomware, operaciones de minería de criptomonedas y abuso de servicios de inteligencia artificial. El documento está dirigido a equipos de operaciones de seguridad, ingeniería de nube, cumplimiento y liderazgo técnico que necesitan ir más allá de consultas básicas en CloudTrail para realizar análisis forenses completos.
Cómo el equipo de AWS estructura la investigación de eventos de seguridad en la nube
La guía define un marco de técnicas de ataque que el equipo SIRT utiliza para clasificar actividad maliciosa en entornos AWS. Este marco incluye reconocimiento (fase inicial donde un actor de amenaza recopila información sobre el entorno objetivo, como listar buckets de Amazon S3), enumeración (catalogación sistemática de recursos específicos para identificar objetivos potenciales), movimiento lateral (cuando un atacante se desplaza de un recurso a otro dentro del mismo entorno, por ejemplo de una instancia EC2 a un servicio de IA), escalada de privilegios (intentos de obtener permisos de nivel superior, como crear usuarios administradores o modificar políticas de IAM), evasión de defensa (técnicas para evitar detección, como operar en regiones de AWS donde el monitoreo podría ser menos robusto), persistencia (establecimiento de acceso continuo mediante creación de nuevos usuarios IAM o claves de acceso), cosecha de credenciales (robo de credenciales de autenticación para suplantar usuarios legítimos) y exfiltración (transferencia no autorizada de datos fuera del entorno).
Cada escenario documentado incluye diagramas de arquitectura que muestran la progresión de eventos, logs de CloudTrail anotados que destacan campos significativos, marcos de investigación con preguntas específicas que formular durante el análisis, y lecciones aprendidas con medidas preventivas. El enfoque metodológico que presenta AWS se basa en reconocer patrones, entender contexto y pensar como un atacante — un cambio de perspectiva respecto del análisis superficial de eventos aislados.
El caso de acceso entre cuentas que reveló un patrón de ransomware en desarrollo
El primer escenario documentado comenzó con una alerta automatizada sobre eliminación múltiple de objetos en un bucket de S3 llamado customer-important-data. Lo que inicialmente parecía una eliminación no autorizada directa resultó ser un incidente entre cuentas con implicancias de ransomware. El análisis de CloudTrail mostró que la actividad comenzó con una llamada a la API ListBuckets realizada a través de un rol asumido a las 14:31:22 UTC. El registro contenía una sesión nombrada dev-migration-script usando el rol CrossAccountS3Access. Aunque el acceso entre cuentas es común en entornos empresariales, los investigadores de SIRT notaron que los nombres de sesión típicamente reflejan unidades de negocio legítimas — los atacantes frecuentemente usan técnicas de enmascaramiento para que recursos no autorizados parezcan legítimos.
La cadena de eventos mostró que el actor de amenaza asumió el rol CrossAccountS3Access desde una cuenta confiable, listó buckets de S3 para identificar objetivos, listó objetos dentro del bucket objetivo para catalogar contenidos, y ejecutó eliminaciones programadas de tres archivos en un lapso de 13 segundos. Cada eliminación devolvió un código de estado HTTP 204 (exitoso). Este patrón de reconocimiento seguido de enumeración y acción automatizada es característico de operaciones de ransomware en fase de preparación — la eliminación rápida y programada sugiere que el atacante estaba probando capacidades antes de ejecutar un ataque a mayor escala.
Por qué IMDSv1 sigue siendo un vector de riesgo en instancias EC2 comprometidas
La guía dedica atención específica a la técnica de server-side request forgery (SSRF), donde un usuario no autorizado engaña a un servidor para que realice solicitudes en su nombre, frecuentemente contra el endpoint de Amazon EC2 Instance Metadata Service. El documento explica que IMDSv1 (Instance Metadata Service versión 1) proporciona credenciales temporales a aplicaciones que se ejecutan en instancias EC2. IMDSv1 en sí mismo no es inherentemente inseguro, pero cuando una aplicación con vulnerabilidades (por ejemplo, una susceptible a SSRF) se ejecuta en la instancia, un usuario no autorizado puede usar esa aplicación para alcanzar el endpoint de metadatos y recuperar credenciales.
IMDSv2 mitiga este riesgo al requerir tokens de autenticación basados en sesiones, lo que dificulta significativamente la explotación mediante SSRF. Sin embargo, la persistencia de IMDSv1 en entornos de producción — ya sea por compatibilidad con aplicaciones legacy o por falta de actualización de configuraciones — mantiene abierto este vector de ataque. El equipo SIRT documenta que en investigaciones reales han observado atacantes que primero comprometen una aplicación web vulnerable en una instancia EC2, luego usan SSRF para acceder a IMDSv1, obtienen credenciales temporales del rol asociado a la instancia, y finalmente pivotan hacia otros servicios de AWS con esas credenciales robadas.
Qué revela el patrón de minería de criptomonedas y abuso de servicios de IA sobre exposición en la región
Los otros dos escenarios documentados — operaciones de minería de criptomonedas y abuso de servicios de inteligencia artificial — comparten un patrón común: los atacantes aprovechan recursos de cómputo elástico y servicios de alto procesamiento para monetizar acceso no autorizado sin necesariamente exfiltrar datos. En el caso de minería de criptomonedas, el objetivo es lanzar instancias de cómputo de alto rendimiento en regiones donde el monitoreo podría ser menos robusto (una técnica de evasión de defensa), ejecutar software de minería, y dejar que la víctima absorba los costos de infraestructura. En el caso de abuso de servicios de IA, el patrón es similar pero orientado a consumir cuotas de servicios de machine learning para revender capacidad o entrenar modelos propios.
Para organizaciones en América Latina que operan cargas de trabajo en AWS, estos escenarios tienen implicancias directas de exposición estructural. La dependencia de configuraciones por defecto en servicios de nube — particularmente el uso de IMDSv1 sin migración a IMDSv2, roles de IAM con permisos excesivamente amplios, y falta de alertas automatizadas sobre actividad en regiones no utilizadas habitualmente — es común en implementaciones que priorizan velocidad de despliegue sobre configuración de seguridad. Brasil y México, que concentran la mayor parte de la infraestructura de nube empresarial en la región, enfrentan el mismo patrón de riesgo que AWS documenta en estos casos: acceso legítimo mal configurado que se convierte en vector de compromiso cuando un atacante obtiene credenciales iniciales mediante phishing, vulnerabilidades en aplicaciones web o claves de acceso filtradas en repositorios públicos.
Nuestro análisis
Lo significativo de esta publicación no es la novedad de las técnicas documentadas — SSRF contra IMDS, abuso de roles entre cuentas y minería de criptomonedas en infraestructura comprometida son vectores conocidos desde hace años — sino la decisión de AWS de documentar públicamente metodologías de investigación forense que su equipo interno utiliza en casos reales. Esta transparencia operativa contrasta con la práctica habitual de proveedores de nube de publicar únicamente guías de mejores prácticas sin contexto de incidentes concretos. Al estructurar la guía alrededor de cadenas de eventos completas (desde reconocimiento inicial hasta objetivo final del atacante), AWS está formalizando un marco de análisis que va más allá de la detección de eventos aislados hacia la comprensión de patrones de comportamiento malicioso.
El énfasis en IMDSv1 como vector de riesgo persistente revela una tensión no resuelta en entornos de nube empresariales: la coexistencia de configuraciones legacy necesarias para compatibilidad con configuraciones modernas de seguridad. IMDSv2 está disponible desde 2019, pero la migración requiere validación de compatibilidad con aplicaciones existentes — un proceso que muchas organizaciones postergan indefinidamente. La guía no proporciona datos sobre qué porcentaje de instancias EC2 en producción todavía usa IMDSv1, pero el hecho de que AWS dedique espacio significativo a documentar ataques basados en esta configuración sugiere que la adopción de IMDSv2 sigue siendo incompleta años después de su lanzamiento. ¿Cuántos incidentes de compromiso en entornos de nube de la región siguen explotando configuraciones que tienen mitigación disponible pero no implementada por fricción operativa?