El jefe de investigación de Galaxy, Alex Thorn, ha identificado lo que parece ser una cuarta ola organizada de robo de Bitcoin que involucra semillas generadas por el firmware afectado de Coldcard. Durante el período de aproximadamente 2.5 horas entre los bloques 960,778 y 960,792, los investigadores observaron 218 transacciones que involucraban 462 direcciones de víctimas sospechosas, 216 nuevos destinos y 388.92748828 BTC. Se informó que transacciones similares permanecían en el mempool, mientras que las transacciones confirmadas tenían habilitado replace-by-fee (RBF).
La actividad sugiere que la divulgación pública y las actualizaciones de firmware de emergencia no han eliminado el riesgo asociado con las semillas generadas previamente. La tasa de barrido observada alcanzó 13.8 por bloque, en comparación con 0.3 durante una ventana de control previa al incidente, un aumento de aproximadamente 45 veces. Sin embargo, la "cuarta ola" sigue siendo una clasificación de investigación basada en patrones en cadena. La evidencia no identifica de manera concluyente a los atacantes ni prueba que la misma entidad haya llevado a cabo cada ola.
Conclusiones clave
- La sospechosa cuarta ola involucró 218 transacciones, 462 direcciones de víctimas sospechosas, 216 nuevos destinos y 388.92748828 BTC.
- La concentración de actividad y el aumento de aproximadamente 45 veces en la tasa de barrido respaldan la interpretación de explotación sistemática en lugar de una migración de billetera ordinaria.
- Transferencias predominantemente 1:1, reutilización mínima de destinos y movimientos de segundo salto pueden indicar una estrategia de gestión de fondos más dispersa.
- Actualizar el firmware de Coldcard no repara una semilla débil existente; los usuarios potencialmente afectados deben generar una nueva semilla mediante un proceso corregido y migrar sus activos.
¿Qué sucedió durante la sospechosa cuarta ola de ataques?
Según el monitoreo de Thorn, el último grupo de transacciones apareció entre los bloques 960,778 y 960,792 de Bitcoin. Durante aproximadamente 2.5 horas, los investigadores identificaron 218 transacciones que compartían características asociadas con el incidente continuo de Coldcard. Las transacciones involucraron 462 direcciones clasificadas como direcciones de víctimas sospechosas, 216 nuevas direcciones de destino y 388.92748828 BTC. Se informó que transacciones similares aún esperaban confirmación en el mempool, lo que sugiere que la ventana observada puede no representar el final de la actividad.
Las transacciones previamente confirmadas también habilitaron RBF, lo que permite reemplazar una transacción de Bitcoin no confirmada con una versión que paga una tarifa más alta. RBF es una característica normal de la red y no demuestra de manera independiente intención maliciosa. Sin embargo, en el contexto de un barrido masivo en curso, su uso sugiere que quien inició las transacciones estaba gestionando activamente la prioridad de confirmación y podría aumentar las tarifas si aparecían transacciones competidoras.
Las cifras de direcciones y valores informadas requieren una interpretación cuidadosa. Una "dirección de víctima" es una dirección clasificada por los investigadores a través de su comportamiento de transacción y conexión con el límite de firmware relevante de Coldcard; no representa necesariamente a un usuario individual. Una billetera puede controlar múltiples direcciones, y una transacción puede gastar varias entradas. Del mismo modo, los 388.92748828 BTC observados en esta ventana no deben sumarse automáticamente a las estimaciones de pérdidas anteriores hasta que los investigadores confirmen que las direcciones, entradas y fondos transferidos no se superponen con grupos anteriores.
La evidencia más importante es la intensidad y consistencia de la actividad. Los investigadores calcularon 13.8 barridos por bloque durante el período monitoreado, en comparación con 0.3 por bloque en una ventana de control previa al incidente. Un aumento tan pronunciado es difícil de explicar únicamente como usuarios independientes reaccionando a una advertencia de seguridad. Las transacciones también informaron que no contenían entradas anteriores al límite de firmware relevante de Coldcard, lo que refuerza la asociación entre los fondos barridos y las semillas creadas bajo el firmware afectado.
La evaluación de Galaxy se basa, por lo tanto, en el peso combinado del momento, la selección de direcciones, la construcción de transacciones y el comportamiento de los destinos. Ninguna característica individual es concluyente: los usuarios legítimos pueden habilitar RBF, generar nuevas direcciones receptoras o migrar fondos simultáneamente después de una advertencia oficial. La interpretación de ataque organizado se vuelve más persuasiva cuando estas características aparecen con una regularidad inusual en cientos de direcciones vinculadas al firmware.
Sin embargo, el análisis en cadena no puede revelar directamente quién controla las claves privadas. Un atacante podría cambiar las estrategias de transacción entre olas, mientras que varios operadores podrían explotar independientemente la misma debilidad después de que se hiciera pública. Galaxy ha tratado, en consecuencia, los grupos como olas de ataque coordinadas sin afirmar que cada ola haya sido atribuida definitivamente a la misma entidad.
¿Qué revela la nueva topología de transacciones?
La sospechosa cuarta ola mostró una estructura predominantemente 1:1 en la que los fondos de las direcciones de víctimas se enviaban a nuevos destinos separados. Solo un destino recibió dos barridos, y no apareció ninguna dirección de agregación central obvia durante el período de monitoreo inicial. Algunos de los fondos se movieron posteriormente a direcciones de segundo salto.
Esta estructura difiere de las huellas dactilares más claras observadas anteriormente en el incidente. El análisis de Galaxy encontró que las dos primeras olas principales usaron repetidamente tarifas fijas de 30 sat/vB y patrones de agrupación similares, lo que respalda la posibilidad de un operador compartido o una herramienta de ataque. Una ola posterior cambió hacia transferencias individuales y destinos dispersos. En las primeras tres olas identificadas, los informes vinculados a Galaxy situaron la cantidad afectada en 1.367,05 BTC de 4.585 direcciones, al tiempo que enfatizaron que las diferencias en las huellas dactilares de las transacciones impedían una atribución definitiva a un solo atacante.
Una explicación es que un atacante reconoció que las direcciones de recolección centralizadas hacían que las transacciones anteriores fueran más fáciles de agrupar y monitorear, y luego adoptó nuevos destinos y saltos adicionales para reducir la visibilidad inmediata. Otra es que la divulgación de la debilidad permitió a atacantes imitadores buscar semillas vulnerables restantes utilizando herramientas desarrolladas de forma independiente. Ambas interpretaciones son consistentes con los patrones de transacción, pero ninguna puede probarse solo a partir de la topología.
Las transferencias de segundo salto no deben describirse automáticamente como lavado de dinero. Pueden separar la extracción inicial de la custodia a largo plazo, preparar fondos para una consolidación posterior, probar si las direcciones han sido marcadas o enrutar activos hacia servicios externos. Los investigadores deberán determinar si las direcciones de segundo salto eventualmente convergen o interactúan con entidades identificables. En esta etapa, la conclusión defendible es que las últimas transacciones muestran un barrido sistemático combinado con una gestión de fondos cada vez más dispersa.
La evolución de los ataques también cambia el riesgo práctico para los usuarios. Galaxy identificó una ráfaga inicial en la que se barrieron 1.082,65 BTC de 1.196 direcciones en aproximadamente 41 minutos. La actividad posterior se dirigió a direcciones adicionales y saldos más pequeños utilizando estructuras diferentes. Esto puede indicar una transición de extraer rápidamente carteras visibles de alto valor a escanear continuamente la población restante de semillas débiles.
Una campaña de enumeración continua puede revisitar el mismo espacio de semillas vulnerable y apuntar a saldos más pequeños a medida que las herramientas de ataque mejoran o los costos de transacción cambian. La divulgación pública también puede crear una carrera entre los propietarios legítimos que intentan migrar y los atacantes que intentan reconstruir sus claves. Por lo tanto, la supuesta cuarta ola es importante no solo por su valor observado, sino porque indica que las semillas no migradas pueden seguir siendo explotables después de que los robos iniciales más visibles hayan terminado.
La causa raíz técnica: aleatoriedad predecible
El equipo de Ingeniería y Seguridad de Bitcoin de Block rastreó el problema subyacente hasta la integración del firmware de Coldcard con su ruta de generación de números aleatorios. Según Block, una configuración destinada a deshabilitar la implementación de hardware-RNG de MicroPython hizo que una biblioteca externa recurriera al generador de software determinista Yasmarang en lugar del RNG de hardware STM32 esperado. La biblioteca verificaba si existía una macro de configuración, pero no si estaba habilitada.
Para el firmware afectado Mk2 y Mk3, el generador de respaldo podía inicializarse utilizando metadatos del dispositivo y estado de temporización sin recibir entropía criptográficamente segura a través de la ruta vulnerable. Si un atacante pudiera determinar o restringir suficientemente el UID del dispositivo, el estado del temporizador y las llamadas anteriores de números aleatorios, los resultados candidatos podrían potencialmente reproducirse fuera de línea. En dispositivos posteriores, se agregó entrada de elemento seguro, pero Block informó que solo cuatro bytes del resumen resultante llegaron a la función de resiembra, limitando el estado diferenciado de forma segura a no más de (2^{32}) posibilidades bajo los supuestos relevantes.
Pasar una salida aleatoria débil a través de un hash criptográfico no resuelve el problema. Un hash puede hacer que los resultados parezcan distribuidos uniformemente, pero no puede crear más secretos posibles de los que existían en el espacio de entrada original. Un atacante puede enumerar semillas candidatas, derivar sus direcciones de Bitcoin y comparar esas direcciones con la cadena de bloques pública. Una coincidencia proporciona una señal de validación que puede revelar la clave privada correspondiente sin acceso físico a la cartera.
Esto no es una falla del sistema de firmas de Bitcoin ni de los estándares de semillas. La vulnerabilidad se refiere a la aleatoriedad utilizada antes de que se crearan las claves privadas. Una vez que existe una semilla débil, un dispositivo fuera de línea, aislado o físicamente asegurado no puede evitar que otra parte reconstruya el mismo secreto mediante computación.
Block describió su informe como una evaluación técnica temprana publicada mientras la explotación parecía estar activa y señaló que no había completado pruebas empíricas de todas las posibles vías de ataque. Por lo tanto, sus hallazgos deben considerarse junto con la investigación de Coinkite y las conclusiones técnicas finales. Incluso con esa salvedad, el problema de seguridad central es claro: las protecciones aplicadas después de la generación de claves no pueden restaurar la entropía que estaba ausente cuando se creó la semilla.
¿Por qué no basta con actualizar el firmware?
La guía oficial de Coinkite distingue entre prevenir la generación vulnerable de semillas en el futuro y reparar una semilla existente. El firmware corregido cambia cómo se generan nuevos secretos, pero no puede alterar un mnemónico creado bajo una versión afectada. Importar ese mnemónico a un firmware actualizado o a un hardware wallet diferente recrea las mismas claves privadas y preserva el riesgo subyacente. La remediación completa requiere generar una semilla genuinamente nueva mediante un proceso corregido y transferir los fondos en la cadena.
Coinkite identifica como afectadas las semillas Mk2 y Mk3 generadas en versiones de firmware 4.0.1 a 4.1.9. También aconseja migrar las semillas Mk4 y Mk5 creadas antes del firmware estándar 5.6.0 o del firmware Edge 6.6.0X, así como las semillas Coldcard Q creadas antes del firmware estándar 1.5.0Q o del firmware Edge 6.6.0QX. La empresa describe el impacto en Mk4, Mk5 y Q como menos severo que en los dispositivos Mk2 y Mk3 afectados, pero aún serio. Los propietarios de Mk2 y Mk3 pueden generar semillas de reemplazo después de instalar la versión 4.2.0 o posterior.
La entropía genuinamente independiente puede proporcionar excepciones limitadas. Coinkite afirma que al menos 50 tiradas de dados justas, independientes y privadas pueden contribuir con 128 bits de entropía, mientras que 99 o más tiradas contribuyen con aproximadamente 256 bits. Los usuarios que no puedan confirmar con confianza cómo se generaron e incorporaron las tiradas no deben confiar en esta excepción. Una frase de contraseña BIP-39 fuerte puede crear una barrera adicional, pero Coinkite aún recomienda la migración porque la frase de contraseña no repara la semilla original. Un PIN de Coldcard no es una frase de contraseña BIP-39 y no evita que los fondos de la cadena de bloques se muevan si las claves privadas se reconstruyen.
¿Qué deben hacer ahora los usuarios de Coldcard?
Los usuarios potencialmente afectados deben determinar el modelo del dispositivo y la versión de firmware utilizada cuando se generó la semilla actual. La versión actual del firmware por sí sola es insuficiente si la semilla se creó en un Coldcard más antiguo o se importó de otro dispositivo. Las comprobaciones y descargas de firmware deben realizarse solo a través de los canales oficiales de Coinkite, sin seguir enlaces proporcionados por cuentas de soporte no solicitadas, mensajes en redes sociales o servicios de recuperación.
Los usuarios dentro de un rango afectado deben instalar el firmware corregido aplicable y generar una semilla completamente nueva. Deben registrar de forma segura la nueva copia de seguridad, verificar la huella digital de la billetera y la dirección de recepción directamente en la pantalla del hardware, y enviar una pequeña transacción de prueba antes de transferir el saldo restante. Restaurar el mnemónico antiguo en un dispositivo nuevo o continuar usándolo después de una actualización de firmware no resuelve la vulnerabilidad.
El incidente también crea una oportunidad para fraude secundario. Los usuarios nunca deben revelar palabras semilla, claves privadas, frases de contraseña, secuencias de tiradas de dados o copias de seguridad de la billetera a nadie que afirme representar a Coldcard, Coinkite, Galaxy, un intercambio, las autoridades o una empresa de recuperación. El personal de soporte legítimo no necesita estos secretos para verificar el firmware o explicar los procedimientos de migración.
Los usuarios de multisig deben evaluar cuántas claves afectadas participan en el umbral de gasto. Si se pueden reconstruir suficientes claves vulnerables, la protección multisig también puede fallar. Reemplazar claves sin debilitar el umbral o exponer innecesariamente los scripts de la billetera puede requerir una migración más cuidadosamente planificada, especialmente para billeteras de alto valor o administradas institucionalmente.
Implicaciones más amplias para la seguridad de los hardware wallets
El incidente no demuestra que todos los hardware wallets o sistemas de autocustodia sean inseguros. Muestra que la seguridad de la billetera depende de todo el ciclo de vida de la clave: generación de entropía, configuración del firmware, revisión de dependencias, copia de seguridad de la semilla, verificación de transacciones y migración eventual. Etiquetas como "air-gapped", "offline", "open source" o "protegido por elemento seguro" describen defensas individuales en lugar de la seguridad del sistema completo.
El firmware de código abierto permite una revisión independiente pero no garantiza que los errores de implementación se descubran antes de la explotación. Una mayor garantía requiere compilaciones reproducibles, pruebas de entropía, revisión de código a través de los límites de las bibliotecas, vectores de prueba deterministas y un comportamiento de cierre seguro cuando la aleatoriedad segura no está disponible. De lo contrario, una billetera puede continuar recibiendo fondos y firmando transacciones válidas mientras oculta una debilidad que ha existido desde la creación de la semilla.
La lección central es la de la procedencia de la semilla. Mover un mnemónico antiguo a un hardware más nuevo mejora su entorno de almacenamiento pero no cambia su seguridad matemática. Los hardware wallets protegen cómo se almacenan y usan las claves privadas; no pueden hacer retroactivamente impredecible una semilla predecible.
Conclusión
La sospechosa cuarta ola de ataques a Coldcard indica que la ventana de riesgo sigue abierta. El tiempo comprimido, el aumento de aproximadamente 45 veces en la tasa de barrido, el límite de entrada vinculado al firmware y la estructura regular de transacciones respaldan la evaluación de Galaxy de actividad sistemática. Sin embargo, las identidades de los atacantes y la relación entre las diferentes olas siguen sin confirmarse.
Para los usuarios potencialmente afectados, la prioridad es verificar cuándo y cómo se creó su semilla actual. El firmware corregido puede proteger secretos recién generados, pero no puede reparar una semilla débil existente. El remedio efectivo es generar una nueva semilla mediante un proceso corregido y migrar los activos de forma segura.
Aviso de riesgo: Este artículo es solo para fines informativos y no constituye asesoramiento de inversión, legal o de ciberseguridad. Los usuarios deben verificar las versiones de firmware y los procedimientos de migración a través de la documentación oficial de Coinkite y buscar asistencia calificada para configuraciones complejas de billeteras.
