Saltar al contenido principal

El ataque Shai-Hulud: Cómo un gusano de la cadena de suministro robó 58 millones de dólares a desarrolladores y usuarios de criptomonedas

· 12 min de lectura
Dora Noda
Software Engineer

En la víspera de Navidad de 2025, mientras la mayor parte del mundo cripto estaba de vacaciones, unos atacantes lanzaron una actualización maliciosa para la extensión de Chrome de Trust Wallet. En 48 horas, $ 8.5 millones desaparecieron de 2,520 billeteras. Las frases semilla de miles de usuarios habían sido recolectadas silenciosamente, disfrazadas como datos de telemetría de rutina. Pero este no fue un incidente aislado; fue la culminación de un ataque a la cadena de suministro que se había estado extendiendo por el ecosistema de desarrollo cripto durante semanas.

La campaña Shai-Hulud, nombrada en honor a los gusanos de arena de Dune, representa el ataque a la cadena de suministro de npm más agresivo de 2025. Comprometió más de 700 paquetes npm, infectó 27,000 repositorios de GitHub y expuso aproximadamente 14,000 secretos de desarrollador en 487 organizaciones. El daño total: más de $ 58 millones en criptomonedas robadas, lo que lo convierte en uno de los ataques dirigidos a desarrolladores más costosos en la historia de las criptomonedas.

La anatomía de un gusano de la cadena de suministro

A diferencia del malware típico que requiere que los usuarios descarguen software malicioso, los ataques a la cadena de suministro envenenan las herramientas en las que los desarrolladores ya confían. La campaña Shai-Hulud convirtió en un arma a npm, el gestor de paquetes que impulsa la mayor parte del desarrollo de JavaScript, incluyendo casi todas las billeteras cripto, frontends de DeFi y aplicaciones Web3.

El ataque comenzó en septiembre de 2025 con la primera ola, que resultó en el robo de aproximadamente $ 50 millones en criptomonedas. Pero fue "La Segunda Venida" en noviembre lo que demostró la verdadera sofisticación de la operación. Entre el 21 y el 23 de noviembre, los atacantes comprometieron la infraestructura de desarrollo de proyectos importantes, incluidos Zapier, ENS Domains, AsyncAPI, PostHog, Browserbase y Postman.

El mecanismo de propagación fue elegante y aterrador. Cuando Shai-Hulud infecta un paquete npm legítimo, inyecta dos archivos maliciosos — setup_bun.js y bun_environment.js — activados por un script de preinstalación. A diferencia del malware tradicional que se activa después de la instalación, esta carga útil se ejecuta antes de que se complete la instalación e incluso cuando la instalación falla. Para cuando los desarrolladores se dan cuenta de que algo anda mal, sus credenciales ya han sido robadas.

El gusano identifica otros paquetes mantenidos por desarrolladores comprometidos, inyecta automáticamente código malicioso y publica nuevas versiones comprometidas en el registro de npm. Esta propagación automatizada permitió que el malware se extendiera exponencialmente sin la intervención directa del atacante.

De los secretos del desarrollador a las billeteras de los usuarios

La conexión entre los paquetes npm comprometidos y el hackeo de Trust Wallet revela cómo los ataques a la cadena de suministro caen en cascada desde los desarrolladores hasta los usuarios finales.

La investigación de Trust Wallet reveló que sus secretos de GitHub para desarrolladores quedaron expuestos durante el brote de Shai-Hulud en noviembre. Esta exposición dio a los atacantes acceso al código fuente de la extensión del navegador y, fundamentalmente, a la clave API de Chrome Web Store. Armados con estas credenciales, los atacantes eludieron por completo el proceso interno de lanzamiento de Trust Wallet.

El 24 de diciembre de 2025, la versión 2.68 de la extensión de Chrome de Trust Wallet apareció en la Chrome Web Store, publicada por los atacantes, no por los desarrolladores de Trust Wallet. El código malicioso fue diseñado para iterar a través de todas las billeteras almacenadas en la extensión y activar una solicitud de frase mnemotécnica para cada billetera. Ya sea que los usuarios se autenticaran con una contraseña o con biometría, sus frases semilla eran exfiltradas silenciosamente a servidores controlados por los atacantes, disfrazadas como datos analíticos legítimos.

Los fondos robados se desglosaron de la siguiente manera: aproximadamente 3millonesenBitcoin,maˊsde3 millones en Bitcoin, más de 3 millones en Ethereum y cantidades menores en Solana y otros tokens. En pocos días, los atacantes comenzaron a lavar los fondos a través de exchanges centralizados: 3.3millonesaChangeNOW,3.3 millones a ChangeNOW, 340,000 a FixedFloat y $ 447,000 a KuCoin.

El interruptor del hombre muerto (Dead Man's Switch)

Quizás lo más inquietante es el mecanismo de "interruptor del hombre muerto" del malware Shai-Hulud. Si el gusano no puede autenticarse con GitHub o npm — si sus canales de propagación y exfiltración son cortados — borrará todos los archivos en el directorio principal del usuario.

Esta característica destructiva sirve para múltiples propósitos. Castiga los intentos de detección, crea un caos que oculta las huellas de los atacantes y proporciona una palanca de presión si los defensores intentan cortar la infraestructura de comando y control. Para los desarrolladores que no han mantenido copias de seguridad adecuadas, un intento fallido de limpieza podría resultar en una pérdida catastrófica de datos, además del robo de credenciales.

Los atacantes también demostraron sofisticación psicológica. Cuando Trust Wallet anunció la brecha, los mismos atacantes lanzaron una campaña de phishing explotando el pánico resultante, creando sitios web falsos con la marca Trust Wallet que pedían a los usuarios que ingresaran sus frases semilla de recuperación para la "verificación de la billetera". Algunas víctimas fueron comprometidas dos veces.

La cuestión del infiltrado

El cofundador de Binance, Changpeng Zhao (CZ), insinuó que el exploit de Trust Wallet fue "muy probablemente" llevado a cabo por un infiltrado o alguien con acceso previo a los permisos de despliegue. El propio análisis de Trust Wallet sugiere que los atacantes podrían haber ganado el control de los dispositivos de los desarrolladores u obtenido permisos de despliegue antes del 8 de diciembre de 2025.

Los investigadores de seguridad han notado patrones que sugieren una posible participación de estados-nación. El momento elegido — la víspera de Navidad — sigue el manual común de las amenazas persistentes avanzadas (APT): atacar durante las vacaciones cuando los equipos de seguridad cuentan con menos personal. La sofisticación técnica y la escala de la campaña Shai-Hulud, combinadas con el rápido lavado de fondos, sugieren recursos que van más allá de las operaciones criminales típicas.

Por qué las extensiones de navegador son excepcionalmente vulnerables

El incidente de Trust Wallet resalta una vulnerabilidad fundamental en el modelo de seguridad cripto. Las extensiones de navegador operan con privilegios extraordinarios: pueden leer y modificar páginas web, acceder al almacenamiento local y, en el caso de las billeteras cripto, poseer las llaves de millones de dólares.

La superficie de ataque es masiva:

  • Mecanismos de actualización: Las extensiones se actualizan automáticamente, y una sola actualización comprometida llega a todos los usuarios.
  • Seguridad de las claves API: Las claves API de Chrome Web Store, si se filtran, permiten que cualquiera publique actualizaciones.
  • Supuestos de confianza: Los usuarios asumen que las actualizaciones de las tiendas oficiales son seguras.
  • Momento de las festividades: El monitoreo de seguridad reducido durante las vacaciones permite un tiempo de permanencia más largo de la amenaza.

Este no es el primer ataque de extensiones de navegador contra usuarios de criptomonedas. Incidentes anteriores incluyen la campaña GlassWorm que tuvo como objetivo las extensiones de VS Code y el fraude de la extensión FoxyWallet en Firefox. Pero la brecha de Trust Wallet fue la mayor en términos de dólares y demostró cómo los compromisos en la cadena de suministro amplifican el impacto de los ataques a las extensiones.

La respuesta de Binance y el precedente de SAFU

Binance confirmó que los usuarios afectados de Trust Wallet serían reembolsados en su totalidad a través de su Fondo de Activos Seguros para Usuarios (SAFU). Este fondo, establecido tras un hackeo al intercambio en 2018, mantiene una parte de las comisiones de trading en reserva específicamente para cubrir las pérdidas de los usuarios por incidentes de seguridad.

La decisión de reembolsar sienta un precedente importante y plantea una pregunta interesante sobre la asignación de responsabilidades. Trust Wallet se vio comprometido sin culpa directa de los usuarios, quienes simplemente abrieron sus billeteras durante la ventana afectada. Pero la causa raíz fue un ataque a la cadena de suministro que comprometió la infraestructura de los desarrolladores, lo cual a su vez fue posible gracias a vulnerabilidades más amplias del ecosistema en npm.

La respuesta inmediata de Trust Wallet incluyó la expiración de todas las API de lanzamiento para bloquear nuevas versiones durante dos semanas, la denuncia del dominio de exfiltración malicioso a su registrador (lo que resultó en una pronta suspensión) y el lanzamiento de una versión 2.69 limpia. Se aconsejó a los usuarios migrar sus fondos a billeteras nuevas de inmediato si habían desbloqueado la extensión entre el 24 y el 26 de diciembre.

Lecciones para el ecosistema cripto

La campaña Shai-Hulud expone vulnerabilidades sistémicas que se extienden mucho más allá de Trust Wallet:

Para desarrolladores

Fije las dependencias explícitamente. La explotación de scripts de preinstalación funciona porque las instalaciones de npm pueden ejecutar código arbitrario. Fijar las versiones a versiones conocidas y limpias evita que las actualizaciones automáticas introduzcan paquetes comprometidos.

Trate los secretos como comprometidos. Cualquier proyecto que haya extraído paquetes de npm entre el 21 de noviembre y diciembre de 2025 debe asumir la exposición de sus credenciales. Esto significa revocar y regenerar tokens de npm, PAT de GitHub, claves SSH y credenciales de proveedores de la nube.

Implemente una gestión de secretos adecuada. Las claves API para infraestructuras críticas, como la publicación en tiendas de aplicaciones, nunca deben almacenarse en el control de versiones, ni siquiera en repositorios privados. Utilice módulos de seguridad de hardware (HSM) o servicios dedicados de gestión de secretos.

Aplique MFA resistente al phishing. La autenticación de dos factores estándar puede ser eludida por atacantes sofisticados. Las llaves de hardware como YubiKeys proporcionan una protección más fuerte para las cuentas de desarrolladores y de CI / CD.

Para usuarios

Diversifique la infraestructura de sus billeteras. No mantenga todos sus fondos en extensiones de navegador. Las billeteras de hardware proporcionan aislamiento de las vulnerabilidades de software: pueden firmar transacciones sin exponer nunca las frases semilla a navegadores potencialmente comprometidos.

Asuma que las actualizaciones pueden ser maliciosas. El modelo de actualización automática que hace que el software sea conveniente también lo hace vulnerable. Considere deshabilitar las actualizaciones automáticas para extensiones críticas de seguridad y verificar manualmente las nuevas versiones.

Monitoree la actividad de su billetera. Los servicios que alertan sobre transacciones inusuales pueden proporcionar una advertencia temprana de compromiso, limitando potencialmente las pérdidas antes de que los atacantes vacíen billeteras enteras.

Para la industria

Fortalecer el ecosistema npm. El registro npm es una infraestructura crítica para el desarrollo de Web3, sin embargo, carece de muchas características de seguridad que evitarían la propagación tipo gusano. La firma de código obligatoria, las compilaciones reproducibles y la detección de anomalías para las actualizaciones de paquetes podrían elevar significativamente la vara para los atacantes.

Replanteee la seguridad de las extensiones de navegador. El modelo actual, donde las extensiones se actualizan automáticamente y tienen permisos amplios, es fundamentalmente incompatible con los requisitos de seguridad para custodiar activos significativos. Los entornos de ejecución aislados (sandboxed), las actualizaciones retrasadas con revisión del usuario y la reducción de permisos podrían ayudar.

Coordine la respuesta a incidentes. La campaña Shai-Hulud afectó a cientos de proyectos en todo el ecosistema cripto. Un mejor intercambio de información y una respuesta coordinada podrían haber limitado el daño a medida que se identificaban los paquetes comprometidos.

El futuro de la seguridad de la cadena de suministro en cripto

La industria de las criptomonedas se ha centrado históricamente en auditorías de contratos inteligentes, almacenamiento en frío de intercambios y protección contra el phishing para el usuario. La campaña Shai-Hulud demuestra que los ataques más peligrosos pueden provenir de herramientas de desarrollo comprometidas, una infraestructura con la que los usuarios de cripto nunca interactúan directamente pero que subyace a cada aplicación que utilizan.

A medida que las aplicaciones Web3 se vuelven más complejas, sus gráficos de dependencia crecen. Cada paquete de npm, cada acción de GitHub, cada integración de CI / CD representa un vector de ataque potencial. La respuesta de la industria a Shai-Hulud determinará si esto se convierte en una llamada de atención única o en el comienzo de una era de ataques a la cadena de suministro en la infraestructura cripto.

Por ahora, los atacantes permanecen sin identificar. Aproximadamente 2.8 millones de dólares de los fondos robados de Trust Wallet permanecen en las billeteras de los atacantes, mientras que el resto ha sido lavado a través de intercambios centralizados y puentes entre cadenas (cross-chain bridges). Los más de 50 millones de dólares en robos anteriores de la campaña Shai-Hulud han desaparecido en gran medida en las profundidades seudónimas de la blockchain.

El gusano de arena se ha enterrado profundamente en los cimientos de las criptomonedas. Erradicarlo requerirá replantear los supuestos de seguridad que la industria ha dado por sentados desde sus inicios.


La creación de aplicaciones Web3 seguras requiere una infraestructura robusta. BlockEden.xyz proporciona nodos RPC y APIs de nivel empresarial con monitoreo incorporado y detección de anomalías, ayudando a los desarrolladores a identificar actividades inusuales antes de que afecten a los usuarios. Explore nuestro mercado de APIs para construir sobre bases enfocadas en la seguridad.