Los cibercriminales están cada vez más interesados ​​en la nube a medida que aumenta su adopción. Una campaña de extorsión que compromete recursos AWS a través de credenciales recopiladas de archivos de entorno (.env) Fue descubierto por investigadores de la Unidad 42 en Palo Alto.Estos archivos se almacenaron de forma insegura en servidores web. Incluían claves de acceso de AWS, credenciales para bases de datos y cuentas de redes sociales, claves API para aplicaciones SaaS y servicios de mensajería, y tokens de acceso para varios servicios en la nube del hiperescalador.

La operación fue descubierta mientras los investigadores investigaban un entorno de AWS comprometido que estaba siendo utilizado de forma abusiva para ejecutar escaneos automáticos contra otros dominios. Los expertos determinaron que los atacantes extrajeron archivos .env de aproximadamente 110.000 dominios, lo que llevó a la exposición de más de 90.000 variables de entorno únicas, incluidas 7.000 que correspondían a servicios en la nube utilizados por empresas. "No todas las filtraciones contenían necesariamente cuentas de usuario o secretos, pero todas revelaban detalles sobre la infraestructura interna de la víctima o su configuración", dijeron los expertos en el informe. Entre los ejemplos de credenciales filtradas se incluyen 1.185 claves de acceso únicas de AWS, 333 tokens OAuth de PayPal, 235 tokens de GitHub, 111 claves de API de HubSpot, 39 webhooks de Slack y 27 tokens de DigitalOcean.

Índice
  1. La configuración incorrecta expone las variables del entorno
  2. Movimientos laterales en entornos AWS
  3. 230 millones de objetivos únicos
  4. Exfiltración de datos, extorsión y asesoramiento

La configuración incorrecta expone las variables del entorno

Muchos marcos de desarrollo y aplicaciones web almacenan datos de configuración importantes en archivos .env. Los servidores web deben configurarse para evitar el acceso a los archivos . (punto) de forma predeterminada, ya que se supone que son archivos ocultos que nunca deben ser accesibles al público. Sin embargo, los errores de configuración ocurren con regularidad. Otro ejemplo es la carpeta .git, que almacena información de configuración importante para el sistema de control de versiones del código fuente git.

La exposición accidental de archivos .env o .git es un problema conocido, que otros investigadores suelen destacar. Por ello, no es inusual que los atacantes lancen bots que escaneen la web en busca de dichos archivos expuestos en la carpeta raíz de los dominios. Sin embargo, la escala de la operación descubierta por la Unidad 42 de Palo Alto Networks sugiere que este tipo de configuraciones erróneas siguen siendo generalizadas.

Movimientos laterales en entornos AWS

En manos de atacantes expertos, los secretos filtrados pueden ser muy peligrosos. Después de obtener una clave de acceso de AWS, los atacantes la usaron para ejecutar una llamada a la API GetCallerIdentity para verificar la identidad o el rol asignado a la credencial expuesta. También realizaron acciones de reconocimiento adicionales al llamar a ListUsers para recopilar una lista de usuarios de administración de identidad y acceso (IAM) en la cuenta de AWS y a ListBuckets para identificar todos los buckets de S3 existentes.

En el entorno de AWS comprometido que se investigó, los atacantes se dieron cuenta de que el rol de IAM de AWS expuesto que habían obtenido no tenía privilegios de administrador en todos los recursos. Sin embargo, sí tenía permiso para crear nuevos roles de IAM y asociar políticas específicas a los roles existentes. Luego procedieron a crear otro rol llamado lambda-ex y le asociaron la política AdministratorAccess, logrando así la escalada de privilegios. “Tras la creación exitosa del rol de IAM privilegiado, el atacante intentó crear dos pilas de infraestructura diferentes, una utilizando recursos de Amazon Elastic Cloud Compute (EC2) y la otra con AWS Lambda”, dijeron los investigadores. “Al realizar estas tácticas de ejecución, los actores no lograron crear un grupo de seguridad, un par de claves y una instancia de EC2, pero crearon con éxito múltiples funciones lambda con el rol de IAM recién creado asociado”.

230 millones de objetivos únicos

AWS Lambda es una plataforma sin servidor diseñada para aprovisionar automáticamente recursos en la nube según la aplicación proporcionada por el usuario. Los atacantes la han utilizado de forma abusiva para la minería de criptoactivos con mineros escritos en Go, pero en este caso, los piratas informáticos la utilizaron para implementar un script bash que escanea otros dominios en busca de archivos .env expuestos, extrae credenciales y las carga en un depósito público de S3 que habían comprometido previamente.

Este script en particular busca credenciales para la plataforma de envío de correo electrónico Mailgun, pero al acceder al almacenamiento S3 expuesto públicamente de los atacantes, los investigadores pudieron comprender el alcance completo de la campaña. “Identificamos más de 230 millones de objetivos únicos que el actor de la amenaza estaba escaneando en busca de archivos de entorno mal configurados y expuestos. En el momento de acceder a este depósito S3 público, creemos que varias cuentas de AWS comprometidas fueron el objetivo de este escaneo malicioso como parte de una operación de compromiso automatizada”.

Exfiltración de datos, extorsión y asesoramiento

Cada vez que conseguían obtener las credenciales de acceso a los buckets S3, los atacantes utilizaban una herramienta de Windows llamada S3 Browser para interactuar con la API de S3 y exfiltrar todos los datos que contenían. Una vez descargados todos los archivos, los borraban y dejaban una nota de rescate informando al propietario de que ahora tenían acceso a su información sensible y que planeaban venderla si no les pagaban. Los cibercriminales accedían a las cuentas de AWS y a los buckets S3 desde la red Tor, VPN públicas o desde dentro de la propia infraestructura de AWS utilizando otras cuentas comprometidas. Sin embargo, los investigadores detectaron dos casos en los que los atacantes se conectaron directamente desde direcciones IP asignadas a ISP de Ucrania y Marruecos.

Aconsejan a las organizaciones que habiliten el registro de S3 o CloudTrail para los eventos de bucket de S3, de modo que puedan realizar investigaciones de incidentes. Estas configuraciones no están habilitadas de manera predeterminada y pueden aumentar el costo del entorno de la nube al atar recursos, pero valen la pena para poder evaluar con precisión lo que sucedió en caso de una vulneración. “Dependiendo de los servicios de AWS que se utilicen, las organizaciones deberán asegurarse de habilitar el registro específico para ese servicio”, dijeron los investigadores. “Una vez que tengan el registro y la retención adecuados para estos datos (se recomienda una retención mínima de 90 días), el enfoque debe cambiar a la supervisión”. El servicio GuardDuty de AWS, por ejemplo, ofrece capacidades de alerta para el abuso de las credenciales y los recursos de EC2. Las organizaciones pueden crear sus propias alertas para la actividad anormal en los datos de registro.

Por último, los expertos recomiendan encarecidamente no utilizar claves de acceso IAM a largo plazo en las aplicaciones y, en su lugar, confiar en roles IAM que solo brindan acceso temporal. Se debe seguir el principio del mínimo privilegio al configurar el acceso a los recursos IAM. También se debe deshabilitar el acceso a las regiones de AWS no utilizadas para que los atacantes no puedan implementar recursos en regiones adicionales.