La campaña GitVenom: Robo de criptomonedas mediante GitHub

En el mundo actual, el código abierto tiene un notable impacto en el desarrollo de software. A lo largo de los años, la comunidad global ha ido publicando una gran cantidad de proyectos de acceso libre que cualquier persona puede consultar y mejorar. Es habitual que el código disponible en línea sirva de inspiración para los desarrolladores. Y cuando necesitan implementar una función en sus proyectos, suelen buscar si ya existe una solución publicada en Internet. De este modo, optimizan su tiempo en lugar de empezar desde cero.

A medida que crecen los proyectos de código abierto, tanto actores patrocinados por gobiernos como ciberdelincuentes han comenzado a utilizarlos como señuelo para infectar a sus víctimas. Esta tendencia sigue vigente, como lo demuestra la campaña GitVenom, dirigida a usuarios de GitHub.

Proyectos que parecen prometedores, pero son falsos

Durante la campaña GitVenom, los atacantes crearon cientos de repositorios en GitHub con proyectos falsos que contenían código malicioso. Algunos ejemplos incluyen una herramienta de automatización para gestionar cuentas de Instagram, un bot de Telegram para administrar billeteras de Bitcoin y un software de hacking para Valorant.

Para hacer que estos repositorios parecieran legítimos, los atacantes utilizaron diversas estrategias. Descubrimos que muchos de estos proyectos contenían archivos README.md bien estructurados, posiblemente generados con herramientas de IA. Estos archivos incluían descripciones de los proyectos y guías de compilación.

Fragmentos de páginas README.md con descripciones de proyectos falsos

Los atacantes también agregaron múltiples etiquetas a los repositorios e inflaron artificialmente el número de commits. Para ello, implementaron un archivo de marca de tiempo que se actualizaba cada pocos minutos:

Ejemplo de estructura de un repositorio malicioso creado por los atacantes

Múltiples tácticas para inyectar código malicioso

Al analizar los repositorios creados durante la campaña GitVenom, notamos que los proyectos falsos que encontramos estaban escritos en varios lenguajes de programación, como, Python, JavaScript, C, C++ y C#. Como era de esperarse, estos proyectos no implementaban las características discutidas en el archivo README.md, y la mayor parte del código realizaba acciones sin sentido. Al mismo tiempo, cada uno de los proyectos estaba infectado con código malicioso, cuya ubicación dependía del lenguaje de programación utilizado.

Por ejemplo, los atacantes colocaron código malicioso en proyectos basados en Python insertando una línea larga en uno de los archivos del proyecto. Esta línea consistía en unos 2000 caracteres de tabulación, seguidos del siguiente código, responsable de descifrar y ejecutar un script de Python:

En el caso de proyectos escritos en JavaScript, los atacantes crearon una función maliciosa dentro de ellos, que a su vez se invocaba desde el archivo principal del proyecto. Este es un ejemplo de dicha función:

Ejemplo de una función maliciosa colocada en proyectos escritos en JavaScript. Decodifica un script de Base64 y lo ejecuta.

En cuanto a los repositorios que contienen código en C, C++ y C#, los atacantes ocultaron un script por lotes malicioso dentro de los archivos de proyecto de Visual Studio, configurándolo para que se ejecutara al compilar el proyecto:

Snippet de un archivo de proyecto malicioso escrito en Visual Studio. Contiene un atributo PreBuildEvent, que instruye ejecutar la carga útil cuando se inicia la compilación del proyecto.

Más cargas útiles desplegadas por los atacantes

Aunque escritas en diferentes lenguajes de programación, las cargas maliciosas almacenadas dentro de los falsos proyectos tenían un objetivo común: descargar más componentes maliciosos desde un repositorio de GitHub controlado por el atacante (URL en el momento de la investigación: hxxps://github[.]com/Dipo17/battle) y ejecutarlos. Estos componentes eran los siguientes:

• Un stealer en Node.js que recopila información como credenciales, datos de billeteras de criptomonedas e historial de navegación almacenados, lo empaqueta en un archivo .7z y lo sube a los atacantes a través de Telegram.

Estructura del archivo que el stealer envía a los atacantes

• El implante de código abierto AsyncRAT (dirección del servidor C2: 138.68.81[.]155);
• El backdoor de código abierto Quasar (dirección del servidor C2: la misma que arriba)
• Un secuestrador del portapapeles, que busca en el contenido del portapapeles direcciones de billeteras de criptomonedas y las reemplaza por otras controladas por el atacante. Vale decir que la billetera de Bitcoin controlada por el atacante ( ID: bc1qtxlz2m6r[...]yspzt) recibió un total aproximado de 5 BTC, equivalentes a unos 485 000 USD en el momento de la investigación, durante noviembre de 2024.

Impacto de la campaña

Mientras investigábamos repositorios maliciosos relacionados con la campaña GitVenom, encontramos varios proyectos falsos publicados hace dos años. Dado que los atacantes han estado atrayendo víctimas con estos proyectos durante varios años, es probable que el vector de infección que utilizan sea bastante eficiente. Es más, según nuestra telemetría, se han observado intentos de infección relacionados con GitVenom en todo el mundo, la mayoría en Rusia, Brasil y Turquía. Es previsible que los ataques continúen, con pequeños cambios en las TTP del actor.

Ejecutar código de GitHub sin tomar precauciones puede ser perjudicial

Dada la popularidad de plataformas como GitHub entre millones de desarrolladores a nivel global, es muy probable que los actores maliciosos sigan utilizando software falsificado como señuelo para propagar infecciones. Por ello, es crucial manejar el procesamiento de código de terceros con mucho cuidado. Antes de intentar ejecutar dicho código o integrarlo en un proyecto existente, es fundamental revisar minuciosamente qué acciones realiza. De esta forma, se facilitará la detección de proyectos falsificados y se impedirá que el código malicioso contenido en ellos ponga en riesgo el entorno de desarrollo.