Malware PyStoreRAT: análisis completo de esta nueva amenaza RAT

El malware PyStoreRAT se ha convertido en una de las amenazas más curiosas y preocupantes de los últimos tiempos para investigadores, desarrolladores y aficionados a las criptomonedas. Esta familia de malware combina técnicas de ingeniería social, abuso de GitHub y módulos avanzados de acceso remoto que le permiten tomar el control del sistema, robar información y desplegar otros códigos maliciosos de forma silenciosa.

Lejos de ser “otro RAT más”, PyStoreRAT destaca por su enfoque modular, su cadena de infección en varias fases y su uso inteligente de repositorios falsos publicados en GitHub que simulan ser herramientas de OSINT, bots DeFi o utilidades relacionadas con GPT y ciberseguridad. Todo ello se acompaña de campañas en redes sociales y técnicas para inflar métricas de popularidad, de forma que las víctimas sientan que están descargando algo legítimo, útil y popular.

Qué es PyStoreRAT y por qué es tan peligroso

PyStoreRAT es un troyano de acceso remoto (RAT) basado principalmente en JavaScript que funciona como un implante modular y de múltiples etapas. Aunque el señuelo inicial suele estar escrito en Python o JavaScript, el núcleo del RAT se apoya en HTML Applications (HTA) y scripts que se ejecutan a través de mshta.exe, una utilidad legítima de Windows utilizada para procesar aplicaciones HTML.

Este implante ofrece a los atacantes un conjunto muy flexible de capacidades: puede ejecutar módulos en diferentes formatos (EXE, DLL, PowerShell, MSI, Python, JavaScript y HTA), lo que facilita adaptar la campaña a distintos entornos y saltarse controles de seguridad más básicos. Además, integra funciones de reconocimiento del sistema, robo de información y despliegue de malware adicional.

Un elemento clave es que PyStoreRAT suele ir acompañado del infostealer Rhadamanthys, un malware especializado en el robo de credenciales, datos de navegadores y, en particular, información relacionada con criptomonedas. De este modo, el RAT actúa como puerta de entrada polivalente, mientras que Rhadamanthys se encarga de la parte de exfiltración masiva de datos.

Otro aspecto que lo hace especialmente preocupante es su foco en perfiles de alto valor como analistas de seguridad, administradores de sistemas y usuarios avanzados. Estos usuarios, al descargar herramientas desde GitHub, suelen pensar que tienen todo bajo control y que “se lo revisan todo”, pero el diseño minimalista de los loaders y el uso de repositorios aparentemente confiables complica muchísimo la detección temprana.

En términos de evolución de amenazas, PyStoreRAT representa un paso más hacia implantes script-based muy discretos, diseñados para convivir con controles EDR modernos, retrasando al máximo su detección gracias a técnicas de evasión y ejecución en memoria.

Campaña en GitHub: repositorios falsos y abuso de la confianza

Los investigadores han documentado una campaña sostenida de distribución de PyStoreRAT a través de repositorios maliciosos alojados en GitHub. Estos repositorios se presentan como proyectos de utilidad para la comunidad técnica, lo que aumenta enormemente las probabilidades de descarga y ejecución.

Los temas habituales de estos repositorios incluyen herramientas OSINT para recolectar información pública, supuestos bots DeFi para automatizar estrategias de trading, wrappers o clientes no oficiales relacionados con GPT y utilidades de seguridad que prometen auditorías o mejoras de defensa. En muchos casos, la documentación y el README parecen perfectamente razonables, incluso profesionales.

Para maximizar su alcance, los atacantes promocionan estos proyectos en redes sociales como YouTube y X (antes Twitter), donde se publican vídeos, hilos y mensajes que enlazan directamente al repositorio. Además, manipulan métricas como las estrellas y los forks, recurriendo a cuentas falsas o automatizadas, al estilo de la Stargazers Ghost Network, de forma que el proyecto aparezca en listados de “repositorios en tendencia” de GitHub.

Un detalle especialmente traicionero es que los actores crean cuentas nuevas o reactivan cuentas antiguas que llevaban meses inactivas, para que parezca que el desarrollo “ha vuelto a la vida”. Una vez que la herramienta gana tracción y empieza a ser conocida, añaden el código malicioso en supuestos “commits de mantenimiento” publicados semanas o meses después, cuando ya se ha consolidado cierta confianza en el proyecto.

En bastantes casos, los proyectos ni siquiera funcionan como prometen: algunas herramientas solo muestran menús estáticos o interfaces sin funcionalidad real, mientras que otras ejecutan acciones mínimas de relleno. El objetivo no es ofrecer valor, sino aparentar legitimidad el tiempo suficiente para que el usuario ejecute el loader malicioso “como parte natural” del uso de la herramienta.

Cadena de infección: de loader mínimo a control total

El corazón de la campaña reside en una cadena de infección en varias etapas muy bien pensada, que comienza con un pequeño fragmento de código en Python o JavaScript dentro del repositorio de GitHub. Esa primera pieza es la que engancha todo lo demás.

Normalmente, el fichero que el usuario ejecuta contiene solo unas pocas líneas de código, en apariencia inofensivas o poco llamativas. Su función real es conectarse a un servidor remoto controlado por el atacante, descargar un archivo HTA y lanzarlo mediante mshta.exe. Esta técnica aprovecha una herramienta legítima de Windows, lo que reduce las sospechas de algunos sistemas de seguridad menos avanzados.

El loader incluye también una lógica de reconocimiento muy básica pero efectiva: recopila la lista de productos antivirus instalados en el sistema y busca cadenas relacionadas con “Falcon” (asociado a CrowdStrike Falcon) o “Reason” (vinculado a soluciones como Cybereason o ReasonLabs). Si detecta alguno de esos nombres, ajusta la forma de ejecutar mshta.exe para intentar disminuir la visibilidad.

Concretamente, cuando identifica esos productos, el malware lanza mshta.exe a través de cmd.exe, añadiendo una capa intermedia que puede modificar ciertos patrones de comportamiento que vigilan las soluciones de seguridad. Si no encuentra nada sospechoso, simplemente ejecuta mshta.exe de forma directa, reduciendo pasos y acelerando el proceso de infección.

Una vez cargado el HTA remoto, se inicia la siguiente fase: la entrega y despliegue de PyStoreRAT propiamente dicho. Aquí comienza el juego de módulos, persistencia y comunicación con el servidor de mando y control (C2), que es donde los atacantes toman las riendas del sistema infectado.

Capacidades internas de PyStoreRAT y módulos soportados

Desde el momento en que el HTA descarga y ejecuta el implante, PyStoreRAT actúa como una plataforma flexible de ejecución de payloads. Su arquitectura modular permite a los atacantes cargar distintos tipos de componentes según las necesidades de cada campaña o de cada víctima concreta.

Entre las capacidades más destacadas se encuentra la posibilidad de ejecutar binarios EXE, cargar DLLs, lanzar scripts de PowerShell, instalar paquetes MSI e incluso desplegar otros scripts en Python, JavaScript o nuevos HTA desde el propio RAT. Esta versatilidad hace que el malware pueda adaptarse con rapidez a distintos escenarios y escapar de defensas basadas en firmas estáticas.

Además, el RAT realiza una fase de reconocimiento del sistema (system profiling) para identificar información como el sistema operativo, permisos del usuario, configuración del entorno y otros datos que pueden ayudar a determinar qué tipo de payload es más útil en cada caso. También comprueba si dispone de privilegios de administrador, lo que abre la puerta a acciones más intrusivas.

Una función especialmente sensible es su capacidad para escudriñar el sistema en busca de archivos relacionados con monederos de criptomonedas. PyStoreRAT realiza búsquedas de rutas y ficheros asociados a aplicaciones como Ledger Live, Trezor, Exodus, Atomic Wallet, Guarda Wallet y BitBox02, sin explotar vulnerabilidades en esos programas, pero sí aprovechando la información almacenada localmente para preparar robos posteriores.

Paralelamente, el RAT facilita la ejecución del infostealer Rhadamanthys como carga secundaria. Una vez descargado, este se encarga de recopilar contraseñas, cookies, datos de navegadores y otra información de alto valor que puede enviarse al servidor C2 o revenderse en mercados clandestinos.

Persistencia, movimientos posteriores y comandos C2

Para asegurarse de que la infección no desaparece tras un simple reinicio, PyStoreRAT establece un mecanismo de persistencia basado en tareas programadas. Concretamente, crea una tarea en el Programador de Tareas de Windows con un nombre que imita un proceso legítimo de actualización de software.

En muchos casos, esa tarea aparece disfrazada como supuesto auto-actualizador de aplicaciones NVIDIA, aprovechando que muchos usuarios tienen drivers o herramientas gráficas instaladas y que este tipo de entradas pasan fácilmente desapercibidas en el sistema. De esta forma, el malware puede lanzarse de nuevo de manera periódica o tras reinicios del equipo.

Curiosamente, cuando el operador considera que ya ha extraído lo que necesitaba o desea reducir rastros, el propio malware puede eliminar la tarea programada para borrar huellas y complicar el análisis forense posterior. Este borrado también puede producirse como parte de comandos específicos enviados desde el servidor de mando y control.

En la fase de control remoto, PyStoreRAT se comunica con un servidor C2 externo desde el que recibe instrucciones. Aunque no se han hecho públicos todos los dominios e IPs utilizados, se sabe que el RAT soporta una lista variada de comandos, destinados tanto a la ejecución de nuevas cargas como a la propagación y limpieza de rastros.

Entre los comandos más importantes que puede ejecutar se encuentran funciones para descargar y ejecutar binarios EXE (incluido Rhadamanthys), descargar y descomprimir archivos ZIP, obtener DLL maliciosas y lanzarlas a través de rundll32.exe, y recibir código JavaScript en bruto que se ejecuta directamente en memoria usando eval(), técnica que dificulta la detección basada en archivos.

El RAT también puede instalar paquetes MSI, iniciar procesos mshta.exe secundarios para cargar más HTA remotos, y ejecutar directamente comandos de PowerShell en memoria, evitando dejar scripts visibles en disco. Además, integra funciones para extender la infección mediante un mecanismo de propagación por unidades extraíbles, sustituyendo documentos legítimos por accesos directos LNK maliciosos que apuntan al malware.

Productos afectados y foco en criptomonedas

Es importante dejar claro que PyStoreRAT no se aprovecha de una vulnerabilidad concreta en un software popular, sino que basa todo su éxito en el abuso de la confianza en proyectos de código abierto y en los malos hábitos de descargar y ejecutar código desde repositorios poco verificados.

Los objetivos principales son usuarios que descargan supuestas herramientas OSINT, bots de trading DeFi, utilidades para interactuar con GPT o scripts de seguridad alojados en GitHub y publicados o actualizados en un periodo que abarca aproximadamente desde junio hasta diciembre de 2025. Cualquier repositorio de este tipo, sin una autoría verificable, merece ser analizado con lupa.

En paralelo, el malware tiene un interés especial en monederos de criptomonedas instalados en el sistema. Aunque no explota fallos en esos programas, sí examina directorios, archivos de datos y configuraciones que puedan exponer información útil sobre saldos, direcciones o claves.

Entre las aplicaciones que suele buscar se encuentran Ledger Live, las carteras Trezor, Exodus, Atomic Wallet, Guarda Wallet y el dispositivo BitBox02. El mero hecho de que el malware rastree esos rastros ya indica un claro interés en la monetización a través del robo de criptoactivos o de la venta de datos de carteras.

Conviene subrayar que el vector de infección sigue siendo la ejecución de código descargado desde GitHub, no una brecha de seguridad inherente a los monederos. Aun así, los usuarios de criptomonedas que combinan estos wallets con herramientas descargadas alegremente de repositorios desconocidos se convierten, de facto, en un blanco muy interesante para los operadores de PyStoreRAT.

Indicadores de compromiso y comportamientos sospechosos

Para detectar posibles infecciones asociadas a esta familia, resulta útil fijarse en signos de comportamiento atípico tanto en el código descargado de GitHub como en el propio sistema Windows (síntomas de los distintos tipos de malware). Aunque no todo indicador garantiza que se trate de PyStoreRAT, un conjunto de ellos debe levantar sospechas.

En el plano del desarrollo, hay que desconfiar de scripts Python o JavaScript muy breves cuyo único propósito sea descargar y ejecutar archivos HTA vía mshta.exe. Este patrón ya es de por sí cuestionable y debe revisarse concienzudamente, sobre todo si procede de un repositorio recién creado o con historial sospechoso.

A nivel de sistema operativo, un indicador típico es la presencia de procesos mshta.exe lanzados por scripts o intérpretes fuera de los contextos habituales. Ver mshta.exe invocado por Python, Node.js, o mediante una consola de comandos asociada a una “herramienta OSINT” debería hacer saltar todas las alarmas en un entorno corporativo o incluso doméstico.

También conviene vigilar la existencia de tareas programadas con nombres que imitan a actualizadores de NVIDIA u otros fabricantes conocidos. Si dichas tareas se han creado en fechas cercanas a la instalación de una herramienta de GitHub poco conocida, el riesgo de que estén relacionadas con PyStoreRAT u otro malware similar es alto.

Finalmente, hay que prestar atención a accesos directos LNK inusuales en unidades USB o discos externos, especialmente cuando sustituyen a documentos de Office o PDFs que antes se abrían con normalidad. Este comportamiento encaja con la táctica de propagación por medios extraíbles implementada en este RAT.

Víctimas potenciales, tácticas observadas y atribución

La campaña detrás de PyStoreRAT parece puesta en marcha con un conocimiento bastante profundo de cómo se mueve la comunidad de ciberseguridad y desarrollo. No buscan solo a usuarios ingenuos, sino a perfiles que trabajan con herramientas de análisis, automatización y OSINT de manera habitual.

Entre las víctimas potenciales destacan investigadores de seguridad, administradores de TI, analistas de amenazas e incluso usuarios avanzados de criptomonedas que prueban a menudo nuevas utilidades de GitHub para optimizar sus flujos de trabajo. Precisamente por confiar en repositorios “de moda”, terminan exponiéndose a cargas maliciosas cuidadosamente camufladas.

Los atacantes se apoyan en varias tácticas de visibilidad, como el uso de listas de repositorios en tendencia y campañas en redes sociales para dirigir tráfico hacia los proyectos infectados. El empleo de cuentas de GitHub recién creadas o inactivas, combinado con commits posteriores que introducen el malware a modo de “actualización menor”, muestra un enfoque claro de ataque a la cadena de suministro de software.

En cuanto a la atribución, las investigaciones apuntan a la presencia de artefactos y patrones de codificación en idioma ruso, lo que sugiere que el grupo responsable tiene origen en Europa del Este. Sin embargo, por el momento no hay una vinculación directa con una APT o grupo criminal claramente catalogado en fuentes abiertas.

El carácter modular, el interés en el robo de criptomonedas y el uso de técnicas modernas de evasión apuntan a actores con experiencia y recursos, más allá de simples aficionados, aunque la campaña todavía se está analizando y pueden aparecer nuevas evidencias con el tiempo.

Relación con otras amenazas: el caso de SetcodeRat

Aunque la estrella de este análisis es PyStoreRAT, distintas investigaciones han señalado la aparición de otras familias de RAT con estrategias igual de refinadas, lo que confirma una tendencia preocupante hacia implantes remotos muy personalizados para ciertos entornos o regiones.

Un ejemplo paralelo es SetcodeRat, descubierto por un proveedor de seguridad chino, que se está propagando mediante campañas de malvertising dentro del país. En este caso, los atacantes se centran en usuarios de habla china y se apoyan en instaladores falsos de software muy conocido, como navegadores web, para llevar a cabo la infección.

El instalador malicioso de SetcodeRat realiza una verificación previa de la región y del idioma del sistema. Si el equipo no está configurado en chino simplificado o variantes locales como Zh-CN (China continental), Zh-HK (Hong Kong), Zh-MO (Macao) o Zh-TW (Taiwán), el programa simplemente se cierra, reduciendo la exposición innecesaria fuera del público objetivo.

Otro requisito curioso es que el malware comprueba la conectividad con una URL de Bilibili (un popular servicio de vídeo chino). Si no puede contactar con la ruta asociada a api.bilibilicom/x/report/click/now, se aborta la ejecución, probablemente como mecanismo adicional para limitar el análisis en entornos de laboratorio.

En la fase siguiente, el instalador ejecuta un binario llamado pnm2png.exe para realizar un side-loading de zlib1.dll. Esta DLL, manipulada por los atacantes, se encarga de descifrar el contenido de un archivo llamado qt.conf y, a partir de ahí, cargar una nueva DLL con el payload RAT integrado. De este modo, el malware se incrusta en la cadena de carga de librerías de una aplicación aparentemente legítima.

Una vez completamente operativo, SetcodeRat ofrece funciones habituales de un RAT moderno: captura de pantallas, keylogging, lectura y modificación de carpetas, ejecución de procesos, lanzamiento de cmd.exe, gestión de conexiones de red y auto-actualización. Para comunicarse con su infraestructura, puede utilizar tanto servidores C2 convencionales como canales a través de Telegram, lo que le da flexibilidad y resiliencia.

Estrategias de mitigación recomendadas

La mejor defensa frente a PyStoreRAT y amenazas similares pasa por cambiar hábitos a la hora de descargar y ejecutar código desde repositorios públicos. Esto es especialmente crítico en entornos corporativos, donde un solo descuido puede derivar en una brecha grave.

En primer lugar, se recomienda verificar la legitimidad de los repositorios de GitHub: comprobar si pertenecen a organizaciones conocidas, contrastar la URL con la web oficial del proyecto y revisar el historial de commits en busca de incorporaciones sospechosas de última hora. También ayuda mucho fijarse en la coherencia entre la popularidad del proyecto y la calidad real del código.

Antes de ejecutar cualquier herramienta descargada, conviene realizar una revisión manual del código, sobre todo de los scripts que actúan como “launchers”. Cualquier referencia a mshta.exe, descargas de HTA remotos o invocaciones extrañas de PowerShell debe analizarse con lupa, idealmente en un entorno aislado (sandbox) o mediante un análisis sin conexión de Microsoft Defender antes de llegar a un equipo de producción.

A nivel de red, resulta útil monitorizar conexiones salientes hacia dominios nuevos o IPs poco habituales, así como registrar y alertar sobre comportamientos de tipo C2. Aunque no estén publicados todos los indicadores específicos, la detección basada en comportamiento de tráfico puede dar pistas muy valiosas.

En el endpoint, las organizaciones deberían configurar alertas para la creación de tareas programadas sospechosas, especialmente aquellas que se presentan como actualizadores de fabricantes conocidos pero cuyo binario apunta a rutas poco habituales. También es clave vigilar el uso de mshta.exe y la ejecución de PowerShell o rundll32.exe con parámetros poco comunes.

Por último, en lo relativo a dispositivos externos, se recomienda restringir o bloquear la ejecución de archivos LNK desde unidades extraíbles en entornos de alto riesgo, o al menos someter estos accesos directos a políticas de análisis reforzado. Esto reduce las probabilidades de que la amenaza se propague a nuevos equipos mediante USBs u otros medios similares.

PyStoreRAT y SetcodeRat ilustran muy bien hasta qué punto los atacantes están perfeccionando los RAT modulares, el abuso de plataformas legítimas como GitHub y el uso de técnicas de evasión centradas en regiones o perfiles específicos. Solo combinando escrutinio del código, buenas prácticas de descarga, monitorización de red y controles en el endpoint se puede reducir de verdad el impacto de este tipo de campañas, que cada vez juegan mejor con nuestra confianza en el software “popular” y en los ecosistemas abiertos.