Repositorios de Python en GitHub usados para distribuir el nuevo RAT PyStoreRAT basado en JavaScript
Introducción
En las últimas semanas, se ha detectado una campaña de distribución de malware particularmente sofisticada que utiliza repositorios públicos de Python alojados en GitHub para propagar un troyano de acceso remoto (RAT) hasta ahora desconocido, denominado PyStoreRAT. Esta amenaza destaca por su enfoque en el aprovechamiento de populares plataformas de desarrollo y por la utilización de un payload JavaScript ejecutado a través de archivos HTA, lo que incrementa el grado de evasión frente a controles tradicionales. El modus operandi apunta tanto a profesionales técnicos como a usuarios avanzados que buscan utilidades de desarrollo u OSINT, evidenciando la necesidad de reforzar la vigilancia sobre los repositorios de código abierto.
Contexto del Incidente
El incidente fue reportado por investigadores de ciberseguridad tras identificar varios repositorios de Python en GitHub que aparentaban ser herramientas legítimas para tareas de desarrollo o inteligencia de fuentes abiertas (OSINT). Sin embargo, el código fuente de estas supuestas utilidades contenía apenas unas líneas cuya finalidad era descargar y ejecutar un archivo HTA remoto, el cual desplegaba el RAT PyStoreRAT. La campaña, activa desde principios de junio de 2024, se ha expandido rápidamente gracias a la confianza que muchos profesionales depositan en el código abierto y la dificultad de auditar manualmente cada aportación en grandes plataformas colaborativas.
Detalles Técnicos
PyStoreRAT es un troyano de acceso remoto escrito íntegramente en JavaScript, lo que supone una rareza en el panorama actual dominado por payloads en C/C++ o Python. El vector inicial de ataque consiste en un script de Python muy simple alojado en GitHub, que descarga y ejecuta un archivo HTA (HTML Application) desde un dominio controlado por el atacante. Una vez ejecutado el HTA, se descarga y ejecuta el RAT JavaScript en la máquina de la víctima.
– CVE asociado: Hasta la fecha no se ha asignado un CVE específico, dado que la amenaza explota la confianza en repositorios públicos y no una vulnerabilidad concreta del software.
– TTPs (MITRE ATT&CK):
– Técnica T1192 (Spearphishing vía servicios): Uso de plataformas legítimas para distribuir malware.
– Técnica T1218.005 (Mshta): Abuso de mshta.exe para ejecutar código malicioso.
– Técnica T1059 (Command and Scripting Interpreter): Uso de intérpretes de scripting para ejecución de payloads.
– Indicadores de Compromiso (IoC):
– Repositorios de GitHub con scripts de Python de unas pocas líneas que invocan mshta.exe.
– Descarga de archivos HTA desde dominios recientemente registrados.
– Conexiones salientes a C2s alojados en infraestructuras cloud públicas.
No se ha reportado la integración de exploits conocidos ni el uso de frameworks como Metasploit o Cobalt Strike; el RAT parece ser una herramienta personalizada y aún no catalogada en bases de datos públicas de malware.
Impacto y Riesgos
El impacto potencial de PyStoreRAT es significativo, especialmente en entornos donde se fomenta el uso de código abierto para acelerar proyectos de desarrollo o automatización de tareas administrativas. Entre los riesgos identificados destacan:
– Exfiltración de credenciales y datos sensibles, dado que el RAT otorga control remoto total sobre el sistema comprometido.
– Persistencia difícil de detectar, ya que la ejecución mediante HTA y JavaScript puede evadir soluciones EDR tradicionales.
– Vectores de escalada lateral si el malware se instala en sistemas con privilegios elevados o acceso a redes internas.
– Riesgo elevado de incumplimiento normativo (GDPR, NIS2) si se produce una fuga de datos personales o información crítica de clientes.
El alcance de la campaña es aún incipiente, pero varios análisis estiman que decenas de organizaciones, principalmente en Europa y América del Norte, han descargado ya alguno de estos repositorios contaminados.
Medidas de Mitigación y Recomendaciones
Para mitigar el riesgo asociado a esta amenaza, se recomienda:
– Auditar exhaustivamente cualquier repositorio de código abierto, especialmente scripts cortos y utilidades desconocidas.
– Monitorizar el uso de mshta.exe y HTA en endpoints, bloqueando su ejecución si no es estrictamente necesaria.
– Implementar reglas YARA y detecciones específicas en SIEM/SOC para patrones de PowerShell/HTA descargados desde fuentes externas.
– Restringir la ejecución de scripts de Python descargados de fuentes no verificadas.
– Mantener inventario actualizado de activos y segmentar redes para limitar la propagación en caso de compromiso.
– Sensibilizar a los equipos de desarrollo y operaciones sobre las tácticas empleadas en la campaña.
Opinión de Expertos
Expertos en ciberseguridad coinciden en que la explotación de confianza en ecosistemas como GitHub va en aumento. “El uso de payloads JavaScript ejecutados mediante HTA demuestra la creatividad de los atacantes para sortear controles tradicionales y aprovechar la superficie de ataque menos vigilada,” señala Marta Jiménez, analista de amenazas en un SOC europeo. Añade que “los controles de seguridad en la cadena de suministro de software son hoy más esenciales que nunca”, citando incidentes recientes como el de SolarWinds y las nuevas exigencias regulatorias europeas (NIS2).
Implicaciones para Empresas y Usuarios
Las organizaciones deben revisar sus políticas de incorporación de repositorios públicos en entornos productivos y de desarrollo, aplicando controles adicionales y soluciones de análisis de código automatizados. Para los usuarios finales y los equipos de DevOps, el incidente subraya la importancia de la formación continua en higiene digital y la limitación de privilegios para procesos automatizados.
Conclusiones
La campaña de PyStoreRAT pone de manifiesto la sofisticación y rapidez con la que los actores de amenazas pueden adaptar y desplegar nuevas técnicas, especialmente en plataformas de confianza como GitHub. La vigilancia proactiva, la segmentación de redes y la restricción de ejecución de archivos HTA son medidas clave para contener este tipo de ataques. Las organizaciones deben reforzar su cadena de suministro de software y adoptar una postura de seguridad “zero trust” también en el ámbito del código abierto.
(Fuente: feeds.feedburner.com)