Un fallo de firmware Coldcard habría estado detrás de un robo especialmente rápido: el 30 de julio, un atacante vació 1.196 direcciones de Bitcoin en solo 41 minutos. Según el mapeo realizado por Galaxy Research, el movimiento inicial incluyó 1.082,65 BTC, que en ese momento rondaban los 70,2 millones de dólares.
El caso no se limita a una cifra llamativa. El análisis apunta a un problema concreto en cómo el dispositivo generaba la semilla (seed) al integrarse una versión de firmware. Además, la historia tuvo continuidad: se identificaron nuevas “olas” sospechosas que elevaron el total observado.
Qué pasó: el vaciado en 41 minutos
La investigación describe que el atacante realizó una operación de barrido (sweep) sobre múltiples direcciones. El patrón de las transacciones encaja con movimientos que, en la práctica, pueden parecer una acción legítima de un propietario que decide reorganizar sus fondos. Aun así, al cruzar las direcciones afectadas, Galaxy pudo vincular el barrido a un origen técnico relacionado con la generación de seeds en el dispositivo.
En el informe inicial, Galaxy remarcó que no vio otras transacciones previas en la ventana temporal analizada con un comportamiento similar (por ejemplo, el mismo contexto asociado a tarifas y firma “de cambio”). Eso ayudó a delimitar el periodo y el alcance del incidente.
El núcleo del fallo de firmware Coldcard
De acuerdo con el análisis, el origen estuvo en una integración del firmware ocurrida en marzo de 2021. El problema consistía en que la generación de seed quedaba encaminada hacia un PRNG determinista por software en lugar de usar el generador aleatorio del hardware (RNG) del microcontrolador.
Cuando la aleatoriedad se ve comprometida, el riesgo cambia de naturaleza: ya no se trata solo de que alguien “adivine” una semilla al azar, sino de que, en ciertas condiciones, el atacante podría reproducir secuencias candidatas sin necesidad de acceder físicamente al dispositivo en el momento del ataque.
El informe detalla una idea central: si el atacante puede determinar o acotar suficientemente datos como el identificador del dispositivo (UID), el estado del temporizador y el historial de llamadas previas relacionadas con el RNG, entonces puede construir flujos de salida candidatos fuera del dispositivo. Luego, con esas semillas candidatas, puede derivar direcciones y comparar con información pública de la cadena de bloques.
Por qué el parche no “arregla” una seed ya creada
Uno de los puntos más importantes para el usuario es el siguiente: la corrección del fabricante se orientó a corregir la generación futura, pero no repara una semilla que ya se hubiera creado bajo el firmware defectuoso.
El fabricante (Coinkite) comunicó que, en los casos donde las seeds hubieran quedado expuestas, los usuarios debían generar una seed nueva usando el firmware actualizado y migrar sus fondos a la nueva configuración. Además, el análisis advierte con claridad que restaurar la antigua seed sobre el firmware corregido (o incluso moverla a otra cartera) conserva la debilidad en la base que habilita la reproducción de candidatos.
Hasta el momento del reporte, no se describió un caso público donde se hubiera reconstruido una seed de una víctima y se hubiera demostrado correspondencia directa con una dirección drenada; sin embargo, el informe sí sostiene que la debilidad técnica era suficiente para habilitar ese tipo de ataque bajo condiciones específicas.
Qué versiones estuvieron en el camino de riesgo
El fallo de firmware Coldcard no afectó “por igual” a todo el historial de modelos. El reporte acota el problema por versiones y rutas de compilación. Por ejemplo, se indica que para Mk2 y Mk3 no se nombra una versión vulnerable de Mk2, pero el camino vulnerable para ambos modelos incluiría versiones entre 4.0.0 y 4.1.9, con una corrección asociada a 4.2.0.
En general, el fabricante y el análisis citan estas líneas de riesgo:
- Mk2 y Mk3: ruta vulnerable en versiones 4.0.0 a 4.1.9; se fija en 4.2.0 según la lista de Coinkite (el reporte ubica también el rango vulnerable de Mk2 y Mk3 en esa franja).
- Mk4 y Mk5: cualquier versión anterior a 5.6.0.
- Q: cualquier versión anterior a 1.5.0Q.
- Compilaciones “Edge”: antes de 6.6.0X para Mk4 y Mk5, y antes de 6.6.0QX para Q.
Además, el informe enfatiza algo que suele generar confusión: la exposición depende del firmware activo en el momento en que se creó la seed, no del número de versión que esté instalado hoy.
Entropía efectiva y una comparación con BIP-39
La investigación discute el concepto de entropía efectiva atribuible a la generación de seed. Coinkite estimó valores aproximados de entropía efectiva de 40 bits para Mk3, y de alrededor de 72 bits para Mk4, Mk5 y Q. Para ponerlo en contexto, un seed de 12 palabras con BIP-39 se asocia a una expectativa de 128 bits bajo supuestos estándar.
El reporte añade una advertencia: aunque hay cifras, no equivale de manera directa a “seguridad criptográfica equivalente” en todos los escenarios. Además, se menciona que no se publicó una evaluación tipo “benchmark” de fuerza bruta práctica.
Condiciones que cambian el costo del ataque
El “precio” del ataque no sería igual para todas las víctimas. El informe explica que el coste práctico dependería de factores como:
- cuánta información del UID está disponible o puede inferirse;
- el momento de arranque (boot timing);
- cuántas llamadas previas al RNG existían (y su historial);
- y el coste computacional requerido para derivar direcciones desde semillas candidatas.
En las versiones posteriores, el fabricante introdujo la posibilidad de “resembrar” (reseed), lo que incrementaría el número de candidatos que habría que evaluar. Sin embargo, el reporte recalca que lo determinante es el entorno real de cada generación de seed y la información que un atacante consiga acotar.
Qué recomiendan y qué mitiga (o no)
Coinkite señala que una seed creada con al menos 50 tiradas privadas e independientes y justas de dados no estaría en riesgo únicamente por este bug. Pero si no existe certeza sobre el número de tiradas o su privacidad, el consejo es migrar.
También se menciona que una frase de paso BIP-39 fuerte y única crea una cartera separada a la que las palabras de la seed por sí solas no tienen acceso. Aun así, el fabricante recomienda reemplazar la seed incluso en presencia de passphrase, porque el objetivo de mitigación es cortar cualquier vínculo explotable derivado de la semilla base.
Sobre multifirma (multisig), el reporte indica que puede ayudar solo si el quórum no está compuesto enteramente por dispositivos afectados. En cambio, se menciona que productos como TAPSIGNER, OPENDIME y SATSCARD usan bases de código distintas y no estarían afectados por este problema concreto.
Nuevas olas sospechosas y estado de la investigación
Más allá del robo inicial, Galaxy Research identificó dos olas adicionales sospechosas de barridos relacionados con Coldcard. Con esto, su estimación observada aumentó a 1.367,05 BTC, equivalentes a cerca de 88,6 millones de dólares, distribuidos en 4.585 direcciones.
El análisis sugiere que las “Waves 1 y 2” podrían compartir un operador por patrones de transacción similares. Aun así, advierte que la “Wave 3” no debe asumirse automáticamente como la misma entidad, ya que el patrón podría coincidir sin reflejar exactamente el mismo actor.
Galaxy también aclara límites: su evaluación se apoya en análisis on-chain y no confirma computacionalmente que cada dirección identificada se haya generado con entropía débil desde Coldcard. Aun así, reporta que la actividad seguía en curso y que remitieron alrededor de 600 direcciones sospechosas vinculadas a supuestos controles del atacante a investigadores federales, empresas de cumplimiento y especialistas en ciberseguridad.
Contexto: otros informes sobre PRNG débil
Este anuncio se produce después de otra línea de investigación relacionada con PRNG débil en software de carteras antiguas. Coinspect publicó “Ill Bloom” a inicios de julio, un estudio que vinculó una falla en wallets de software con drenajes que superarían los 5 millones de dólares en varias redes (incluyendo Bitcoin, Ethereum, Tron, Rootstock y Polygon).
En otras palabras, el incidente de fallo de firmware Coldcard encaja con un patrón más amplio: cuando la aleatoriedad no se comporta como debería, aumentan las posibilidades de que un adversario reconstruya semillas o reduzca el espacio de búsqueda.
Conclusión: qué hacer para reducir el riesgo
Si usas una wallet de hardware, el mensaje central del reporte es directo: el riesgo se asocia a cómo se generó la seed, no solo a la versión que llevas instalada hoy. Por eso, ante cualquier duda sobre el firmware activo en el momento de creación, la recomendación práctica es clara: migrar a una seed nueva con firmware corregido y desplazar los fondos a la nueva configuración.
El fallo de firmware Coldcard descrito demuestra que, incluso sin “romper” la criptografía de fondo, una mala implementación de aleatoriedad puede abrir la puerta a ataques con impacto real y rápido. Mantenerse al día con las actualizaciones y revisar cómo se construyó tu seed es, en este contexto, la forma más efectiva de proteger tu Bitcoin.
Fuente: https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
