ForceMemo la campaña que reescribe la historia de GitHub roba tokens y difunde malware a traves de paquetes Python

Hace unos meses la comunidad de desarrolladores comenzó a notar algo inquietante: paquetes y proyectos en GitHub que, sin aparentes cambios visibles, estaban incorporando fragmentos de código dañino. La investigación ha puesto en evidencia una campaña sofisticada que toma prestadas técnicas ya conocidas del grupo GlassWorm, pero que ahora opera con una variante centrada en forzar el historial de repositorios para insertar cargas útiles maliciosas en proyectos Python. Los informes técnicos publicados por equipos de investigación como StepSecurity y análisis complementarios de grupos como Socket dibujan un panorama preocupante para la integridad del código abierto.

El vector inicial de esta operación no es un ataque directo a GitHub, sino la infiltración de los entornos de desarrollo. Mediante extensiones maliciosas para editores como VS Code y herramientas de autocompletado se instala un componente que busca y exfiltra credenciales: tokens de GitHub que permiten actuar como si fuesen los propios desarrolladores. Con esas credenciales en mano, el actor remueve las barreras normales del flujo de trabajo. En lugar de crear una pull request o añadir un commit visible, la intrusión reescribe la historia del repositorio mediante un rebase y un force-push, de modo que los metadatos —el autor, la fecha y el mensaje del commit— parecen genuinos y no queda rastro evidente en la interfaz pública.

Una vez conseguida la puerta abierta, los atacantes buscan ficheros concretos que suelen ejecutarse o empaquetarse en proyectos Python —nombres habituales como setup.py, main.py o app.py— y añaden al final del archivo una carga inyectada codificada en Base64. Ese código ofuscado no es un simple script: contiene comprobaciones para detectar entornos que usen la localización rusa y, si se detecta esa configuración, evita ejecutarse, una técnica habitual para evadir análisis en determinadas jurisdicciones. En cualquier otro caso, el fragmento descodifica instrucciones que apuntan a una dirección en la red de Solana; el campo memo de una transacción actúa como canal para que el atacante actualice dinámicamente la URL desde la que el malware descargará componentes adicionales, incluida JavaScript cifrada diseñada para sustraer criptomonedas y datos del sistema infectado.

La cronología que reportan los investigadores muestra que la infraestructura de control llevaba operando meses antes de que se detectasen las primeras inserciones en repositorios. Los registros en la cadena de bloques indican transacciones en esa dirección de Solana que datan de finales de noviembre de 2025, mientras que las primeras inyecciones en GitHub se identificaron a partir del 8 de marzo de 2026. Además, el patrón de operación revela que el actor va cambiando con frecuencia la URL de la carga útil, lo que complica la defensa si solo se bloquea una dirección concreta.

Lo que hace singular a esta variante —apodada por algunos investigadores como ForceMemo— es la combinación de varias técnicas: uso de extensiones maliciosas para robar secretos, explotación de tokens válidos para reescribir la historia git preservando metadatos legítimos, y el empleo de la cadena de bloques como canal de mando y control. Socket ha señalado además que la campaña mejoró su capacidad de supervivencia al distribuir el malware de forma transitiva mediante metadatos de paquetes de extensiones, es decir, apoyándose en mecanismos de empaquetado y dependencias para propagar la carga maliciosa a través del ecosistema de extensiones.

Para quienes mantienen software abierto o dependen de librerías de terceros, las implicaciones son claras: un desarrollador infectado puede, sin dejar trazas obvias, propagar código malicioso a proyectos consumidos por miles de usuarios. Cualquier operación que haga un pip install desde un repositorio comprometido o que clone y ejecute código sin las debidas comprobaciones puede desencadenar la ejecución del malware. Ante este riesgo, las buenas prácticas de seguridad de GitHub —como la rotación de tokens, la revisión de permisos concedidos a aplicaciones y la activación de autenticación multifactor— recuperan todo su valor; GitHub mantiene documentación útil sobre cómo gestionar y proteger tokens personales en su plataforma en sus guías oficiales.

Además, la prevención en el plano del repositorio debe incluir políticas que dificulten un force-push no autorizado. La protección de ramas, revisiones obligatorias de código y flujos de integración continua que validen la integridad del historial y las firmas de commit son barreras eficaces para detectar alteraciones indeseadas; GitHub ofrece orientaciones para configurar ramas protegidas en su documentación. En el ámbito del empaquetado Python, resulta prudente asumir que ejecutar directamente scripts descargados de repositorios no verificados implica riesgo; la comunidad y PyPI han venido reforzando prácticas de seguridad que se pueden consultar en las pautas de PyPI.

Si tu organización desarrolla o consume paquetes Python, conviene revisar tokens y sesiones activas ligados a cuentas de mantenimiento, auditar commits recientes buscando inserciones sospechosas y establecer reglas que impidan reescribir la historia de la rama principal sin revisiones adicionales. Las medidas reactivas incluyen revocar credenciales comprometidas, forzar rotación de tokens y realizar análisis forense de los entornos de desarrollo para detectar extensiones o procesos atípicos. Aun con controles técnicos en marcha, la concienciación del equipo —no abrir extensiones de procedencia dudosa, verificar la reputación de paquetes y evitar ejecutar código a ciegas— sigue siendo una defensa esencial.

En un plano más amplio, ForceMemo pone de manifiesto algo que la seguridad del software ha venido advirtiendo desde hace años: la cadena de suministro del software es tan débil como su eslabón más vulnerable. Un único desarrollador con el entorno comprometido puede convertir un proyecto confiable en un vector de ataque distribuido. La comunidad necesita combinar controles técnicos —protección de ramas, auditoría de permisos, escaneos automáticos de repositorios— con procesos organizativos que reduzcan la exposición de secretos y mejoren la detección temprana.

Para los curiosos que quieran profundizar en los hallazgos técnicos, los análisis publicados por los equipos de respuesta y detección son recursos recomendables: el informe de StepSecurity sobre esta campaña está disponible en su blog, y el trabajo de Socket que describe la distribución transitiva a través de extensiones puede consultarse en su artículo técnico. Mantenerse informado y aplicar controles preventivos es, hoy más que nunca, la mejor herramienta para proteger proyectos y usuarios frente a campañas que combinan ingeniería social, abuso de plataformas y técnicas de ofuscación cada vez más maduras.