Ocho vectores de ataque descubiertos en AWS Bedrock: la infraestructura de IA es el nuevo frente de batalla

Los investigadores de XM Cyber han cartografiado ocho rutas de ataque validadas dentro de AWS Bedrock que permiten a los adversarios secuestrar agentes de IA, envenenar prompts, robar bases de conocimiento y debilitar las medidas de seguridad, todo ello sin tocar el propio modelo.

🔍 Por qué es importante

AWS Bedrock es la plataforma insignia de Amazon para crear aplicaciones basadas en IA. Conecta modelos fundacionales directamente con datos empresariales: instancias de Salesforce, bibliotecas de SharePoint, funciones Lambda y buckets de S3. Esa conectividad es lo que la hace potente y también lo que la convierte en un objetivo.

Cuando un agente de IA puede consultar tu CRM, activar funciones sin servidor o extraer información de una base de conocimiento, se convierte en un nodo de tu infraestructura con permisos, accesibilidad y rutas hacia activos críticos. El equipo de investigación de amenazas de XM Cyber ha demostrado que una sola identidad con privilegios excesivos basta para comprometer toda la pila de IA.

⚡ Los ocho vectores de ataque

1. Ataques contra los registros de invocación de modelos

Bedrock registra cada interacción con los modelos para garantizar el cumplimiento normativo. Los atacantes pueden redirigir los registros a buckets de S3 controlados por ellos mediante bedrock:PutModelInvocationLoggingConfiguration y capturar silenciosamente cada prompt. Una segunda variante utiliza s3:DeleteObject para borrar las pruebas de las actividades de jailbreak.

2. Ataques contra las fuentes de datos de las bases de conocimiento

Las fuentes de datos conectadas mediante RAG (S3, Salesforce, SharePoint y Confluence) son directamente accesibles. Un atacante con acceso s3:GetObject puede eludir por completo el modelo y extraer datos empresariales sin procesar. Peor aún: las credenciales robadas pueden permitir el movimiento lateral hacia Active Directory.

3. Ataques contra los almacenes de datos de las bases de conocimiento

Las bases de datos vectoriales como Pinecone y Redis Enterprise Cloud almacenan conocimiento indexado. Las credenciales expuestas en StorageConfiguration proporcionan a los atacantes acceso administrativo completo a los índices vectoriales y a todos los datos estructurados de Aurora o Redshift.

4. Ataques directos contra agentes

Con permisos bedrock:UpdateAgent, los atacantes pueden reescribir el prompt base de un agente para filtrar instrucciones internas y esquemas de herramientas. En combinación con bedrock:CreateAgentActionGroup, pueden adjuntar ejecutores maliciosos a agentes legítimos, lo que permite modificar bases de datos sin autorización bajo la apariencia de flujos de trabajo normales de IA.

5. Ataques indirectos contra agentes

En lugar de atacar la configuración del agente, los atacantes se dirigen a las funciones Lambda auxiliares. Mediante lambda:UpdateFunctionCode o lambda:PublishLayer, inyectan código malicioso en las llamadas a herramientas de las que dependen los agentes, exfiltrando datos o manipulando respuestas de forma invisible.

6. Ataques de inyección en flujos

Bedrock Flows define flujos de trabajo de IA de varios pasos. Los atacantes con bedrock:UpdateFlow pueden inyectar nodos auxiliares de S3 o Lambda y redirigir entradas sensibles hacia endpoints controlados por ellos sin alterar la lógica de la aplicación. También pueden modificar nodos condicionales para eludir las comprobaciones de autorización.

7. Degradación de las medidas de seguridad

Las medidas de seguridad filtran contenido tóxico, bloquean la inyección de prompts y ocultan información de identificación personal. Un atacante con bedrock:UpdateGuardrail puede reducir sistemáticamente los umbrales y hacer que los modelos sean vulnerables a la manipulación. Con bedrock:DeleteGuardrail, las defensas desaparecen por completo.

8. Envenenamiento de prompts gestionados

Bedrock Prompt Management centraliza las plantillas utilizadas por distintas aplicaciones. Los atacantes con bedrock:UpdatePrompt pueden modificar las plantillas sobre la marcha e inyectar instrucciones como «ignora las reglas de seguridad» o «incluye enlaces del atacante». Los cambios no activan un nuevo despliegue, lo que dificulta enormemente su detección.

🎯 Idea clave: el modelo no es el objetivo

Los ocho vectores comparten un patrón común: los atacantes se dirigen a los permisos, las configuraciones y las integraciones que rodean al modelo, no al propio modelo. La seguridad tradicional de la IA se ha centrado en la inyección de prompts y el jailbreak, pero pasa por alto la verdadera superficie de ataque: las políticas de IAM, las configuraciones de las fuentes de datos y la infraestructura que conecta la IA con los sistemas empresariales.

🛡️ Medidas inmediatas para los equipos de seguridad

1. Audita las políticas de IAM de Bedrock: aplica el principio de mínimo privilegio a todos los permisos bedrock:*, lambda:* y s3:* vinculados a cargas de trabajo de IA
2. Supervisa los cambios en la configuración de los registros: genera una alerta ante cualquier llamada a PutModelInvocationLoggingConfiguration
3. Cifra y rota las credenciales: todas las credenciales de fuentes y almacenes de datos deben utilizar AWS Secrets Manager con rotación automática
4. Protege las configuraciones de los agentes: restringe UpdateAgent y CreateAgentActionGroup exclusivamente a las canalizaciones de CI/CD
5. Controla las versiones de los prompts: trata los prompts gestionados como código y exige revisión, aprobación y registros de auditoría para cualquier cambio
6. Cartografía tu superficie de ataque de IA: utiliza la gestión de la exposición para identificar todas las rutas desde las cargas de trabajo de IA hasta los activos críticos
7. Comprueba la resiliencia de las medidas de seguridad: verifica periódicamente que no puedan debilitarse mediante cambios de configuración

📊 Implicaciones para NIS2 y DORA

Para las organizaciones de la EU, estos hallazgos tienen un impacto normativo directo. NIS2 exige la gestión de riesgos de la cadena de suministro y la notificación de incidentes significativos. El compromiso de la infraestructura de IA, especialmente a través de servicios en la nube de terceros, entra plenamente dentro de su ámbito de aplicación. El marco de gestión de riesgos de las TIC de DORA exige que las entidades financieras cartografíen y prueben todas sus dependencias operativas digitales, incluida la automatización basada en IA.

Las organizaciones que utilizan AWS Bedrock en producción deben documentar estos vectores de ataque en sus evaluaciones de riesgos y validar los controles como parte de su programa de cumplimiento de NIS2.