Panorama: cuando la identidad es el perímetro#

Todos los capítulos anteriores de esta Parte suponen, en el fondo, un modelo de centro de datos: hay máquinas, hay una red que las conecta, y comprometer el entorno es conquistar máquinas y moverse por esa red. La nube rompe ese modelo, y el red team que la ataca tiene que cambiar de raíz su forma de pensar. En un proveedor de nube no hay una «adentro» de red que conquistar —los recursos son servicios gestionados a los que se accede por una interfaz de programación (API) desde cualquier parte—, y no hay un perímetro físico que atravesar. Lo que hay es un plano de control (control plane) gobernado por identidades y políticas: quién es cada actor y qué se le permite hacer. El atacante en la nube, por eso, rara vez explota una vulnerabilidad de memoria o un servicio sin parchear; abusa de permisos mal puestos.

La tesis que ordena todo el capítulo se puede enunciar de una vez, y es la misma que la arquitectura de seguridad presentó como corrección del modelo de perímetro: en la nube, la identidad es el perímetro. Si no hay un «adentro» confiable por ubicación de red, lo único que decide cada acceso es la identidad del actor y los permisos que tiene asignados. Esa es exactamente la lógica del zero trust, y la nube es su encarnación más pura: cada llamada a la API se autentica y se autoriza por identidad, sin importar de dónde venga. La consecuencia ofensiva es directa —el objetivo del atacante deja de ser una máquina y pasa a ser una credencial de identidad con permisos, y el camino al control total es una cadena de identidades que van otorgando cada vez más autoridad—. Es, estructuralmente, el mismo juego que la Parte 4 jugó en el Active Directory: la identidad como terreno de batalla; solo que el terreno ahora es un proveedor de nube en lugar de un dominio, y los mecanismos son distintos.

El capítulo es material de dominio actual, sin base destilada que lo respalde, y se organiza en los dos planos donde vive el red team de nube: la identidad corporativa (con Entra ID como referente) y la infraestructura (con AWS como referente), más los puentes entre la nube y el dominio local que caracterizan los entornos reales.

flowchart TB
  I["la identidad es el perímetro\n(no hay 'adentro' de red)"]
  I --> ID["plano identidad · Entra ID\ndevice-code · consent grant · robo de token · service principals"]
  I --> IN["plano infra · AWS/IAM\nenum · privesc por política · SSRF→metadata · assume-role"]
  ID --> C["control del entorno\n(cadena de identidades con más autoridad)"]
  IN --> C
  H["dominio local (P4)"] -.->|"puente híbrido\nsincronización de identidad"| I

El plano de la identidad: Entra ID#

Entra ID —el servicio antes llamado Azure AD— es el proveedor de identidad que autentica a los usuarios de las organizaciones que viven en la nube de Microsoft, y su compromiso equivale a las llaves del reino corporativo. Los ataques contra él no rompen criptografía ni servicios: manipulan los flujos de autenticación y consentimiento que el propio sistema ofrece.

El phishing de código de dispositivo (device code phishing) abusa de un flujo legítimo pensado para dispositivos sin teclado cómodo —televisores, consolas—: el atacante inicia el flujo, obtiene un código, y convence a la víctima de introducirlo en el portal legítimo de Microsoft e iniciar sesión; al hacerlo, la víctima autoriza la sesión del atacante, que recibe tokens válidos sin haber capturado nunca la contraseña ni el segundo factor. El consentimiento ilícito de aplicaciones (illicit consent grant) sigue una lógica parecida: el atacante registra una aplicación y convence a la víctima de concederle permisos sobre sus datos —leer su correo, su calendario—; una vez concedido el consentimiento, la aplicación accede a esos datos con un token propio que sobrevive al cambio de contraseña, porque no depende de la credencial de la víctima sino del permiso otorgado. Y el robo de tokens —incluido el token primario de actualización que Windows mantiene para el inicio de sesión único— permite reproducir la sesión de un usuario ya autenticado sin volver a pasar por el segundo factor.

Para persistir, el mecanismo predilecto son los principales de servicio (service principals) y los registros de aplicación. Una aplicación en Entra ID puede tener sus propias credenciales y permisos, independientes de cualquier usuario; un atacante que crea una aplicación con permisos amplios, o que agrega una credencial nueva a una existente, consigue un acceso que no está atado a ninguna cuenta humana y que la rotación de contraseñas de usuarios no toca. Es el equivalente en la nube de las persistencias sigilosas del host: un actor no-humano, legítimo a los ojos del sistema, con las llaves puestas.

El plano de la infraestructura: AWS e IAM#

En el proveedor de infraestructura —AWS como caso de referencia— el terreno es la gestión de identidad y acceso (Identity and Access Management, IAM): el sistema de usuarios, roles, grupos y políticas que decide qué puede hacer cada actor sobre cada recurso. El red team en IAM es, casi por definición, un ejercicio de encontrar y encadenar permisos mal puestos.

La enumeración es el primer paso: con cualquier credencial, el atacante lista sus propios permisos y los del entorno para mapear qué puede hacer y qué caminos de escalada existen. La escalada de privilegios en IAM no explota software: abusa de permisos que, combinados, permiten a un actor otorgarse más autoridad de la que tiene. Un permiso para pasar un rol a un servicio (iam:PassRole), uno para crear una versión nueva de una política (iam:CreatePolicyVersion), uno para modificar la política de confianza de un rol: cada uno, aislado, parece inocuo; encadenados, permiten a un actor con permisos limitados convertirse en administrador. Es el análogo cloud de las cadenas de listas de control de acceso que la Parte 4 recorrió en el Active Directory —el privilegio se escala componiendo permisos, no explotando fallos—.

Hay un puente que conecta esta Parte consigo misma y merece destacarse: el servicio de metadatos de instancia (Instance Metadata Service, IMDS). Cada máquina virtual en la nube puede consultar, en una dirección interna fija, los metadatos de su propia configuración —incluidas las credenciales temporales del rol que tiene asignado—. Si una aplicación que corre en esa máquina es vulnerable a una falsificación de petición del lado servidor (SSRF), el atacante puede hacer que la aplicación consulte ese servicio de metadatos por él y le entregue las credenciales del rol de la máquina. Así, una vulnerabilidad web clásica se convierte en un pie dentro de la infraestructura de nube: la SSRF que la Parte 3 trató como lectura de recursos internos es, en la nube, un robo de credenciales de IAM. La versión endurecida del servicio de metadatos mitiga en parte este puente, pero las configuraciones antiguas lo dejan abierto, y es una de las cadenas de compromiso de nube más comunes.

Persistencia en la nube y los puentes híbridos#

Persistir en la nube tiene su propio repertorio, coherente con la tesis de la identidad como perímetro. En lugar de un servicio o una clave de registro en un host, el atacante crea claves de acceso nuevas para una identidad comprometida, modifica políticas de confianza de roles para que un actor externo pueda asumirlos, o esconde su acceso en la automatización del entorno —funciones que se ejecutan ante eventos, tareas programadas de la plataforma—. Como en el host, el principio es el mismo: suscribir la propia autoridad a un mecanismo que la nube ya honra, de modo que sobreviva a la limpieza de la credencial original.

Los entornos reales rara vez son puros: la mayoría son híbridos, con un Active Directory local sincronizado con la identidad de nube. Esa sincronización es un puente que el red team recorre en ambos sentidos. El servidor que sincroniza las identidades tiene credenciales de alto privilegio en los dos mundos, y comprometerlo abre el camino del dominio local a la nube y viceversa. Los mecanismos de inicio de sesión único entre el dominio y la nube, si se los abusa, permiten a un atacante que domina el Active Directory local forjar accesos a la nube. El puente híbrido es, por eso, uno de los objetivos de mayor valor: conecta el terreno de la Parte 4 con el de este capítulo, y quien controla la costura controla los dos lados.

Defensa y detección: la ventaja del registro de la API#

El cierre púrpura de la nube tiene una particularidad que juega a favor del defensor: como todo acceso pasa por la API, todo acceso se puede registrar. La nube no tiene los puntos ciegos de red que tiene un centro de datos; tiene un registro central de cada llamada, y el problema defensivo es de análisis, no de visibilidad.

El primer plano es la telemetría de actividad: los registros de todas las llamadas a la API —el historial de acciones de la plataforma— son el equivalente en la nube de los registros de eventos del host, y contienen la firma de cada maniobra ofensiva descrita arriba. Un consentimiento de aplicación nuevo, un flujo de código de dispositivo iniciado desde una ubicación anómala, una clave de acceso creada, una política de IAM modificada, un rol asumido desde un origen inusual: todos quedan registrados, y la detección consiste en correlacionarlos con el resto de la actividad. Los servicios de detección gestionada de cada proveedor —y la defensa de identidad de la Parte 5— construyen alertas sobre exactamente estas señales.

El segundo plano es la gestión de la identidad como control, que es la contracara de la tesis: si la identidad es el perímetro, endurecerla es la defensa central. El mínimo privilegio aplicado a IAM —revisar y podar los permisos excesivos, que son el combustible de la escalada— es el control de mayor retorno; la disciplina emergente de gestión de derechos en la nube (CIEM) existe para eso. El acceso condicional —exigir segundo factor, restringir por dispositivo o ubicación, bloquear flujos de autenticación legados como el del código de dispositivo cuando no se usan— corta de raíz varias de las técnicas de identidad. Y la vigilancia específica de los actores no-humanos —los principales de servicio, las claves de acceso, sus permisos y su antigüedad— cierra la vía de persistencia más sigilosa. En la nube, más que en ningún otro terreno del manual, la seguridad se gana o se pierde en la configuración de la identidad; el atacante lo sabe, y por eso el defensor tiene que saberlo primero.

Referencias#