Alrededor de 10.000 repositorios falsos en GitHub propagan troyanos

GitHub resultó inundado de repositorios falsos, que se hacen pasar por proyectos legítimos de desarrolladores y distribuyen troyanos mediante enlaces a archivos ZIP.
Una importante campaña maliciosa fue detectada por un desarrollador bajo el seudónimo Orchid. Encontró alrededor de 10 000 repositorios en GitHub que parecían proyectos independientes de distintos autores, pero funcionaban según el mismo esquema. Los atacantes copiaban repositorios nuevos de otros, conservaban el historial de cambios y la lista de colaboradores, y luego modificaban el archivo README añadiendo un enlace al archivo con contenido malicioso.
Orchid advirtió el problema después de que su propio proyecto fue copiado. En Google el repositorio original aparecía correctamente, pero en Bing, con la misma consulta, apareció un repositorio ajeno con el mismo nombre y la misma descripción. En su interior había una copia del proyecto, incluido el historial de cambios, pero en el README se había añadido un enlace a un archivo ZIP.
Según el desarrollador, los repositorios falsos no eran forks habituales de proyectos. Tenían distintos nombres, distintos propietarios y distintos colaboradores. El rasgo común era que volvían a modificar el README. En algunos casos los atacantes eliminaban un commit antiguo y, pasadas unas horas, añadían uno nuevo con el mismo título «Update README.md». Ya habían aparecido en la red mensajes sobre este esquema, y los desarrolladores se quejaban de la suplantación de sus proyectos. Orchid identificó alrededor de 40 000 repositorios sospechosos, de los cuales aproximadamente 10 000 coincidían completamente con el patrón observado.
El esquema malicioso giraba en torno a un archivo ZIP. Normalmente en su interior había un archivo por lotes de Windows, un ejecutable como loader.exe o luajit.exe, un archivo cualquiera con la extensión .txt o .cso y la biblioteca lua51.dll. Al comprobarse solo en VirusTotal el código malicioso podía no detectarse, pero el propio archivo descargado ya se clasificaba como troyano.
Anteriormente una campaña similar fue descrita por la empresa HexaStrike. Sus especialistas encontraron 109 repositorios falsos y vincularon la actividad con la cadena maliciosa SmartLoader y StealC. Tras ejecutar el archivo por lotes en el equipo de la víctima se iniciaba el intérprete LuaJIT con un script ofuscado. A continuación el programa malicioso obtenía la dirección de la infraestructura de control a través de un contrato inteligente en la red Polygon y descargaba la siguiente fase del ataque.
Como resultado, en el dispositivo infectado podía llegar StealC, que roba datos. Ese troyano es capaz de sustraer carteras de criptomonedas, contraseñas, datos bancarios, archivos de navegadores, cuentas de correo electrónico, así como datos de Steam, Discord, Telegram y otros servicios.
Los repositorios falsos parecían convincentes porque conservaban el código fuente, el historial de cambios y los colaboradores de los proyectos originales. Según Orchid, los atacantes copiaban precisamente los repositorios nuevos para aparecer más rápido en los resultados de búsqueda por consultas poco frecuentes. Además, esos proyectos podían ser encontrados no solo por personas, sino también por agentes basados en inteligencia artificial que buscan dependencias o ejemplos de código y pueden acceder automáticamente al enlace malicioso.
El desarrollador notificó a GitHub sobre dos copias falsas de sus proyectos, pero, según él, hubo que esperar casi dos meses para que los repositorios se eliminaran. Tras publicar el script y la lista de repositorios maliciosos, GitHub empezó a borrar los proyectos detectados; sin embargo, Orchid afirma que la plataforma eliminó solo los repositorios que estaban directamente enumerados en la lista. Después de ejecutar el script de nuevo aparecieron nuevos hallazgos que, según el autor, no fueron eliminados con rapidez.
Parte de los repositorios falsos existieron durante meses, y algunos pudieron permanecer accesibles más de un año. Orchid considera que los 10 000 proyectos encontrados pueden ser solo una parte de la campaña, ya que su búsqueda estuvo limitada por el límite de la API de GitHub de 5 000 solicitudes por hora. La propia plataforma no tiene tales restricciones, por lo que GitHub puede comprobar todos los repositorios, encontrar archivos y ejecutables y luego escanearlos en busca de código malicioso.
Por el momento se desconoce quién está detrás del ataque. HexaStrike sugirió que la campaña la lleva a cabo un ciberdelincuente o un pequeño grupo con gestión centralizada. Esto lo indican la estructura idéntica de los README, las actualizaciones sincronizadas de los repositorios, las técnicas repetidas con las que cargaban el malware y la infraestructura común.