Explotación del Servicio de Metadatos en la Nube: La Puerta Abierta de IMDSv1 a las Credenciales de AWS ☁️

Introducción: La Puerta Oculta a tu Reino en la Nube

En el panorama de seguridad en la nube, pocas vulnerabilidades permanecen tan persistentes en su explotación y, al mismo tiempo, son fundamentalmente prevenibles como el AWS Instance Metadata Service versión 1 (IMDSv1). Aunque fue introducido hace más de una década como una función de conveniencia para instancias EC2, IMDSv1 se ha convertido en lo que los investigadores de seguridad llaman la “llave maestra” para entornos AWS—un servicio aparentemente inocuo que, cuando se explota mediante ataques de Server-Side Request Forgery (SSRF), otorga a los atacantes acceso completo a credenciales IAM temporales, metadatos de la instancia y potencialmente toda tu infraestructura en la nube.

Las apuestas no podrían ser mayores. La infame brecha de Capital One en 2019, que expuso más de 100 millones de registros de clientes y resultó en una multa de 80 millones de dólares, no fue resultado de un exploit sofisticado de zero-day ni de una amenaza persistente avanzada. Fue un ataque SSRF directo dirigido a IMDSv1—una vulnerabilidad que AWS conocía desde al menos 2018. Sin embargo, en diciembre de 2024, solo el 32% de las instancias EC2 han migrado a IMDSv2, dejando a la gran mayoría de la infraestructura en la nube expuesta a los mismos vectores de ataque que devastaron Capital One.

Esta guía exhaustiva investiga cómo los ataques SSRF explotan los endpoints de metadatos en la nube, por qué el servicio de metadatos de AWS sigue siendo un objetivo crítico para el robo de credenciales y escalada de privilegios, y qué deben hacer las organizaciones para proteger su infraestructura en la nube antes de convertirse en la próxima noticia.

Entendiendo el Servicio de Metadatos de la Instancia: Conveniencia y Vulnerabilidad

¿Qué es IMDS y por qué existe?

El AWS Instance Metadata Service es un endpoint API accesible desde dentro de las instancias EC2 en la dirección IP local especial 169.254.169.254. Esta dirección está intencionadamente no enrutable en internet, lo que significa que solo el software que se ejecuta directamente en una instancia EC2 puede acceder a ella—o eso fue lo que se diseñó.

IMDS fue creado para resolver un desafío fundamental de seguridad en la nube: ¿cómo pueden las aplicaciones que corren en instancias EC2 acceder de forma segura a los recursos de AWS sin codificar credenciales? El servicio ofrece una solución elegante al hacer disponibles credenciales IAM temporales y rotativas localmente en la instancia, eliminando la necesidad de incrustar claves de acceso sensibles en el código de la aplicación o archivos de configuración.

Más allá de las credenciales, IMDS expone metadatos críticos de la instancia incluyendo:

• ID de la instancia, ID de la AMI y tipo de instancia
• Configuración de red (direcciones IP, grupos de seguridad, subredes)
• Nombre del rol IAM y credenciales temporales asociadas
• Datos de usuario y scripts de inicialización
• Mapeos de dispositivos de bloque e información de almacenamiento

Estos metadatos permiten que las aplicaciones se auto-configuren, autentiquen con los servicios de AWS y se adapten dinámicamente a su entorno—una capacidad poderosa que se ha convertido en fundamental para la arquitectura moderna en la nube.

El fallo fatal: Arquitectura de solicitud-respuesta de IMDSv1

IMDSv1 funciona con un modelo simple de solicitud-respuesta que requiere solo solicitudes HTTP GET. Cualquier proceso capaz de hacer llamadas HTTP a 169.254.169.254 puede recuperar los metadatos de la instancia sin autenticación, gestión de sesiones o verificaciones de autorización. Este diseño incluye varias suposiciones de seguridad críticas:

1. Suposición de frontera de confianza: El servicio asume que cualquier solicitud originada desde dentro de la instancia es legítima
2. Sin autenticación: IMDSv1 no realiza ninguna verificación del origen de la solicitud
3. Sin gestión de sesiones: Cada solicitud es completamente independiente sin seguimiento de estado
4. Sin validación de solicitudes: El servicio no distingue entre solicitudes legítimas y intentos de explotación

Estas suposiciones crean lo que los investigadores llaman una “vulnerabilidad de divulgación de información no autenticada”—pero la realidad es mucho más grave porque la información divulgada incluye credenciales completas de AWS.

Entrando en IMDSv2: Seguridad basada en sesiones

En noviembre de 2019, cuatro meses después de la brecha de Capital One, AWS lanzó IMDSv2 con protecciones de defensa en profundidad diseñadas específicamente para mitigar ataques SSRF. IMDSv2 implementa una arquitectura orientada a sesiones que requiere un proceso de autenticación en dos pasos:

Paso 1: Generación de token

PUT http://169.254.169.254/latest/api/token
X-aws-ec2-metadata-token-ttl-seconds: 21600

Esta solicitud PUT genera un token de sesión con un valor de tiempo de vida (TTL) especificado entre 1 segundo y 6 horas.

Paso 2: Solicitudes autenticadas

GET http://169.254.169.254/latest/meta-data/
X-aws-ec2-metadata-token: AQAAANpaYGqH...

Todas las solicitudes subsiguientes deben incluir el token en la cabecera X-aws-ec2-metadata-token.

Esta arquitectura bloquea efectivamente la explotación SSRF porque:

• Los atacantes deben controlar tanto los métodos HTTP (GET y PUT)
• Los atacantes deben inyectar cabeceras HTTP personalizadas
• El enfoque basado en tokens previene la explotación simple mediante URL
• Los límites TTL reducen la ventana de oportunidad incluso si los tokens son comprometidos

A pesar de estas protecciones robustas y de que AWS hace de IMDSv2 el valor predeterminado para nuevos lanzamientos de Console Quick Start desde noviembre de 2023, la transición aún no está completa. El informe de Estado de Seguridad en la Nube 2024 de Datadog revela que el 68% de las instancias EC2 todavía no aplican IMDSv2, representando millones de instancias potencialmente vulnerables en todo el ecosistema de AWS.

Server-Side Request Forgery: La Vía de Explotación de IMDS

Anatomía de un ataque SSRF

Server-Side Request Forgery es una vulnerabilidad en aplicaciones web que permite a los atacantes manipular un servidor para realizar solicitudes HTTP no deseadas a destinos especificados por el atacante. SSRF figura en las 10 principales vulnerabilidades de OWASP y ha sido utilizada de forma constante contra servicios de metadatos en la nube desde su introducción.

El problema fundamental es que muchas aplicaciones web aceptan URLs suministradas por el usuario como entrada—para vistas previas de URLs, callbacks de webhooks, procesamiento de documentos, obtención de imágenes o integraciones API—y luego hacen solicitudes HTTP a esas URLs sin validación adecuada. Cuando estas aplicaciones se ejecutan en instancias EC2 con IMDSv1 habilitado, se convierten en conductos para la explotación del servicio de metadatos.

La cadena de ataque de IMDSv1

La cadena completa de ataque progresa a través de varias fases distintas:

Fase 1: Reconocimiento Los atacantes comienzan identificando aplicaciones web alojadas en EC2 mediante varias técnicas: - Análisis de registros DNS y rangos IP - Identificación de infraestructura AWS a través de cabeceras, mensajes de error o tiempos de respuesta - Escaneo de aplicaciones accesibles públicamente - Explotación de otras vulnerabilidades para obtener un primer acceso

Fase 2: Descubrimiento de vulnerabilidades SSRF Los atacantes prueban vulnerabilidades SSRF mediante la prueba de campos de entrada de usuario que puedan desencadenar solicitudes HTTP en el servidor: - Parámetros URL en funciones de vista previa o fetch - Endpoints de configuración de webhooks - Mecanismos de carga de archivos que aceptan URLs - Puntos de inyección XXE (entidades externas XML) - Vulnerabilidades de redirección abierta - Servicios de generación PDF

Fase 3: Acceso al servicio de metadatos Una vez identificado un vector SSRF, los atacantes crean solicitudes dirigidas al servicio de metadatos:

https://vulnerable-app.com/preview?url=http://169.254.169.254/latest/meta-data/

La aplicación realiza esta solicitud y devuelve los metadatos, revelando categorías de información disponibles.

Fase 4: Extracción de credenciales IAM Luego, los atacantes enumeran roles IAM y extraen credenciales:

http://169.254.169.254/latest/meta-data/iam/security-credentials/
→ Devuelve: "ec2-production-role"

http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-production-role
→ Devuelve: {
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2024-12-08T01:23:45Z"
}

Fase 5: Uso de credenciales Con credenciales AWS válidas, los atacantes configuran la CLI o SDK de AWS:

export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

aws sts get-caller-identity
# Confirma identidad y rol

Fase 6: Escalada de privilegios y movimiento lateral Dependiendo de los permisos del rol IAM, los atacantes pueden: - Listar y acceder a buckets S3 con datos sensibles - Enumerar otros recursos AWS - Lanzar instancias EC2 adicionales - Modificar grupos de seguridad y controles de acceso en red - Acceder a bases de datos, secretos y datos de configuración - Pivotar a otras cuentas AWS mediante asunción de roles

Caso real de explotación: Estudio de caso Capital One

La brecha de Capital One en 2019 ofrece el estudio de caso definitivo en la explotación de IMDSv1. Los días 22 y 23 de marzo de 2019, un atacante (identificado posteriormente como la ex empleada de AWS Paige Thompson) explotó una configuración incorrecta en un firewall de aplicaciones web (WAF) en EC2. La metodología del ataque demuestra cómo las fallas organizacionales agravan las vulnerabilidades técnicas:

Ruta técnica del ataque: 1. Identificación de configuración de WAF ModSecurity que permite ejecución de comandos 2. Explotación de vulnerabilidad SSRF en la aplicación detrás del WAF 3. Acceso al servicio de metadatos en 169.254.169.254 4. Obtención del rol IAM llamado *****-WAF-Role 5. Extracción de credenciales temporales desde el endpoint del rol 6. Uso de credenciales para listar buckets S3 mediante CLI de AWS 7. Sincronización de más de 700 buckets S3 con datos de clientes (aproximadamente 30GB) 8. Exfiltración de 106 millones de registros de clientes incluyendo: - 140,000 números de Seguro Social - 80,000 números de cuenta bancaria - 1 millón de números de Seguro Social canadienses - Información personal extensa (nombres, direcciones, puntajes de crédito, historial de pagos)

Las fallas acumuladas: - Configuración incorrecta del WAF que permitió acceso no autorizado a aplicaciones backend - Vulnerabilidad SSRF en la aplicación web sin detectar - IMDSv1 proporcionó acceso a credenciales sin autenticación - Rol IAM con permisos demasiado permisivos que otorgaba amplio acceso a S3 - Falta de monitoreo de egresos que permitió detectar la exfiltración masiva de datos - La detección tomó casi cuatro meses (descubierto el 19 de julio de 2019)

Las consecuencias: - Multa civil de 80 millones de dólares por reguladores bancarios - Más de 50 millones en multas y acuerdos - Daño reputacional incalculable - Demandas colectivas de clientes afectados - Procesamiento penal del atacante

AWS lanzó IMDSv2 en noviembre de 2019, pocos meses después de que la brecha se hiciera pública. El momento no fue casual—el incidente de Capital One demostró de manera concluyente que la falta de protecciones en IMDSv1 generaba riesgos inaceptables.

Campañas de explotación activa

La amenaza no ha disminuido desde 2019. Los investigadores de seguridad continúan observando campañas activas dirigidas a IMDS:

Campaña marzo 2025: F5 Labs documentó una campaña coordinada dirigida a sitios web alojados en EC2, explotando vulnerabilidades SSRF para acceder a IMDSv1. La campaña utilizó infraestructura de ASN 34534 (FBW NETWORKS SAS) en Francia y Rumanía, demostrando un objetivo organizado y persistente.

Campaña UNC2903 (2021): Mandiant identificó al actor de amenazas UNC2903 explotando CVE-2021-21311 en la herramienta de gestión de bases de datos Adminer. Los atacantes usaron un relay con scripts de redirección 301 para engañar a los servidores víctimas y exponer credenciales API de AWS vía IMDS.

Investigación continua de vulnerabilidades: Los informes de programas de recompensas de errores como HackerOne incluyen vulnerabilidades relacionadas con IMDS, incluyendo hallazgos críticos que afectan a organizaciones como el Departamento de Defensa de EE. UU. y DuckDuckGo, demostrando que las cadenas de ataque SSRF a IMDS siguen siendo viables y valiosas para los atacantes.

Por qué IMDSv1 sigue siendo un objetivo crítico

El problema de la persistencia

A pesar de que IMDSv2 está disponible desde 2019 y es el valor predeterminado desde noviembre de 2023, su adopción sigue siendo alarmantemente baja. Varios factores contribuyen a esta persistencia:

Infraestructura heredada: Las organizaciones que ejecutan instancias EC2 de varios años pueden nunca haber revisado su configuración del servicio de metadatos. Estas instancias de larga duración siguen usando IMDSv1 a menos que se migren manualmente.

Compatibilidad de software: SDKs antiguos de AWS, bibliotecas de terceros y aplicaciones personalizadas pueden no soportar IMDSv2 con tokens, requiriendo actualizaciones de código.

Inercia organizacional: Las migraciones requieren coordinación entre desarrollo, operaciones y seguridad. Sin patrocinio ejecutivo o presión regulatoria, estas iniciativas se priorizan menos.

Brechas de conocimiento: Muchas organizaciones desconocen los riesgos. Los equipos de desarrollo enfocados en funcionalidad pueden no entender las implicaciones de seguridad a nivel de infraestructura.

Percepción de complejidad: Aunque AWS ofrece herramientas robustas, el proceso requiere inventario, pruebas y despliegue coordinado—esfuerzos que compiten con otras prioridades.

El multiplicador de escalada de privilegios

Lo que hace a IMDSv1 particularmente peligroso es su papel como mecanismo de escalada de privilegios. Una vulnerabilidad SSRF menor en una aplicación web de bajo privilegio puede proporcionar instantáneamente a los atacantes los permisos completos del rol IAM de la instancia. Esto crea escenarios donde:

• Una simple función de vista previa de URL se convierte en una puerta de entrada a bases de datos de producción
• Un endpoint de prueba de webhooks expone contenidos de buckets S3
• Un servicio de procesamiento de archivos otorga acceso a sistemas de gestión de secretos
• Una herramienta de desarrollo proporciona acceso administrativo en AWS

El límite de seguridad colapsa porque el servicio de metadatos no distingue entre solicitudes legítimas y controladas por atacantes.

El punto dulce del robo de credenciales

Desde la perspectiva de un atacante, la explotación de IMDSv1 ofrece ventajas únicas:

Sin necesidad de autenticación: A diferencia de otras técnicas de robo de credenciales, acceder a IMDSv1 no requiere contraseñas, claves API o tokens.

Temporales pero suficientes: Aunque las credenciales son temporales (generalmente válidas de 6 a 12 horas), esta ventana da tiempo suficiente para reconocimiento, exfiltración de datos y movimiento lateral.

Dificultad en detección: El acceso a credenciales vía IMDS parece comportamiento normal de la instancia, dificultando distinguirlo del tráfico legítimo sin monitoreo especializado.

Desafíos de auditoría: IMDSv1 no ofrece capacidades nativas de registro o auditoría. Las organizaciones a menudo no tienen visibilidad de qué procesos acceden al servicio de metadatos y cuándo.

Claves de contexto en políticas: Las credenciales obtenidas vía IMDSv1 incluyen la clave de contexto ec2:RoleDelivery: "1.0", que puede usarse en políticas IAM para restringir su uso—pero solo si las organizaciones las han implementado, lo cual la mayoría no ha.

Estrategias de detección y migración

Identificando uso de IMDSv1

Las organizaciones deben primero entender su exposición actual a IMDSv1 antes de implementar protecciones. AWS ofrece varios mecanismos de detección:

Visibilidad en la consola de AWS: La consola EC2 muestra una columna “IMDSv2” que indica la configuración de cada instancia. Las que muestran “Optional” tienen IMDSv1 habilitado, mientras que “Required” indica operación solo con IMDSv2.

Reglas de AWS Config: La regla gestionada ec2-imdsv2-check monitorea continuamente las configuraciones del servicio de metadatos y marca las instancias no conformes.

AWS Security Hub: Control EC2.8 (“Las instancias de Amazon EC2 deben usar la Versión 2 del Servicio de Metadatos”) proporciona visibilidad centralizada en todas las cuentas y regiones, con capacidades de agregación y consolidación organizacional.

Métricas de CloudWatch: La métrica MetadataNoToken rastrea la frecuencia de llamadas IMDSv1 por instancia, ayudando a identificar qué instancias y aplicaciones usan el servicio heredado.

Analizador de paquetes IMDS: Herramienta de código abierto que captura tráfico de red para identificar y registrar llamadas IMDSv1 desde una instancia, identificando qué software necesita actualizaciones.

Seguridad en la carga de trabajo en la nube de Datadog: Soluciones de terceros como CWS de Datadog implementan reglas de detección en red que identifican llamadas IMDSv1 en tiempo real, superando limitaciones de las herramientas nativas de AWS.

La hoja de ruta de migración

La migración exitosa a IMDSv2 requiere planificación y ejecución sistemática en tres fases:

Fase 1: Evaluación y planificación (Semana 1-2)

1. Inventario del estado actual: Usa AWS Config y Security Hub para identificar todas las instancias habilitadas para IMDSv1 en todas las cuentas y regiones.

2. Análisis de dependencias de aplicaciones: Implementa el Analizador de paquetes IMDS en instancias representativas para identificar qué aplicaciones y bibliotecas acceden a los metadatos.

3. Priorizar cargas críticas: Comienza con despliegues nuevos y entornos no productivos, luego avanza a sistemas en producción según evaluación de riesgos.

4. Actualizar pila de software: Asegura que SDKs, CLIs y frameworks de AWS soporten IMDSv2:

   • AWS CLI v2.x soporta IMDSv2 de forma nativa
   • SDKs de AWS lanzados después de 2020 soportan IMDSv2
   • Actualiza agentes de gestión (SSM, CloudWatch)
   • Prueba aplicaciones personalizadas con autenticación basada en tokens

Fase 2: Aplicación gradual (Semana 3-8)

1. Habilitar soporte IMDSv2: Configura instancias para soportar ambas versiones mientras monitoreas problemas:

   aws ec2 modify-instance-metadata-options \
   --instance-id i-1234567890abcdef0 \
   --http-tokens optional \
   --http-endpoint enabled
   

   1. Monitorear transición: Observa métricas MetadataNoToken en CloudWatch para identificar llamadas IMDSv1 restantes.
   2. Aplicar IMDSv2: Cuando el uso de IMDSv1 caiga a cero, fuerza IMDSv2 exclusivo: bash aws ec2 modify-instance-metadata-options \ --instance-id i-1234567890abcdef0 \ --http-tokens required

2. Actualizar plantillas de lanzamiento: Modifica plantillas de lanzamiento EC2 y configuraciones de Auto Scaling para requerir IMDSv2 en nuevas instancias:

   {
   "MetadataOptions": {
   "HttpTokens": "required",
   "HttpPutResponseHopLimit": 1,
   "HttpEndpoint": "enabled"
   }
   }
   

   Fase 3: Aplicación y prevención continua 1. Implementar políticas de control de servicios (SCPs): Impide el uso de IMDSv1 en toda la organización en AWS Organizations:

   {
   "Version": "2012-10-17",
   "Statement": [{
   "Sid": "RequireIMDSv2",
   "Effect": "Deny",
   "Action": "ec2:RunInstances",
   "Resource": "arn:aws:ec2:*:*:instance/*",
   "Condition": {
     "StringNotEquals": {
       "ec2:MetadataHttpTokens": "required"
     }
   }
   }]
   }
   

3. Bloquear credenciales IMDSv1: Usa políticas IAM para impedir que credenciales obtenidas vía IMDSv1 accedan a recursos sensibles:

   {
   "Version": "2012-10-17",
   "Statement": [{
   "Sid": "RequireIMDSv2Credentials",
   "Effect": "Deny",
   "Action": "*",
   "Resource": "*",
   "Condition": {
     "NumericLessThan": {
       "ec2:RoleDelivery": "2.0"
     }
   }
   }]
   }
   

   1. Remediación automática: Implementa documentos de automatización de AWS Systems Manager como EnforceEC2InstanceIMDSv2 para configurar automáticamente instancias no conformes.

   2. Monitoreo continuo: Mantén reglas de Security Hub y alarmas de CloudWatch para detectar regresiones a configuración IMDSv1.

      Defensa en profundidad: Más allá de IMDSv2

      Mientras IMDSv2 aborda la explotación SSRF en IMDS, la seguridad en la nube requiere defensas en capas: Seguridad en aplicaciones:

   • Validación robusta de entrada en URLs suministradas por usuarios

   • Uso de listas blancas en dominios permitidos

   • Implementación de Web Application Firewalls con reglas de detección SSRF

   • Pruebas regulares de seguridad incluyendo evaluaciones de vulnerabilidades SSRF Principio de menor privilegio en IAM:

   • Otorga a los roles de instancia permisos mínimos necesarios

   • Evita permisos con comodines (ej. s3:*, *:*)

   • Usa permisos a nivel de recurso para limitar alcance

   • Audita y elimina permisos no utilizados regularmente Segmentación de red:

   • Implementa grupos de seguridad que restrinjan tráfico saliente

   • Usa endpoints VPC para acceso a servicios AWS en lugar de enrutamiento por internet

   • Despliega monitoreo de red para patrones de egreso inusuales

   • Considera bloquear 169.254.169.254 en Capa 3 cuando sea apropiado Monitoreo y alertas:

   • Habilita AWS CloudTrail para todo registro de actividad API

   • Configura AWS GuardDuty para detección de amenazas

   • Implementa integración SIEM

   • Crea alertas para patrones inusuales de acceso al servicio de metadatos

   • Monitorea transferencias de datos grandes a destinos externos Gestión de secretos:

   • Evita almacenar datos sensibles en S3 sin cifrado

   • Usa AWS Secrets Manager o Parameter Store para secretos

   • Implementa políticas en buckets S3 que restrinjan acceso

   • Habilita registros y monitoreo en buckets S3

     Lecciones de la industria y perspectivas futuras

     La realidad de la responsabilidad compartida

     La brecha de Capital One generó un intenso debate sobre responsabilidad del proveedor en la nube versus responsabilidad del cliente. AWS sostiene que la brecha fue resultado de configuraciones incorrectas del cliente—la vulnerabilidad SSRF, roles IAM demasiado permisivos y configuraciones de firewall. Los críticos argumentan que AWS conocía los riesgos SSRF en IMDSv1 desde 2018 pero no implementó mitigaciones hasta después de una brecha importante. La realidad es matizada: la seguridad en la nube es realmente compartida. AWS proporciona las herramientas y configuraciones seguras por defecto (como IMDSv2), pero los clientes deben usarlas efectivamente. Como señaló Evan Johnson, ex gerente de seguridad de productos en Cloudflare: “Hay mucho conocimiento especializado que viene con operar un servicio en AWS, y para alguien sin ese conocimiento, [los ataques SSRF] no serían algo que apareciera en ninguna guía de configuración crítica.” Las organizaciones deben entender que adoptar la nube requiere experiencia en seguridad que va más allá de la infraestructura tradicional. La suposición de que seguir la documentación de AWS garantiza seguridad es falsa—debes comprender el panorama de amenazas, reconocer vulnerabilidades arquitectónicas y aplicar defensas en profundidad de manera proactiva.

     La línea de tiempo hacia la universalidad de IMDSv2

     AWS ha estado fortaleciendo continuamente los requisitos de IMDSv2:

   • Noviembre 2019: Lanzamiento de IMDSv2

   • Noviembre 2023: La consola Quick Start por defecto usa IMDSv2

   • Mitad de 2024: Nuevos tipos de instancia EC2 usan IMDSv2 por defecto

   • En curso: AWS sigue promoviendo la migración mediante documentación, herramientas y controles a nivel de cuenta Sin embargo, la transición sigue siendo voluntaria para instancias existentes. AWS no ha anunciado planes para forzar la migración de instancias heredadas a IMDSv2, probablemente por preocupaciones de romper cargas de trabajo de clientes. Esto significa que las organizaciones deben completar sus propias migraciones.

     Aprendiendo de otros incidentes

     La explotación de IMDSv1 no es exclusiva de Capital One. Varias organizaciones han sufrido brechas similares, aunque muchas no se reportan por acuerdos de confidencialidad o divulgación incompleta:

   • Instituciones financieras han remediado silenciosamente vulnerabilidades SSRF a IMDS tras evaluaciones de seguridad

   • Agencias gubernamentales han reforzado su infraestructura en la nube tras pruebas de penetración exitosas

   • Empresas tecnológicas han descubierto robo de credenciales vía IMDS durante investigaciones de incidentes El patrón es consistente: vulnerabilidades SSRF comunes, IMDSv1 aún prevalente, y la combinación crea riesgos críticos.

     Conclusión: La necesidad imperante de actuar

     Seis años después de la brecha de Capital One, IMDSv1 sigue siendo una vulnerabilidad crítica que afecta a la mayoría de la infraestructura AWS. A pesar de que AWS ofrece mitigaciones robustas mediante IMDSv2, la adopción generalizada ha sido lenta, dejando a las organizaciones expuestas a vectores de ataque bien conocidos y activamente explotados. La imperativa de seguridad es clara: toda organización que ejecute instancias EC2 debe migrar a IMDSv2 y deshabilitar IMDSv1 por completo. Esto no es una mejora de seguridad “agradable de tener”—es un requisito fundamental para la higiene de seguridad en la nube, equivalente a parchear vulnerabilidades críticas o aplicar autenticación multifactor. El proceso de migración requiere esfuerzo, coordinación y pruebas, pero la alternativa es aceptar el riesgo de convertirse en la próxima brecha mediática. Las herramientas, documentación y capacidades de automatización existen para facilitar esta transición. Lo único que falta es el compromiso organizacional.

     Tu plan de acción desde ahora

     Esta semana:

   • Ejecuta la regla de AWS Config ec2-imdsv2-check para inventariar tu estado actual

   • Habilita el control EC2.8 en AWS Security Hub para monitoreo continuo

   • Identifica y prioriza cargas críticas para migrar Este mes:

   • Implementa el Analizador de paquetes IMDS en instancias representativas

   • Actualiza SDKs, CLIs y dependencias a versiones compatibles con IMDSv2

   • Comienza a aplicar IMDSv2 en entornos no productivos Este trimestre:

   • Completa la migración a IMDSv2 en todas las instancias de producción

   • Implementa SCPs que prevengan nuevas instancias IMDSv1

   • Despliega políticas IAM que bloqueen el uso de credenciales IMDSv1

   • Realiza pruebas de seguridad para verificar protecciones SSRF La revolución en la nube prometió seguridad, escalabilidad y simplicidad. El servicio de metadatos de AWS cumplió esa promesa—pero solo si las organizaciones lo usan de forma segura. IMDSv1 fue un diseño aceptable para 2012. En 2024 y más allá, es un riesgo inaceptable. La brecha de Capital One costó más de 150 millones de dólares y expuso 106 millones de registros. La brecha de tu organización costará diferente, pero costará.

     La elección es tuya: migrar proactivamente a IMDSv2 en tu cronograma, o reaccionar tras una brecha. La historia ha demostrado qué camino es menos doloroso.

     Sobre el Autor: Este análisis se basa en la última investigación en seguridad, documentación de AWS y reportes de incidentes reales hasta diciembre de 2024. Las organizaciones deben consultar con profesionales calificados en seguridad en la nube para implementar estas recomendaciones. Referencias: Blog de Seguridad de AWS, Labs de Seguridad de Datadog, Inteligencia de Amenazas de Mandiant, Fundación OWASP, ACM Transactions on Privacy and Security