En la campaña activa Elektra-Leak, los atacantes buscan credenciales de Amazon IAM dentro de los repositorios públicos de GitHub antes de usarlas para la criptominería. Obtenga consejos para mitigar esta amenaza a la ciberseguridad. Imagen: WhataWin Una nueva investigación de la Unidad 42 de Palo Alto Networks expone una campaña de ataque activo en la que un actor de amenazas busca credenciales de Amazon IAM en tiempo real en repositorios de GitHub y comienza a usarlas menos de cinco minutos después. La carga útil final ejecuta software de criptominería Monero personalizado en máquinas virtuales implementadas en las instancias de Amazon. Saltar a: Credenciales de IAM expuestas en GitHub GitHub ofrece a sus usuarios muchas funciones para manejar su código dentro de la plataforma. Una de estas características consiste en proporcionar una lista de todos los repositorios públicos a cualquier usuario que la solicite, lo que ayuda a los desarrolladores a rastrear fácilmente varios desarrollos que les interesan. El seguimiento se realiza en tiempo real y permite que cualquiera, incluidos los actores de amenazas, vea nuevos repositorios. tan pronto como sean enviados a GitHub. VER: Las 8 mejores soluciones de gestión de identidad y acceso (IAM) para 2023 (TechRepublic) Los investigadores de la Unidad 42 de Palo Alto Networks informan que es posible encontrar credenciales de gestión de identidad y acceso de Amazon Web Services dentro de los repositorios públicos de GitHub y que estas credenciales se buscan activamente por los ciberdelincuentes. Para analizar el riesgo en mayor profundidad, los investigadores decidieron almacenar las credenciales de IAM en GitHub y verificar toda la actividad a su alrededor. Esa prueba de honeypot reveló que las claves de AWS filtradas que estaban codificadas en base64 y almacenadas en GitHub no fueron encontradas ni utilizadas por los actores de amenazas, que solo obtuvieron claves de AWS de texto sin cifrar ocultas detrás de una confirmación anterior en un archivo aleatorio. El honeypot permitió a los investigadores William Gamazo y Nathaniel Quist detectar una campaña de ataque particular que comenzó cinco minutos después de que se colocaron las credenciales en GitHub. Detalles técnicos sobre esta campaña de ataque La campaña, denominada EleKtra-Leak por los investigadores en referencia a la ninfa de la nube griega Electra y el uso de Lek como los primeros 3 caracteres en las contraseñas utilizadas por el actor de amenazas, ha estado activa desde al menos diciembre. 2020, según la Unidad 42. Una vez que se encuentran las credenciales de IAM, el atacante realiza una serie de acciones de reconocimiento para saber más sobre la cuenta de AWS a la que se accede (Figura A). Figura A Acciones de reconocimiento ejecutadas por el actor de amenazas en la cuenta de AWS. Imagen: Palo Alto Networks Una vez realizadas esas acciones, el actor de amenazas crea nuevos grupos de seguridad de AWS antes de lanzar varias instancias de Amazon Elastic Compute Cloud por región en cualquier región de AWS accesible. Gamazo y Quist pudieron observar más de 400 llamadas API en siete minutos, todas realizadas a través de una conexión VPN, lo que demuestra que el actor ha automatizado el ataque contra esos entornos de cuentas de AWS. Cobertura de seguridad de lectura obligada El actor de amenazas apuntó a máquinas virtuales en la nube de gran formato para realizar sus operaciones, ya que tienen mayor poder de procesamiento, que es lo que buscan los atacantes cuando ejecutan operaciones de criptominería. El actor de amenazas también eligió imágenes privadas para Amazon Machine Images; algunas de esas imágenes eran distribuciones antiguas de Linux Ubuntu, lo que llevó a los investigadores a creer que la operación se remonta al menos a 2020. El actor de amenazas también pareció bloquear cuentas de AWS que habitualmente exponen credenciales de IAM, ya que este tipo de comportamiento podría originarse en investigadores de amenazas o sistemas de honeypot. El objetivo de esta campaña de ataque: Criptominería. Una vez que se realiza todo el reconocimiento y se inician las máquinas virtuales, se entrega una carga útil, que se descarga desde Google Drive. La carga útil, cifrada en el almacenamiento de Google, se descifra al descargarla. La Unidad 42 afirma que la carga útil es una conocida herramienta de criptominería aparentemente utilizada en 2021 y reportada por Intezer, una empresa especializada en plataformas autónomas de sistemas operativos de seguridad. En la campaña de ataque reportada, Intezer indicó que un actor de amenazas había accedido a instancias de Docker expuestas en Internet para instalar software de criptominería para extraer la criptomoneda Monero. Ese software de criptominería personalizado es el mismo que se utiliza en la nueva campaña expuesta por Palo Alto Networks. El software está configurado para utilizar el grupo de minería SupportXMR. Los grupos de minería permiten que varias personas agreguen su tiempo de computación al mismo espacio de trabajo, lo que aumenta sus posibilidades de ganar más criptomonedas. Como afirmó Palo Alto Networks, el servicio SupportXMR solo proporciona estadísticas por tiempo limitado, por lo que los investigadores obtuvieron las estadísticas de minería durante varias semanas, ya que se usó la misma billetera para las operaciones de minería de AWS (Figura B). Figura B Estadísticas de SupportXMR asociadas con la billetera del actor de la amenaza. Imagen: Palo Alto Networks Entre el 30 de agosto de 2023 y el 6 de octubre de 2023, aparecieron un total de 474 mineros únicos, siendo cada uno de ellos una instancia única de Amazon EC2. Aún no es posible obtener una estimación de la ganancia financiera generada por el actor de la amenaza, ya que Monero incluye controles de privacidad que limitan el seguimiento de este tipo de datos. Medidas automatizadas de GitHub para detectar secretos GitHub escanea automáticamente en busca de secretos en los archivos almacenados en la plataforma y notifica a los proveedores de servicios sobre secretos filtrados en GitHub. Durante su investigación, Gamazo y Quist notaron los secretos que estaban almacenando intencionalmente en GitHub, ya que GitHub detectó con éxito los datos del honeypot para su investigación y los informó a Amazon, quien a su vez aplicó automáticamente en cuestión de minutos una política de cuarentena que evita que los atacantes realicen operaciones como como acceder a AWS IAM, EC2, S3, Lambda y Lightsail. Durante el proceso de investigación, la Unidad 42 dejó la política de cuarentena vigente y estudió pasivamente las pruebas de las cuentas realizadas por los atacantes; luego, se abandonó la política para estudiar toda la cadena de ataque. Los investigadores escriben que «creen que el actor de la amenaza podría encontrar claves de AWS expuestas que no se detectan automáticamente» y que, según su evidencia, los atacantes probablemente lo hicieron, ya que podían ejecutar el ataque sin ninguna política que interfiriera. También afirman que “incluso cuando GitHub y AWS están coordinados para implementar un cierto nivel de protección cuando se filtran claves de AWS, no todos los casos están cubiertos” y que otras víctimas potenciales de este actor de amenazas podrían haber sido atacadas de una manera diferente. Cómo mitigar este riesgo de ciberseguridad Las credenciales de IAM nunca deben almacenarse en GitHub ni en ningún otro servicio o almacenamiento en línea. Las credenciales de IAM expuestas deben eliminarse de los repositorios y se deben generar nuevas credenciales de IAM para reemplazar las filtradas. Las empresas deben utilizar credenciales de corta duración para realizar cualquier funcionalidad dinámica dentro de un entorno de producción. Los equipos de seguridad deben monitorear los repositorios de GitHub utilizados por sus organizaciones. Se debe auditar los eventos de clonación que ocurren en esos repositorios porque es necesario que los actores de amenazas clonen primero los repositorios para ver su contenido. Esa característica está disponible para todas las cuentas de GitHub Enterprise. También se debe realizar constantemente un escaneo personalizado y dedicado en busca de secretos en los repositorios. Herramientas como Trufflehog podrían ayudar en esa tarea. Si no es necesario compartir los repositorios de la organización públicamente, los repositorios privados de GitHub deben ser utilizados y solo el personal de la organización debe acceder a ellos. El acceso a los repositorios privados de GitHub debe protegerse mediante autenticación multifactor para evitar que un atacante acceda a ellos con credenciales de inicio de sesión filtradas. Divulgación: trabajo para Trend Micro, pero las opiniones expresadas en este artículo son mías.

Source link