FakeGit vuelve con 17.610 repositorios maliciosos en GitHub
La operación de malware FakeGit vuelve a estar activa en GitHub, y ahora es más grande que antes. Los investigadores contabilizan 17.610 repositorios falsos que distribuyen el malware SmartLoader, después de que la campaña reapareciera a principios de este mes para propagar el infostealer StealC.
Los hallazgos proceden de Apiiro, una empresa especializada en la seguridad de la cadena de suministro de software. Según sus investigadores, FakeGit reanudó su actividad el 4 de octubre.
La mayoría de las cuentas que están detrás de los repositorios parecen perfiles de usar y tirar creados para la campaña. Sin embargo, los investigadores también encontraron al menos 700 cuentas que parecen pertenecer a desarrolladores reales.
Un cargador disfrazado de descarga
El montaje es sencillo. Cada repositorio malicioso tiene un archivo README con unas instrucciones muy cuidadas y un botón de descarga. Ese botón lleva a un archivo ZIP que contiene SmartLoader, la carga útil de primera fase. La función de SmartLoader es descargar e instalar otro malware en el equipo de la víctima.
Se ha observado actividad de este tipo, con distintas cargas útiles, al menos desde enero. El nombre FakeGit se le asignó a la operación en julio, cuando Island, una empresa que desarrolla una plataforma de navegador corporativo, informó de 7.600 repositorios falsos en GitHub que distribuían SmartLoader.
En aquel informe, Island señalaba que 800 de los repositorios se hacían pasar por habilidades de IA o servidores MCP. Los servidores MCP son componentes que permiten a los asistentes de IA conectarse a herramientas y datos externos. Estas entradas falsas aparecían en registros y catálogos públicos de IA, donde los desarrolladores buscan complementos.
13.000 repositorios redirigidos en 34 horas
Apiiro afirma que la última oleada avanzó muy deprisa. En 34 horas, FakeGit introdujo cambios en más de 13.000 repositorios. En el momento de máxima actividad, el operador llegaba a 2.999 repositorios por hora.
Los cambios eran pequeños y muy concretos. "En los commits que analizamos, el 97% solo modificaba el README, y el 88% hacía que su botón 'Download' apuntara a un ZIP que instala SmartLoader", explica Apiiro.
Ese detalle es importante. El atacante no necesitó montar una infraestructura nueva para esta ronda.
"Nadie tuvo que crear ni un solo repositorio nuevo. La flota ya estaba ahí. Simplemente se redirigió", explicaron los investigadores.
Por qué no han funcionado las retiradas
Apiiro relaciona la persistencia de FakeGit con la forma en que se gestionan las retiradas. Los repositorios se eliminan a partir de listas, y esas listas solo cubren una parte de la flota maliciosa.
Bloquear las cargas útiles tampoco basta. Los archivos incluidos en listas de bloqueo y sus copias de respaldo suelen seguir accesibles, así que el operador puede actualizar el enlace de descarga y mantener el mismo repositorio en línea.
Las fuentes de inteligencia de amenazas también iban por detrás. "El 71% de la flota no figuraba en URLhaus antes de nuestro informe, y una lista de bloqueo DNS a nivel de dominio no puede bloquear un archivo en GitHub sin bloquear GitHub", señala Apiiro. URLhaus es una base de datos pública que rastrea las URL utilizadas para propagar malware.
Los archivos maliciosos estaban alojados en muchos rincones de GitHub. Los investigadores los encontraron en forks, archivos antiguos, recursos de versiones publicadas, adjuntos de incidencias y repositorios dedicados exclusivamente a alojar descargas. Eliminar los enlaces de uno en uno sirve de poco frente a una dispersión así.
"Borras un archivo y el operador puede hacer que el señuelo apunte a una copia de reserva: un fork, un ZIP antiguo, un recurso de una versión o un adjunto de una incidencia", dijeron los investigadores.
Qué recomienda Apiiro
Los investigadores aconsejan a los usuarios comprobar quién es el propietario de un repositorio antes de descargar nada de él. Las habilidades de IA y los servidores MCP solo deberían obtenerse de registros oficiales o de los repositorios del propio proveedor.
Quien sospeche que SmartLoader se ha ejecutado en su sistema debería tratarlo como un posible compromiso de su cuenta de GitHub. Eso implica revocar las sesiones activas y los tokens de acceso, y pasar a usar llaves de acceso para iniciar sesión.
Nuestro análisis
FakeGit demuestra que el punto débil ya no es solo el propio malware, sino la confianza que los desarrolladores depositan en una plataforma que conocen. Una página de GitHub con un README bien presentado y un botón de descarga parece algo rutinario, y precisamente en eso confía el operador. El trabajo en curso sobre defensas en la propia plataforma, como las funciones de protección de push de GitHub, se centra en otros riesgos y no parece abordar los señuelos que se esconden dentro de los archivos README.
La campaña encaja además en una tendencia más amplia de atacantes que utilizan los ecosistemas de desarrollo como canales de distribución, de forma similar a los paquetes maliciosos de npm diseñados para llegar directamente a los programadores. El uso de habilidades de IA y servidores MCP falsos sugiere que los atacantes están siguiendo a los desarrolladores hacia catálogos más nuevos y menos maduros, donde los controles pueden ser más laxos.
Llaman la atención las 700 cuentas que parecen pertenecer a desarrolladores reales. Si esas cuentas fueron secuestradas, es posible que las credenciales robadas estén alimentando el crecimiento de la operación. Esto hace aún más urgente el consejo de revocar tokens y adoptar llaves de acceso, aunque la adopción de las llaves de acceso sigue rezagada entre los profesionales de la seguridad.
Habrá que ver si GitHub cambia su forma de retirar este tipo de contenido y pasa de las retiradas basadas en listas a limpiar a la vez forks, recursos de versiones y adjuntos. Hasta entonces, la flota podría volver a redirigirse sin más.