AWS Auto Scaling: seis endpoints dejaban en CloudTrail "AWS Internal" en lugar de la IP y el user-agent del que llama

Resumen

AWS CloudTrail es el servicio que guarda, para cada cliente, el registro de las llamadas que se hacen a la API de AWS: qué acción se ejecutó, cuándo, con qué identidad, desde qué dirección IP y con qué cliente (el campo UserAgent). Para un equipo de respuesta a incidentes es una de las fuentes principales para seguir el rastro de un intruso.

El investigador encontró seis endpoints del servicio AWS Auto Scaling que, al ser invocados, no registraban en CloudTrail la información real de red ni el user-agent de quien hacía la llamada. En su lugar, esos campos aparecían con el valor AWS Internal, como si la petición la hubiese originado la propia infraestructura de AWS.

El fallo se clasificó como registro insuficiente (CWE-778, Insufficient Logging) con severidad media. El investigador señala que no es un caso aislado: antes había reportado el mismo comportamiento en otros servicios de AWS, en concreto Pinpoint SMS and Voice, Kendra y Comprehend Medical.

Cronología: enviado el 11 de noviembre de 2025 y divulgado el 5 de enero de 2026, con estado resuelto.

Pasos de reproducción

En el reporte divulgado, los dos comandos de AWS CLI y la lista de los seis endpoints afectados están censurados, así que solo se puede describir el método:

1. Ejecutar con AWS CLI una llamada de referencia a una API que CloudTrail registra con normalidad.
2. Esperar entre 5 y 10 minutos a que el evento aparezca en CloudTrail.
3. Abrir el evento y comprobar que el campo UserAgent y la dirección IP de origen están rellenos con los datos reales del cliente.
4. Ejecutar con AWS CLI una llamada a uno de los endpoints afectados de AWS Auto Scaling.
5. Esperar de nuevo entre 5 y 10 minutos a que el evento llegue a CloudTrail.
6. Abrir ese segundo evento: el campo UserAgent y la información de red aparecen como AWS Internal, sin rastro de la IP ni del sistema operativo o la herramienta de quien hizo la llamada.

Impacto

Quien disponga de credenciales válidas en una cuenta (por ejemplo, unas claves robadas) podía usar esos seis endpoints sin que CloudTrail dejase constancia de su dirección IP ni de su user-agent. Eso dificulta a los defensores:

• localizar desde dónde se está operando y bloquear esa IP;
• distinguir la actividad del intruso de la del cliente legítimo por la herramienta o el sistema operativo que usa;
• correlacionar esas acciones con otras peticiones del mismo atacante que sí quedaron registradas.

La acción en sí sigue apareciendo en el log; lo que se pierde es el contexto de red y de cliente que permite atribuirla.

Remediación

El reporte figura como resuelto por AWS, pero el texto divulgado no detalla en qué consistió el arreglo.

Qué aprender de este caso

• Al auditar los logs de un proveedor cloud, no basta con comprobar que la acción aparece: compara servicio por servicio que campos como la IP de origen y el UserAgent contienen los datos reales del cliente y no un valor genérico como AWS Internal.
• El mismo fallo se repitió en varios servicios de AWS (Pinpoint, Kendra, Comprehend Medical y ahora Auto Scaling): cuando aparece un defecto de registro en un servicio, merece la pena probar sistemáticamente los endpoints del resto, sobre todo los menos usados.
• En detección, conviene revisar con lupa los eventos de CloudTrail con AWS Internal asociados a una identidad de usuario (y no a un rol de servicio), en lugar de darlos siempre por actividad interna de confianza.