Reportadas pérdidas en el incidente Ledger CryptoBilis alcanzaron un valor estimado de $93.2 millones de dólares provenientes de 315 carteras en seis blockchains, tras drains coordinados el 9 de octubre de 2026, mientras Ledger confirmó la existencia de un implante de hardware no autorizado en uno de los dispositivos afectados. Ledger no ha confirmado una cifra exacta de pérdidas, la identidad del atacante, el modelo del dispositivo afectado ni si el mecanismo de implantación identificado en investigaciones públicas explica todos los robos reportados.
Conclusión clave: El incidente Ledger CryptoBilis se entiende mejor como un ataque en la cadena de suministro de hardware-wallets contra el método de visualización de la frase de recuperación, no como una comprometida confirmada del firmware de Ledger, del elemento seguro o de la infraestructura propia de Ledger.
¿Qué ocurrió durante los drains en las wallets Ledger CryptoBilis?
Los drains en las wallets Ledger CryptoBilis fueron un robo coordinado en múltiples cadenas que comenzó alrededor de las 05:07 UTC del 9 de octubre de 2026, afectando a usuarios que adquirieron dispositivos Ledger a través de CryptoBilis en Malasia, Indonesia y Filipinas. Analysis blockchain estima que 315 carteras perdieron aproximadamente $93.2 millones de dólares en Bitcoin, Ethereum, TRON, BNB Chain, Polygon y Solana, aunque Ledger no ha validado dicha estimación.
El momento es importante porque la secuencia en la cadena indica un acceso sincronizado en lugar de errores aislados de los usuarios. Aproximadamente a las 05:00 UTC, 30 wallets TRON tenían la misma nueva llave agregada a los permisos de la cuenta. A las 05:07:48 UTC, 13 wallets TRON firmaron la misma aprobación de token, seguidas por otras 12 en segundos. Las aprobaciones iniciales en TRON permitieron retirar aproximadamente $29 millones.
Luego comenzaron los drains en BNB Chain, Polygon y Ethereum entre las 05:07 y las 05:09 UTC. A las 05:54 UTC, 111 wallets de Bitcoin fueron vaciadas en un solo bloque, retirando unos 203 BTC. La secuencia es coherente con un actor controlando credenciales capaces de autorizar actividades en varias wallets casi simultáneamente.
Los investigadores señalaron públicamente las direcciones de los drains alrededor de las 12:00 UTC del 9 de octubre. Ledger emitió su primera declaración a las 13:32 UTC, informó que investigaba reportes relacionados con CryptoBilis y solicitó a los revendedores que detuvieran las ventas. El 10 de octubre, CryptoBilis suspendió las ventas y envíos de todas las marcas de hardware-wallets y cerró tiendas físicas como medida precautoria.
Ledger confirmó el 10 de octubre que uno de los dispositivos afectados contenía un implante de hardware no autorizado. Para el 11 de octubre, Ledger afirmó que los casos confirmados estaban vinculados a dispositivos CryptoBilis, que el volumen de dispositivos afectados era limitado y que colaboraba con las autoridades pertinentes. También dijo Ledger que no tenían indicios de que su infraestructura, sistemas, servicios o canales de ventas directas hubiesen sido comprometidos.
| Fecha y hora | Evento del incidente Ledger CryptoBilis | Detalle concreto reportado |
|---|---|---|
| 25 de septiembre de 2026 | Direcciones controladas por atacante reciben fondos iniciales | Analysis blockchain identifica la primera actividad de fondos |
| 26 de septiembre a 7 de octubre de 2026 | Actividad de prueba en TRON y Ethereum | 21 transacciones de prueba en TRON y 20 en Ethereum |
| 9 de octubre de 2026, cerca de las 05:00 UTC | Cambios en permisos en TRON | 30 wallets victimarias recibieron la misma nueva clave |
| 9 de octubre de 2026, 05:07 UTC | Comienzo del drain masivo | 25 wallets TRON firmaron la misma aprobación en segundos |
| 9 de octubre de 2026, 05:54 UTC | Carteras Bitcoin vaciadas | 111 wallets de Bitcoin vaciadas en un solo bloque |
| 9 de octubre de 2026, 13:32 UTC | Primer comunicado público de Ledger | Ledger informó que investigaba reportes vinculados a CryptoBilis |
| 10 de octubre de 2026, 17:09 UTC | Confirmación de evidencia de manipulación física | Un dispositivo afectado contenía un implante de hardware no autorizado |
| 11 de octubre de 2026, 07:00 UTC | Estimado público revisado | Aproximadamente $93.2 millones en 315 wallets en seis cadenas |
| 11 de octubre de 2026, 17:13 UTC | Actualización de 72 horas | Ledger mencionó que el volumen de dispositivos impactados era limitado |
La concentración de pérdidas también fue desigual. Según la estimación pública en blockchain, 131 wallets TRON representaron aproximadamente $70.5 millones, incluyendo alrededor de 70.2 millones en USDT y algunos TRX. Bitcoin representó 122 wallets y 203.8 BTC, valorados en aproximadamente $16.8 millones. Ethereum, BNB Chain, Polygon y Solana completaron las pérdidas restantes identificadas.
En los trabajos de seguridad en contratos inteligentes y infraestructura de Soken, las aprobaciones sincronizadas y cambios en credenciales en wallets no relacionadas son una señal fuerte de respuesta a incidentes: los responsables deben primero identificar el frontera de confianza compartida, en lugar de tratar cada wallet afectada como un compromiso separado.
¿Por qué los datos apuntan a un ataque en la cadena de suministro de hardware?
La evidencia disponible indica un ataque en la cadena de suministro de hardware porque Ledger confirmó un implante no autorizado en un dispositivo afectado, mientras afirma que sus propios sistemas y canales de ventas directas no fueron afectados. El método propuesto para el implante captura las palabras de recuperación cuando se muestran en la pantalla del dispositivo, lo que evita la necesidad de derrotar al elemento seguro o alterar el firmware de Ledger.
Las investigaciones públicas en hardware han descrito dispositivos que contienen una placa adicional oculta bajo la pantalla. Una hipótesis públicamente descrita usa un módulo LTE, eSIM de datos, y un microcontrolador conectado al bus de datos de la pantalla. Bajo esa hipótesis, el implante espera a que se configure el dispositivo, reconoce la frase de recuperación en texto claro en pantalla, y la exfiltra mediante una conexión móvil.
Ledger no ha confirmado ese mecanismo, ni el modelo del dispositivo implantado que examinó, ni cuántos dispositivos se vieron afectados. Por tanto, el mecanismo debe considerarse una explicación técnica plausible respaldada por investigaciones externas, no una narrativa confirmada que explique todas las robos en Ledger CryptoBilis.
La diferencia clave es que un elemento seguro protege las operaciones con clave privada dentro del dispositivo. Un implante de lectura de pantalla no necesita extraer la clave privada del elemento seguro si puede capturar la frase de recuperación durante la inicialización. Una vez que un atacante obtiene la frase de recuperación, puede recrear el acceso a la wallet en otro lugar y firmar transacciones sin requerir acceso físico continuo al dispositivo original.
Esto explica por qué los análisis públicos detectaron cambios coordinados de llave, aprobaciones de token y drains en varias cadenas. Los registros de blockchain pueden demostrar que el mismo actor controló las wallets afectadas, pero la blockchain en sí misma no revela cómo se obtuvieron las frases de recuperación o las credenciales de firma.
El incidente Ledger CryptoBilis también difiere de una estafa con wallets precargados. Ledger afirmó que los dispositivos genuinos nunca llegan con un frase de recuperación o PIN ya configurados. Ningún reporte público en este incidente afirma que los dispositivos tengan semillas impresas, tarjetas de rasguño o credenciales preconfiguradas. El riesgo aquí descrito es la exposición de una frase recién generada en el momento exacto en que un usuario espera que el proceso de configuración sea privado.
Para organizaciones que gestionan activos de tesorería, esta distinción debería impulsar revisiones de seguridad técnicas. Una revisión limitada al código del contrato o firmware del dispositivo no identificará todas las exposiciones creadas por compras, inicialización, manejo físico y procedimientos de semillas de recuperación.
¿Por qué Ledger Genuine Check no detectó el supuesto implante?
Ledger Genuine Check no fue diseñado para detectar un implante que conserve el elemento seguro original, ya que esa verificación valida una atestación criptográfica y no toda la historia física de la cadena de suministro del dispositivo. El propio modelo de amenaza de Ledger indica que Genuine Check no puede detectar modificaciones físicas no autorizadas cuando el elemento seguro original permanece intacto.
El proceso Genuine Check funciona mediante un diseño de desafío-respuesta. El elemento seguro de Ledger demuestra que es genuino creando una firma criptográfica correcta para un desafío. Ese diseño proporciona confianza sobre la autenticidad del elemento seguro, lo cual es valioso contra dispositivos falsificados que reemplazan componentes confiables centrales.
Un implante físico puede estar fuera de ese límite de confianza. Si una parte maliciosa añade circuitería sin reemplazar el elemento seguro auténtico, este aún puede responder correctamente al desafío de atestación. Por lo tanto, el dispositivo podría pasar Genuine Check aunque otro componente haya sido añadido para observar la pantalla o interactuar con comunicaciones externas.
Esto no prueba que Genuine Check haya fallado en su propósito criptográfico. Es evidencia de que la autenticación del dispositivo y la integridad de la cadena de suministro son propiedades de seguridad distintas.
| Pregunta de seguridad | Ledger Genuine Check | Control en la cadena de suministro necesario para el escenario Ledger CryptoBilis |
|---|---|---|
| ¿Es el elemento seguro auténtico? | El elemento seguro firma un desafío de atestación | Verificar origen autorizado y custodia antes de la inicialización |
| ¿Puede el dispositivo demostrar su historia física? | No, Ledger afirma que Genuine Check no puede verificar la historia física | Mantener trazabilidad en revendedores, distribuidores, almacenes y devoluciones |
| ¿Se puede identificar un implante que observe la pantalla? | No, si el elemento seguro original permanece intacto | Usar inspección de manipulación y procedimientos controlados de configuración |
| ¿El control protege la frase de recuperación de 24 palabras durante la configuración? | No por sí solo | Generar y registrar la frase solo en un entorno físico confiable |
| ¿El control establece si los sistemas de Ledger fueron comprometidos? | No | Ledger afirmó no tener indicios de compromiso en su infraestructura o canales de ventas directas |
El patrón del ataque refuerza un principio de seguridad más amplio: la criptografía puede ser sólida, mientras que el camino alrededor de esa criptografía puede estar comprometido. La frase de recuperación se muestra deliberadamente en texto claro para permitir su respaldo. Ese momento de usabilidad necesario se vuelve un elemento crítico si un componente malicioso puede observar la pantalla.
Por tanto, los equipos deberían evitar tratar la verificación de hardware-wallets como un proceso en un solo paso. Un proceso robusto combina verificaciones de autenticidad del dispositivo, compras documentadas, recepción a prueba de manipulaciones, inicialización controlada, revisión independiente de transacciones y un procedimiento definido de migración en caso de exposición sospechada.
Los servicios de seguridad de Soken pueden ayudar a mapear estos controles en el despliegue de wallets, acceso operativo, permisos en contratos inteligentes y flujos de respuesta a incidentes. La pregunta relevante no es solo si un firmante es genuino, sino si cada etapa que maneja la frase de recuperación y la autoridad para firmar transacciones es confiable.
¿Qué deben hacer ahora los usuarios y organizaciones afectadas por Ledger CryptoBilis?
Los usuarios afectados por Ledger CryptoBilis no deben inicializar dispositivos no utilizados comprados a través de CryptoBilis y deben transferir sus activos desde cualquier dispositivo CryptoBilis ya inicializado a un nuevo firmante Ledger usando una nueva semilla. Reutilizar la frase de recuperación antigua en un dispositivo de reemplazo preservaría la exposición sospechada y no constituiría una migración segura.
Las recomendaciones iniciales de Ledger cubrían usuarios que habían comprado en CryptoBilis en los últimos 90 días, y luego se ampliaron para aconsejar no inicializar dispositivos CryptoBilis no utilizados sin un límite de tiempo establecido. Ledger también indicó a los usuarios contactar canales de soporte oficiales y presentar denuncias a las autoridades locales cuando fuera apropiado.
Una migración debe tratarse como una operación de seguridad controlada, no solo como una transferencia entre interfaces de wallet:
-
Dejar de usar el dispositivo sospechoso. No inicializar un Ledger con enlace a CryptoBilis y no usar un dispositivo ya inicializado para crear nuevas estructuras de wallets a largo plazo.
-
Crear una frase de recuperación genuinamente nueva. El firmante de reemplazo debe generar una nueva semilla. Importar una frase antigua en otra wallet conserva el riesgo de que la frase original fue expuesta.
-
Mover fondos a direcciones derivadas de la nueva semilla. Confirmar la dirección de destino a través de la pantalla confiable del firmante nuevo y realizar verificaciones cuidadosas en cada transferencia.
-
Revisar permisos delegados. En TRON, Ethereum, BNB Chain, Polygon, Solana y otras redes relevantes, revisar aprobaciones, permisos de cuenta y autoridad delegada para firmar vinculada a la wallet antigua.
-
Anticipar ingeniería social secundaria. Ledger afirmó que nunca llamará, enviará mensajes directos o solicitará la frase de recuperación de 24 palabras. Durante migraciones, pueden aparecer páginas de phishing, contactos falsos de soporte y aplicaciones fraudulentas.
-
Conservar evidencia. Guardar recibos, empaques, comunicaciones y registros relevantes de las wallets. No desmontar un dispositivo si eso puede dañar evidencia que requieran investigadores o autoridades.
El movimiento posterior al drain de fondos muestra por qué la contención rápida es importante. Analysis blockchain pública indica que el atacante puenteó 20 millones en USDT en 40 partes iguales, intercambió esa cantidad por aproximadamente 7,994 ETH, y convirtió alrededor de 14.9 millones en USDT en USDD. Otras rutas reportadas incluyen Relay.link, Chainflip, HiFiSwap, NEAR Intents y aproximadamente 2,990 ETH en Tornado Cash.
Tether congeló aproximadamente $10.0 millones en USDT en 20 wallets vinculadas al atacante el 9 de octubre. Hasta el 12 de octubre no se había devuelto fondos a las víctimas ni se había anunciado alguna compensación. La recuperación de activos depende de la velocidad, la calidad de la evidencia, la coordinación legal y las rutas elegidas por el atacante en varias cadenas y servicios. Las organizaciones que enfrentan pérdidas en wallets en múltiples jurisdicciones también podrían necesitar soporte legal y de cumplimiento junto con medidas técnicas de contención.
¿Qué cambio supone el incidente Ledger CryptoBilis para la seguridad de hardware-wallets?
El incidente Ledger CryptoBilis demuestra que la seguridad en hardware-wallets debe incluir el camino confiable desde la adquisición por parte del revendedor, pasando por la inicialización de la frase de recuperación, porque la criptografía central fuerte no protege una frase que se observa antes de que se convierta en un secreto. La confirmación de un implante en un dispositivo hace de los controles en la cadena de suministro física un requisito práctico de seguridad, no solo una preocupación teórica.
El evento no debería ser malinterpretado como un zero-day confirmado en Ledger. Ledger afirmó que su infraestructura y canales de venta directa no fueron afectados, y ninguna fuente pública indica que el elemento seguro de Ledger o su firmware hayan sido vulnerados. Igualmente, hasta el 12 de octubre no se ha atribuido credibilidad alguna a actores o grupos específicos, y las afirmaciones en redes sociales sobre participación estatal siguen siendo especulación.
El incidente no debe generalizarse a una afirmación de que todos los dispositivos Ledger, todos los revendedores o todas las wallets de hardware están comprometidos. Ledger aseguró que todos los casos confirmados estaban vinculados a CryptoBilis y que no tiene reportes que involucren dispositivos adquiridos directamente en Ledger. La respuesta adecuada es una reducción de riesgo dirigida, basada en evidencias de compra y configuración.
Una comparación útil es la diferencia entre el incidente Ledger CryptoBilis y otros modos de fallo en hardware-wallets. En el caso reportado de Coldcard, julio de 2026, se informó que firmware antiguo generaba semillas con probabilidad débil. En el caso Ledger CryptoBilis, la preocupación reportada es la observación física de una semilla correctamente generada. En un escenario con dispositivo falsificado, toda la plataforma hardware puede ser fraudulenta. Cada caso ataca un segmento diferente del camino confiable.
Para mayor contexto en análisis de incidentes, los lectores pueden consultar el centro de investigación en seguridad de Soken, especialmente en la elaboración de políticas de wallets que conecten controles técnicos con decisiones operativas.
Trate el incidente Ledger CryptoBilis como una prueba de seguridad en adquisición e inicialización: identifique todos los hardware-wallets adquiridos a través de CryptoBilis, detenga la configuración de unidades no utilizadas y migre cualquier dispositivo ya inicializado a una semilla recién generada. Ese paso concreto de inventario y migración aborda la ruta de riesgo verificada de manera más efectiva que confiar solo en una comprobación Genuine Check.