La cara oculta de la confianza en código abierto clonaron MCP y desplegaron StealC para robar secretos de alto valor

Hace unos días, investigadores en ciberseguridad destaparon una campaña sofisticada que combina ingeniería social, suplantación de proyectos de código abierto y malware para alcanzar objetivos de alto valor. En el centro de la maniobra está una versión manipulada de un servidor MCP (Model Context Protocol) vinculado al anillo inteligente Oura, que fue clonado y enriquecido con código malicioso para instalar un ladrón de información conocido como StealC.

Según el análisis publicado por Straiker's AI Research (STAR) Labs, los atacantes no optaron por la vía del “ataque rápido y masivo”: invirtieron semanas, incluso meses, en construir una apariencia de legitimidad en plataformas públicas antes de desplegar su payload. Ese trabajo incluyó la creación de múltiples cuentas falsas en GitHub y una red de forks y colaboradores ficticios para que el repositorio infectado pareciera verificado por la comunidad. El repositorio original del proyecto puede consultarse en GitHub, mientras que el informe de Straiker detalla la técnica usada para clonar y trocear la confianza: informe de Straiker.

El vector de entrada fue doble. Por un lado, los operadores subieron la versión troceada del servidor MCP a listados públicos de componentes —incluido un directorio público de MCP— de forma que alguien buscando integrar el servicio en su asistente o flujo de trabajo podía toparse con el paquete malicioso entre alternativas legítimas. Por otro lado, el paquete se distribuía en un ZIP que, al ejecutarse, lanzaba un script Lua ofuscado que dejaba caer SmartLoader, un loader conocido por descargar y ejecutar herramientas adicionales. En este caso, SmartLoader sirvió para desplegar StealC, diseñado para exfiltrar contraseñas de navegadores, credenciales y hasta información de monederos de criptomonedas.

La campaña ejemplifica una evolución preocupante: los atacantes pasan de apuntar a usuarios que buscan software pirateado a dirigirse deliberadamente a desarrolladores y equipos que integran componentes en entornos de desarrollo o producción. Los sistemas de desarrollo suelen albergar secretos de alto valor —como claves de API, tokens de acceso a la nube y accesos a entornos de producción— que multiplican el impacto de una intrusión.

El uso de repositorios y registros públicos como vectores de confianza es clave en este ataque. Al aprovechar la reputación implícita de GitHub y de catálogos específicos, los agresores explotan heurísticas de confianza que suelen seguir los desarrolladores: if a package está en un registro público y tiene una historia aparente de contribuciones, se tiende a asumir que es seguro. Straiker advierte que la campaña fabricó esa historia y la usó como cebo deliberadamente.

Este tipo de abusos de la cadena de suministro no es nuevo, pero sí ha ido ganando sofisticación con técnicas que incluyen generación de contenido por IA para crear descripciones y documentación creíbles, y fabricación de actividad en plataformas públicas. Para entender la magnitud del riesgo es útil recordar que las cadenas de suministro de software son un vector priorizado por organismos de seguridad: iniciativas como las guías de GitHub sobre seguridad de la cadena de suministro y los recursos de agencias como CISA insisten en controles específicos para mitigar ataques de este tipo.

¿Qué pueden hacer equipos y organizaciones? Primero, es imprescindible tratar los componentes de terceros con la misma cautela que el software ejecutable: verificar el origen, revisar el historial real de commits y colaboradores y, cuando sea posible, preferir paquetes firmados o provenientes de mantenedores verificados. También es recomendable establecer controles en el entorno de desarrollo que supervisen conexiones salientes inusuales y mecanismos de persistencia. No basta con confiar en la apariencia; es necesario validar la procedencia y comportamiento del código.

En la práctica, esto implica auditar qué MCP servers están instalados en los entornos, someter cualquier integración nueva a una revisión de seguridad formal y monitorizar la telemetría de red en busca de tráfico hacia infraestructuras desconocidas. Además, las organizaciones deberían gestionar y rotar secretos, minimizar privilegios en los entornos de desarrollo y usar escaneo automatizado de dependencias para detectar cambios inesperados en proyectos de terceros.

El caso también plantea preguntas sobre cómo evoluciona la confianza en el ecosistema de desarrollo abierto en la era de la IA. Fabricar credenciales comunitarias —repositorios con forks y colaboradores falsos, documentación generada automáticamente, listados en directorios públicos— añade una capa nueva de engaño que desafía heurísticas tradicionales. Straiker resume la lección: los atacantes están invirtiendo tiempo y recursos para fabricar confianza porque saben que ese es el atajo más eficaz para acceder a víctimas de alto valor.

Para quienes usan dispositivos o servicios relacionados con Oura, conviene estar atentos a comunicaciones oficiales y actualizaciones del fabricante en Oura. Y para equipos de software, la recomendación es clara: integrar controles de seguridad en el ciclo de vida del desarrollo y no descargar ni instalar componentes sin una verificación previa. Las buenas prácticas y la vigilancia continua siguen siendo las mejores defensas frente a campañas que combinan ingeniería social, abuso de plataformas públicas y malware.

La campaña que empleó SmartLoader y StealC recuerda que la amenaza no siempre llega por ventanas obvias; a veces entra por la puerta que el propio ecosistema de desarrollo dejó abierta. La confianza en la cadena de suministro digital debe ganarse y supervisarse continuamente, no asumirse por defecto.