AWS Builder Center

Builder Center

Las credenciales robadas ahora también invocan tus modelos: AI Protection en las secuencias de ataque de GuardDuty

Un atacante consigue unas credenciales de IAM por phishing. Asi enumero permisos, toca un bucket y invoca un modelo de Amazon Bedrock que esas credenciales nunca habían usado. Cada acción, por separado, es una señal débil que quizá no dispara nada. La invocación anómala del modelo solo se une al resto de la cadena si una pieza está activada. Si no lo está, la secuencia de ataque se arma sin ella, y el equipo nunca ve que las credenciales que tocaron el bucket también estuvieron hurgando en tus modelos.

vtjean

Amazon GuardDuty incorporó el 17 de septiembre de 2026 los hallazgos de AI Protection como señales de correlación en las secuencias de ataque de Extended Threat Detection. Este artículo no vuelve a explicar qué es AI Protection, que ya tiene cobertura. Se centra en la correlación: cuáles de sus hallazgos entran en una secuencia de ataque, qué hace falta para que entren y qué punto ciego aparece si no lo activas. Cierra con un procedimiento de triaje y con las limitaciones.

Qué correlaciona Extended Threat Detection

Amazon GuardDuty Extended Threat Detection detecta ataques de varias etapas que cruzan fuentes de datos, tipos de recurso y tiempo dentro de una cuenta. En lugar de mirar cada evento por separado, correlaciona una secuencia de acciones y genera un solo hallazgo de secuencia de ataque.
La pieza clave es el concepto de señal. Una señal es cualquier evento que GuardDuty evalúa cuando busca actividad sospechosa. Una señal débil es la que, por sí sola, no apunta con claridad a una amenaza: una invocación de modelo desde una IP nueva no prueba un ataque, solo una desviación. Extended Threat Detection gana su valor cuando une esas señales débiles con otras acciones y con hallazgos ya conocidos de GuardDuty.
Tres detalles del funcionamiento condicionan todo lo demás:
  • Todos los hallazgos de secuencia de ataque son de severidad Critical, por la naturaleza de los escenarios que representan.
  • GuardDuty correlaciona dentro de una ventana móvil de 24 horas.
  • La correlación no considera los hallazgos archivados, incluidos los que se archivan de forma automática por reglas de supresión. Una regla de supresión puede, sin querer, dejar fuera una señal que habría completado la secuencia. Conviene revisar las reglas de supresión existentes.
Extended Threat Detection se habilita de forma automática en toda cuenta de GuardDuty, sin costo adicional, y amplía su alcance a medida que activas más planes de protección.

Los tres hallazgos de AI Protection

Cuando activas AI Protection, GuardDuty analiza eventos de administración y de datos de AWS CloudTrail de Amazon Bedrock, Amazon Bedrock AgentCore y Amazon SageMaker AI, y genera uno de tres tipos de hallazgo. En los tres, el tipo de recurso es AccessKey, es decir, identifican la identidad de IAM que invocó el modelo, y los tres tienen severidad por defecto Low:
  • Impact:IAMUser/AnomalousModelInvocation: una identidad de IAM invocó un modelo de Amazon Bedrock o Amazon SageMaker AI de una forma que se desvía de la línea base histórica de esa identidad o cuenta. GuardDuty perfila la API de invocación, el modelo, la dirección IP de origen y su ASN, y el user agent. Mapea a la técnica AML.T0040 de MITRE ATLAS.
  • Impact:IAMUser/CostHarvesting: una identidad invocó un modelo con volúmenes de tokens anómalos que pueden indicar un ataque de agotamiento de costo, en el que el atacante envía entradas caras para inflar el gasto del modelo sin necesariamente sacar datos. Mapea a AML.T0034.
  • Impact:IAMUser/PromptInjection.Direct: un guardrail de Amazon Bedrock detectó un intento de inyección directa de prompt en una invocación. Requiere un guardrail de Amazon Bedrock con un filtro de ataque de prompt. Sin guardrail, no hay señal.
La severidad Low de los tres es importante para entender por qué la correlación cambia tanto el panorama. Por separado, un hallazgo Low puede perderse entre el ruido. Dentro de una secuencia de ataque, se convierte en parte de un hallazgo Critical.

Cómo entran en la secuencia

Para que las señales de tus cargas de IA entren en una secuencia AttackSequence:IAM/CompromisedCredentials, tienes que activar AI Protection. Con AI Protection activado, GuardDuty puede usar los tres hallazgos anteriores como señales de correlación.
El ejemplo que da la documentación es directo: un atacante usa las mismas credenciales comprometidas para hacer una invocación anómala de un modelo de Amazon Bedrock o Amazon SageMaker AI. GuardDuty correlaciona esa invocación con otras acciones sospechosas hechas con esas credenciales y las representa como un solo hallazgo AttackSequence:IAM/CompromisedCredentials.
Hay una frase de la documentación que conviene no perder de vista: por sí solos, los hallazgos de AI Protection no generan una secuencia de ataque. No son el disparador. Son una señal más que se suma a una cadena que ya se está formando con otras acciones de las mismas credenciales.

El punto ciego

Aquí está el verdadero tema del artículo. Si AI Protection no está activado, GuardDuty no puede generar los tipos de hallazgo de AI Protection. Y si no puede generarlos, no puede incluir en la secuencia de ataque nada de lo que ocurra en tus modelos. La cadena se arma igual, con la enumeración, el acceso al bucket y la escalada, pero sin la parte de IA. El equipo que investiga el hallazgo Critical ve una historia incompleta.
Esto se agrava con dos condiciones:
  • PromptInjection.Direct solo aparece si hay un guardrail de Amazon Bedrock con filtro de ataque de prompt. Sin guardrail, el ataque ocurre y no hay hallazgo, así que tampoco entra en la secuencia.
  • Las reglas de supresión que archivan hallazgos los sacan de la correlación. Un hallazgo de AI Protection suprimido no suma a la secuencia.
El patrón es el mismo en los tres casos: la secuencia de ataque solo es tan completa como las señales que la alimentan. Activar AI Protection, hacer cumplir los guardrails de forma amplia y revisar las reglas de supresión no son tres tareas sueltas. Son lo que determina si la cadena que ves incluye lo que pasó en tus modelos o lo omite.

Señal, objetivo y runbook

El hilo de esta serie encaja aquí.
La señal es una invocación anómala de un modelo ligada a credenciales que ya están haciendo otras cosas sospechosas. Esa combinación, no la invocación sola, es lo que importa.
El objetivo lo pone el equipo. Una meta razonable es que ninguna carga de IA en producción quede fuera de la correlación: AI Protection activado en todas las cuentas, guardrails de Amazon Bedrock aplicados de forma amplia y reglas de supresión revisadas para que no archiven señales de IA. Es una meta de cobertura, no un umbral que el servicio imponga.
El runbook es la respuesta a un hallazgo AttackSequence:IAM/CompromisedCredentials que incluye señales de IA: remediar las credenciales comprometidas y acotar los permisos de invocación de modelos.

Runbook de triaje

Un procedimiento que un equipo de seguridad puede adaptar:
  1. Antes de depender de la correlación, activa AI Protection en las cuentas que ejecutan cargas de Amazon Bedrock o Amazon SageMaker AI. Sin ella, las secuencias de ataque no incluyen la actividad de los modelos.
  2. Aplica los guardrails de Amazon Bedrock de forma amplia, por cuenta o por organización, para que PromptInjection.Direct tenga señal desde el primer día en lugar de depender de que cada aplicación adjunte el guardrail.
  3. Revisa las reglas de supresión. Si alguna archiva hallazgos de AI Protection, esas señales no entran en la correlación.
  4. Cuando llegue un hallazgo AttackSequence:IAM/CompromisedCredentials, abre la secuencia y revisa si incluye alguno de los tres hallazgos de AI Protection. Si los incluye, las credenciales tocaron tus modelos.
  5. Remedia las credenciales comprometidas siguiendo la guía de GuardDuty para credenciales de AWS potencialmente comprometidas.
  6. Acota el acceso a las APIs de invocación de modelos a las identidades que de verdad las necesitan. La documentación de cada hallazgo lista las acciones de Amazon Bedrock y Amazon SageMaker AI que conviene restringir.
  7. Si el hallazgo fue CostHarvesting, revisa el gasto del modelo y considera controles de presupuesto además del ajuste de permisos.

Limitaciones

  • Los hallazgos de AI Protection no generan por sí solos una secuencia de ataque. Son señales de correlación que se suman a una cadena formada por otras acciones de las mismas credenciales.
  • Sin AI Protection activado, GuardDuty no genera esos hallazgos y la secuencia de ataque no incluye nada de la actividad en los modelos.
  • PromptInjection.Direct depende de un guardrail de Amazon Bedrock con filtro de ataque de prompt. Sin guardrail, no hay hallazgo.
  • La correlación usa una ventana móvil de 24 horas y no considera hallazgos archivados ni suprimidos. Una regla de supresión puede dejar fuera una señal de IA.
  • Los tres hallazgos tienen severidad por defecto Low de forma individual. Su peso aparece al entrar en una secuencia Critical, no antes.
  • AnomalousModelInvocation y CostHarvesting aplican a Amazon Bedrock y Amazon SageMaker AI. PromptInjection.Direct aplica solo a cargas de Amazon Bedrock que usan guardrails.
  • La correlación con señales de IA se documenta para la secuencia AttackSequence:IAM/CompromisedCredentials. La documentación consultada no describe su entrada en otros tipos de secuencia de ataque.

Recursos

# amazon-guardduty# amazon-bedrock# amazon-bedrock-agentcore# ai-security
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article