iam:PassRole: cómo funciona, cómo abusan de él los atacantes y cómo acotarlo

Ian Austin · 3 de noviembre de 2026 · 12 min de lectura

iam:PassRole es el permiso de AWS IAM que controla qué roles puede entregar un principal a un servicio de AWS, como el rol de ejecución de una función Lambda, el perfil de instancia de una instancia EC2 o el rol de servicio de un proyecto de CodeBuild. También es el permiso que aparece con más frecuencia en el Mapa de ataque de Pathbreak: el 55 por ciento de las rutas de escalada de privilegios del mapa dependen de él, y esas rutas alcanzan 23 servicios de AWS, porque cada servicio que ejecuta cargas de trabajo en tu nombre acepta un rol que le entregas. Es fácil concederlo de forma demasiado amplia, ya que un recurso comodín parece inofensivo en una revisión de políticas y el paso en sí nunca aparece en CloudTrail. Este artículo explica qué hace el permiso, las comprobaciones que hace AWS, cómo lo usa un atacante, qué muestran los registros y cómo acotarlo para que la ruta se cierre.

Qué es iam:PassRole

Muchos servicios de AWS actúan con un rol de IAM que les das al configurar un recurso. Una función Lambda se ejecuta como su rol de ejecución, una instancia EC2 obtiene credenciales de su perfil de instancia y un proyecto de CodeBuild llama a AWS con su rol de servicio. Entregar ese rol al servicio se llama pasar el rol, y AWS comprueba si quien hace la llamada tiene permiso para hacerlo.

Esa comprobación es iam:PassRole. La documentación de AWS deja claro que PassRole es un permiso y no tiene llamada a la API, así que no existe una operación PassRole en el SDK. El ARN del rol viaja como parámetro de otra llamada, como el parámetro Role de CreateFunction de Lambda, y el servicio comprueba el permiso iam:PassRole de quien hace la llamada mientras procesa esa llamada.

El permiso existe para impedir que un principal entregue a un servicio más acceso del que el propio principal tiene. Si un desarrollador sin permisos de Amazon S3 pudiera pasar un rol que permite S3, el servicio realizaría esas acciones de S3 en su nombre, que es exactamente la escalada sobre la que AWS advierte en esa misma página.

Las tres comprobaciones que hace AWS cuando se pasa un rol

La entrada del AWS Security Blog sobre PassRole establece tres condiciones que deben cumplirse todas antes de que un servicio pueda usar un rol pasado.

1. Quien hace la llamada tiene permiso para pasar ese rol. Una política basada en identidad de quien hace la llamada debe permitir iam:PassRole con el rol en el elemento Resource, deben cumplirse todas las condiciones de esa declaración y nada más puede denegarlo, incluidas las políticas de control de servicios, los límites de permisos, las políticas de sesión y las políticas de punto de enlace de VPC.
2. El rol confía en el servicio de destino. La política de confianza del rol debe permitir el principal de servicio, por ejemplo lambda.amazonaws.com para un rol de ejecución de Lambda. AWS señala que en algunos casos el recurso se crea igualmente cuando falta la confianza, pero entonces el servicio no puede usar el rol.
3. El rol y quien hace la llamada están en la misma cuenta. La Guía del usuario de IAM indica que iam:PassRole solo pasa un rol a un servicio de la misma cuenta de AWS, así que un diseño entre cuentas necesita un rol en la segunda cuenta que pueda asumir el primero.

Para un atacante, la segunda condición define la lista de objetivos. Cualquier rol de la cuenta cuya política de confianza nombre un servicio en el que el atacante pueda crear recursos es un candidato, y la primera condición decide si el atacante puede usarlo.

Dónde se produce la comprobación de PassRole

La comprobación se ejecuta siempre que se crea un recurso con un rol de servicio, y siempre que se actualiza un recurso existente con un rol nuevo. Cambiar el rol de ejecución de una función Lambda es una actualización de ese tipo, así que necesita el mismo permiso que crear la función.

Los servicios que usan roles vinculados a servicios suelen crear y administrar esos roles ellos mismos, así que no se produce ningún paso. Cuando un servicio te deja elegir un rol vinculado a un servicio, como un grupo de Amazon EC2 Auto Scaling creado con uno concreto, AWS comprueba iam:PassRole de la misma manera.

La tabla recoge algunas llamadas habituales que pasan un rol y el parámetro de la solicitud que lo lleva. Ese mismo parámetro es el que necesita leer una regla de detección.

El mapa recoge cada paso que Pathbreak rastrea, incluidos los trabajos de Glue, los trabajos de entrenamiento de SageMaker, las tareas de ECS, Step Functions y Bedrock AgentCore, y el Mapa de ataque puede filtrarse por iam:PassRole para verlos juntos.

Cómo abusan los atacantes de iam:PassRole

El abuso sigue los mismos tres pasos sea cual sea el servicio.

Encontrar un rol privilegiado que confíe en un servicio. iam:ListRoles devuelve la política de confianza de cada rol en el campo AssumeRolePolicyDocument, así que una sola llamada muestra qué roles confían en Lambda, EC2, CodeBuild o cualquier otro servicio. El atacante busca un rol con permisos amplios cuya política de confianza nombre un servicio en el que pueda crear recursos.

Crear un recurso con ese rol asociado. Con iam:PassRole sobre el rol y lambda:CreateFunction, el atacante crea una función cuyo rol de ejecución es el rol privilegiado. AWS acepta el paso porque la política de quien hace la llamada lo permite y el rol confía en lambda.amazonaws.com.

Ejecutar código como el rol. El atacante invoca la función, y el código que haya escrito se ejecuta con los permisos del rol privilegiado. Si el rol es un administrador, un solo create y un solo invoke bastan para hacerse con la cuenta. El mismo movimiento funciona a través de los user data de EC2, un buildspec de CodeBuild, una plantilla de CloudFormation o el script de un trabajo de Glue, y por eso una sola concesión demasiado amplia de iam:PassRole puede abrir muchas rutas a la vez.

La versión de Lambda de esta cadena, con los eventos de CloudTrail de cada paso, se trata en tres ataques de escalada de privilegios en AWS, con la evidencia de CloudTrail y la solución.

Por qué iam:PassedToService por sí sola no basta

iam:PassedToService es una clave de condición que limita a qué servicio puede pasarse un rol. Es útil, y la propia validación de políticas de AWS emite una advertencia de seguridad para iam:PassRole con un recurso comodín y recomienda usar ARN de rol concretos o esta condición. Sin embargo, las dos opciones distan mucho de ser equivalentes, porque la condición acota el servicio mientras el comodín sigue cubriendo todos los roles de la cuenta.

La política administrada de AWS AWSLambda_FullAccess muestra la diferencia con claridad. Concede lambda:*, iam:ListRoles y iam:GetRole, y permite iam:PassRole sobre "Resource": "*" con iam:PassedToService establecido en lambda.amazonaws.com. Un principal con esta política puede listar los roles de la cuenta, encontrar cualquier rol cuya política de confianza permita Lambda, crear una función con él e invocarla. Si un rol privilegiado de la cuenta confía en Lambda, la condición no hace nada para detener la escalada, porque el paso es realmente a Lambda.

La condición se gana su lugar cuando se combina con un recurso concreto. Un ARN de rol concreto decide qué rol puede pasarse, y la clave iam:PassedToService decide a qué servicio puede pasarse, lo que importa cuando un rol confía en más de un servicio.

Cómo detectar el abuso de iam:PassRole en CloudTrail

AWS indica que no se generan registros de CloudTrail para PassRole, así que la evidencia es siempre la llamada de creación o actualización que recibió el rol.

• Vigila el parámetro. En Lambda, es el evento de administración CreateFunction con el ARN del rol en sus parámetros de solicitud. La referencia de CloudTrail de Lambda muestra el nombre del evento como CreateFunction20150331, así que una regla debe buscar el prefijo del nombre del evento. La misma referencia señala que los parámetros Environment y ZipFile se omiten del registro, así que el código que subió el atacante no está en el evento.
• Compara el rol con quien hace la llamada. La señal fuerte es una llamada de creación que asocia un rol con más permisos que el principal que hace la llamada, sobre todo si procede de un principal sin historial de crear ese tipo de recurso.
• Activa los eventos posteriores. Invoke de Lambda es un evento de datos, y CloudTrail no lo registra por defecto, como confirma AWS. Habilitar los eventos de datos de Lambda permite que una regla empareje la creación con una invocación unos minutos después.
• Lee los fallos. CloudTrail registra las llamadas fallidas con un código de error y un mensaje de error. Cuando se rechaza un paso, el error que devuelve AWS nombra iam:PassRole y el ARN del rol, como se ve en la guía de solución de problemas de AWS. Una serie de llamadas de creación denegadas que nombran cada una un rol distinto es el aspecto que tiene un atacante que prueba qué roles puede pasar.

Una vez que el paso tiene éxito, la actividad del propio rol es el último lugar donde mirar. Las llamadas a la API hechas como el rol pasado desde una función o instancia que no existía una hora antes merecen una revisión más detenida.

Cómo acotar iam:PassRole

El objetivo es que cada principal solo pueda pasar los roles que su trabajo necesita, y solo a los servicios que los usan.

• Nombra los roles. Pon ARN de rol concretos en el elemento Resource. Donde se crean roles con frecuencia, usa una ruta de IAM como arn:aws:iam::111122223333:role/application_role/* o un prefijo de nombre, para que los roles nuevos de esa ruta queden cubiertos sin cambiar la política, como recomienda el AWS Security Blog.
• Añade iam:PassedToService. Úsala junto con un recurso concreto, para que un rol que confía en varios servicios solo pueda pasarse al que usa la carga de trabajo.
• Usa iam:AssociatedResourceArn donde encaje. Esta clave de condición limita a qué recurso puede asociarse un rol. Como algunos ARN de recurso cambian cuando el recurso se vuelve a crear, AWS señala que muchas organizaciones restringen en su lugar quién puede modificar el recurso.
• Evita el control basado en etiquetas. AWS advierte que las condiciones ResourceTag sobre iam:PassRole no dan resultados fiables, así que las etiquetas del rol son el control equivocado para este permiso.
• Protege las rutas privilegiadas con una SCP. Una política de control de servicios puede denegar iam:PassRole sobre una ruta protegida, por ejemplo los roles que usa un equipo de seguridad, salvo que quien hace la llamada lleve una etiqueta concreta o esté en una ruta aprobada.
• Limita los roles que crean los desarrolladores. Si los desarrolladores pueden crear sus propios roles, exige un límite de permisos en esos roles y permíteles pasar solo roles de una ruta dedicada, para que un rol que creen y luego pasen no pueda superar el límite.

Cada cambio mantiene la capacidad de la que depende el equipo y cierra las rutas que pasan por roles que nunca necesitó pasar.

Lo que acotar PassRole no soluciona

Acotar iam:PassRole cierra las rutas que empiezan con un recurso nuevo. No hace nada con los recursos que ya tienen un rol privilegiado asociado, porque cambiar lo que esos recursos ejecutan nunca pasa un rol. Estas rutas necesitan sus propios controles sobre los permisos de modificación.

• Código de funciones Lambda. lambda:UpdateFunctionCode sustituye el código de una función existente y deja su rol de ejecución en su sitio, así que el código del atacante se ejecuta como ese rol la próxima vez que se invoca la función.
• User data de EC2. Con ec2:StopInstances, ec2:ModifyInstanceAttribute y ec2:StartInstances, un atacante detiene una instancia, reescribe sus user data y la vuelve a iniciar. Por defecto, los user data solo se ejecutan en el primer arranque, así que el atacante aporta una configuración de cloud-init que se ejecuta en cada arranque, y el script se ejecuta con el perfil existente de la instancia.
• Comandos de SSM. ssm:SendCommand ejecuta un script en una instancia administrada, y ese script puede leer las credenciales del rol que ya tiene asociado.
• Roles de pilas de CloudFormation. AWS señala que, una vez que se asocia un rol de servicio a una pila, los usuarios que pueden operar sobre la pila pueden usar el rol tengan o no iam:PassRole, así que un principal que puede actualizar la pila o ejecutar un change set hereda el rol. La variante UpdateStack funciona de la misma manera.
• Proyectos de CodeBuild. Iniciar una compilación de un proyecto existente con un buildspec sustituido ejecuta los comandos del atacante con el rol de servicio del proyecto.

Una revisión de la cuenta que se detenga en iam:PassRole pasará por alto todos estos casos, y por eso el mapa los recoge como entradas separadas.

Cómo comprobar quién puede pasar un rol privilegiado

Para un principal y un rol, el simulador de políticas de IAM da una respuesta rápida. Evalúa las políticas basadas en identidad y las políticas de control de servicios, incluidas las condiciones, para el principal que indiques.

Cuando la política del principal usa iam:PassedToService, añade un argumento --context-entries que establezca la clave iam:PassedToService en el servicio de destino, como lambda.amazonaws.com, porque sin él el simulador no tiene ningún valor con el que comparar. El resultado solo responde a la primera de las tres comprobaciones. Si la política de confianza del rol permite el servicio es otra cuestión, que se responde leyendo el AssumeRolePolicyDocument del rol, y quien hace la llamada sigue necesitando el permiso de creación para ese servicio. AWS también señala que los resultados del simulador pueden diferir del entorno real.

Eso es manejable para un solo par e inviable en una cuenta con cientos de principales y roles. La herramienta gratuita y de código abierto pathbreak-audit lee la configuración de IAM de una cuenta y enumera los roles y usuarios que tienen permisos y combinaciones abusables, como iam:PassRole con una acción de creación, con la solución para cada uno, como punto de partida. Pathbreak va más allá: resuelve cada paso contra las políticas de quien hace la llamada, los límites, las SCP y la política de confianza del rol, de modo que solo se informan las rutas que de verdad tendrían éxito, clasificadas según lo que puede alcanzar el rol pasado.

Preguntas frecuentes