Saltar al contenido
Software Supply Chain Security

StubMaker: campaña de typosquatting en RubyGems

Typosquatting op RubyGems

Un nuevo incidente de typosquatting en RubyGems ha puesto en alerta a la comunidad de Ruby. La actividad, rastreada por investigadores como StubMaker, utilizó paquetes publicados con nombres que se parecían a dependencias legítimas para atraer instalaciones en sistemas Windows. El objetivo fue amplio: desde robo de credenciales hasta datos de carteras de criptomonedas y acceso a información asociada a Telegram.

La campaña fue detectada el 15 de agosto de 2026 y, según los reportes, los paquetes maliciosos ya fueron retirados del repositorio. Aun así, el caso deja varias lecciones técnicas sobre cómo ciertos comportamientos del ecosistema pueden facilitar el abuso.

Qué es la campaña de typosquatting en RubyGems

El término typosquatting describe una táctica en la que un atacante registra nombres de paquetes casi iguales a otros conocidos, buscando que los usuarios se equivoquen al teclear o al copiar instrucciones. En este caso, los investigadores identificaron un conjunto de 16 gemas publicadas con variaciones tipográficas de dependencias de Ruby populares.

El seguimiento se realiza bajo el nombre StubMaker, asociado a una familia de software malicioso que actúa durante la instalación. Aunque los nombres recuerdan a librerías legítimas, el análisis indica que el acercamiento no buscaba una apariencia “perfecta” ni se apoyaba en tácticas sofisticadas de posicionamiento; más bien, se trataba de errores ortográficos deliberados y poco “pulidos”.

Qué paquetes se publicaron y cuál fue su estado

De acuerdo con el reporte, la campaña incluyó gemas publicadas con nombres como: ubnuler, ubnlder, ri18nr, reaker, rakier, orakw, joxn, ise18n, ioe18n, ie18u, iai8n, i1l8n, i18om, activesupmport, brumdler y brundlef.

Las investigaciones señalan que, al momento del informe, estos paquetes fueron eliminados (yanked) de RubyGems. Además, se atribuye su publicación a dos cuentas vinculadas a los usuarios mod8rz41mje (Riley Miller) y rbq95bwt6q (Alex Davis).

Objetivo del malware: credenciales, carteras y datos de Telegram

El componente malicioso se diseñó para recolectar información sensible desde el equipo comprometido. Entre los datos que busca se incluyen:

  • Credenciales de navegadores basados en Chromium, usando un enfoque que evita protecciones de cifrado por aplicación.
  • Carteras de criptomonedas y frases semilla (seed phrases).
  • Datos de Telegram Desktop.
  • Historial de navegación, información de extensiones y números de tarjetas.
  • Información del sistema y la IP pública consultando un servicio externo.

De forma adicional, el robo no se limita a “capturar”, sino que también contempla el empaquetado y la exfiltración: los datos se suben a un servicio de almacenamiento como un archivo ZIP protegido con contraseña y se envía un enlace de descarga al atacante mediante un canal sin cifrado.

Cómo funcionaba StubMaker durante la instalación

Uno de los puntos más relevantes del caso es el vector de ejecución dentro del proceso de instalación de gemas. En términos generales, la cadena aprovecha un gancho de Ruby denominado extconf.rb, que se ejecuta automáticamente cuando el usuario instala una gema. Este archivo se usa normalmente para configurar extensiones nativas incluidas en el paquete.

En el escenario de StubMaker, ese hook se convierte en un conducto para iniciar descargas y ejecución. El flujo descrito por los investigadores se puede resumir así:

  • El hook de instalación genera una configuración (“Makefile”) y scripts simulados.
  • Cuando Ruby ejecuta el flujo de instalación, se activa el punto de entrada real para recuperar un loader basado en Rust.
  • Ese loader incluye o desencadena un stealer escrito en Go.
  • El stealer incorpora un componente DLL que extrae datos de navegadores y otros artefactos del sistema.

Los investigadores subrayan un detalle: StubMaker “no construye” nada de forma útil. En lugar de eso, usa objetivos vacíos para que la fase de compilación parezca correcta, mientras que el trabajo real ocurre en el hook del instalador.

El papel de la técnica ABE en el robo de credenciales

El informe indica que el robo de datos de navegadores basados en Chromium se realiza sorteando protecciones de cifrado conocidas como ABE (App-Bound Encryption) introducidas por Google. Esto permite al malware acceder a secretos que, en condiciones normales, estarían ligados a la aplicación correspondiente y protegidos por el modelo de cifrado del navegador.

Además de credenciales, se recopilan datos relacionados con extensiones, historial y elementos financieros. Este enfoque amplía el impacto más allá del acceso puntual a cuentas: se orienta a consolidar materiales que faciliten fraude o persistencia.

Abuso de comportamientos de RubyGems al retirar versiones

En al menos dos casos, el reporte identifica una estrategia adicional para sostener el ataque incluso después del retiro de versiones. Las gemas brumdler y brundlef se habrían visto afectadas por un comportamiento conocido de RubyGems: cuando todas las versiones de una gema están “yanked”, el espacio de nombre puede quedar disponible para que otro actor lo reclame.

Según el análisis, las gemas fueron publicadas originalmente por la cuenta gemlewqqhu1 (Taylor Moore) y más tarde fueron “reclamadas” por las dos cuentas asociadas a la campaña. La consecuencia práctica es clara: lo que debería quedar inhabilitado para siempre pudo reactivarse y volverse a usar para comprometer a más personas.

La trampa del campo “Author” sin validación

Otro componente del engaño fue cosmético pero efectivo. El atacante asignó un nombre distinto en el campo Author para cada gema, con la idea de que parecieran no relacionadas. El problema es que el campo “Author” funciona como texto plano y no está validado contra el propietario real, por lo que no necesariamente coincide con la cuenta dueña del paquete.

Así, incluso si una gema se revisa superficialmente, puede pasar desapercibida por pequeñas diferencias en la metainformación.

Conexión con incidentes recientes de supply chain en npm

El anuncio sobre StubMaker coincide con otra alerta de seguridad: investigadores también identificaron campañas de supply chain dirigidas a npm. En uno de los casos se detectaron paquetes que apuntaban a campos de ejecutables definidos en package.json, aprovechando una brecha en cómo se registran nombres no acotados.

En el otro, se observaron modificaciones maliciosas en forks relacionados con mensajería, incluyendo comportamientos que manipulan el seguimiento de canales y alteran el contenido multimedia enviado por bots.

Si bien ambos eventos ocurren en ecosistemas distintos, comparten un patrón: el abuso de mecanismos de instalación y metadatos para ejecutar o propagar acciones maliciosas.

Qué pueden hacer usuarios y equipos para reducir el riesgo

Aunque los paquetes ya fueron retirados, el incidente refuerza buenas prácticas para evitar caer en typosquatting en RubyGems y otras técnicas similares:

  • Verifica nombres y versiones antes de instalar gemas, especialmente cuando se copian comandos o snippets de internet.
  • Revisa el propietario del paquete, no solo el nombre del autor mostrado en metadatos.
  • Utiliza controles de seguridad en tu proceso de dependencias (por ejemplo, políticas internas y revisión).
  • Monitoriza instalaciones y actividad inusual en entornos críticos, en especial durante la fase de gem install.

Como regla general, cuanto más “automático” sea el flujo de instalación, más importante es la verificación previa y la supervisión posterior.

Conclusión

La campaña StubMaker muestra cómo el typosquatting en RubyGems puede convertirse en un problema de seguridad real cuando el atacante integra ejecución durante la instalación. Al robar credenciales de navegadores, datos de Telegram y materiales de carteras cripto, el impacto va más allá de la mera infección: se enfoca en consolidar información para fraude y abuso.

El hecho de que varias gemas terminaran retiradas ayuda, pero el caso también revela por qué ciertos detalles del funcionamiento del repositorio—como la disponibilidad de nombres tras el retiro y la falta de validación en el campo “Author”—pueden dar nueva vida a paquetes maliciosos. Para la comunidad, la mejor defensa es una higiene estricta al gestionar dependencias y una verificación constante de lo que se instala.

Fuente: https://thehackernews.com/2026/08/16-typosquatted-rubygems-packages-steal.html