La supuesta cuarta ola de ataques de Coldcard: ¿Por qué se siguen barriendo 462 direcciones?

El jefe de investigación de Galaxy, Alex Thorn, ha identificado lo que parece ser una cuarta oleada organizada de robo de Bitcoin que involucra semillas generadas por el firmware afectado de Coldcard. Durante el período aproximado de 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 informa que transacciones similares permanecieron en la mempool, mientras que las transacciones confirmadas tenían habilitada la función 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 a las semillas generadas anteriormente. La tasa de barrido observada alcanzó 13,8 por bloque, en comparación con 0,3 durante una ventana de control previa al incidente, lo que representa un aumento de aproximadamente 45 veces. No obstante, “cuarta oleada” sigue siendo una clasificación de investigación basada en patrones on-chain. La evidencia no identifica de manera concluyente a los atacantes ni prueba que la misma entidad haya llevado a cabo cada oleada.

Puntos clave

• La supuesta cuarta oleada 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 apoyan la interpretación de una explotación sistemática en lugar de una migración ordinaria de billeteras.
• Las transferencias predominantemente 1:1, la mínima reutilización de destinos y los 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é ocurrió durante la supuesta cuarta oleada de ataques?

Según el monitoreo de Thorn, el último clúster de transacciones apareció entre los bloques de Bitcoin 960.778 y 960.792. En 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 informa que transacciones similares aún esperaban confirmación en la mempool, lo que sugiere que la ventana observada puede no representar el final de la actividad.

Las transacciones confirmadas anteriormente también habilitaron RBF, lo que permite que una transacción de Bitcoin no confirmada sea reemplazada por una versión que paga una comisión más alta. RBF es una función normal de la red y no demuestra por sí sola 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 podía aumentar las comisiones si aparecían transacciones competidoras.

Las cifras reportadas de direcciones y valores 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 transaccional y su conexión con el límite relevante del firmware de Coldcard; no necesariamente representa a un usuario individual. Una billetera puede controlar múltiples direcciones, y una transacción puede gastar varias entradas. Asimismo, 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 clústeres 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 que reaccionan a una advertencia de seguridad. También se informa que las transacciones no contenían entradas anteriores al límite relevante del firmware de Coldcard, reforzando la asociación entre los fondos barridos y las semillas creadas bajo el firmware afectado.

Por lo tanto, la evaluación de Galaxy se basa en el peso combinado del timing, la selección de direcciones, la construcción de transacciones y el comportamiento de los destinos. Ninguna característica única es concluyente: los usuarios legítimos pueden habilitar RBF, generar nuevas direcciones de recepción 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 on-chain no puede revelar directamente quién controla las claves privadas. Un atacante podría cambiar las estrategias de transacción entre oleadas, mientras que varios operadores podrían explotar independientemente la misma debilidad después de que se hiciera pública. En consecuencia, Galaxy ha tratado los clústeres como oleadas de ataques coordinados sin afirmar que cada oleada haya sido atribuida definitivamente a la misma entidad.

¿Qué revela la nueva topología de transacciones?

La supuesta cuarta oleada mostró una estructura predominantemente 1:1 en la que los fondos de las direcciones de las víctimas se enviaron a nuevos destinos separados. Solo se informa que un destino recibió dos barridos, y no apareció ninguna dirección central de agregación obvia durante el período inicial de monitoreo. Algunos de los fondos se movieron posteriormente a direcciones de segundo salto.

Esta estructura difiere de las huellas digitales más claras observadas anteriormente en el incidente. El análisis de Galaxy encontró que las dos primeras oleadas principales utilizaron repetidamente comisiones codificadas de 30 sat/vB y patrones de agrupamiento similares, apoyando la posibilidad de un operador compartido o una herramienta de ataque. Una oleada posterior se desplazó hacia transferencias individuales y destinos dispersos. A lo largo de las tres primeras oleadas identificadas, los informes vinculados a Galaxy situaron el monto afectado en 1.367,05 BTC de 4.585 direcciones, enfatizando que las diferencias en las huellas digitales de las transacciones impedían la atribución definitiva a un solo atacante.

Una explicación es que un atacante reconoció que las direcciones de recolección centralizadas facilitaban la agrupación y el monitoreo de transacciones anteriores, 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 independientemente. Ambas interpretaciones son consistentes con los patrones de transacción, pero ninguna puede probarse solo por 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 dirigir activos hacia servicios externos. Los investigadores deberán determinar si las direcciones de segundo salto convergen eventualmente 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ó un brote inicial en el 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 diferentes estructuras. Esto puede indicar una transición desde la extracción rápida de billeteras de alto valor visibles hacia el escaneo continuo de la población restante de semillas débiles.

Una campaña de enumeración continua puede volver a visitar el mismo espacio de semillas vulnerables y apuntar a saldos más pequeños a medida que mejoran las herramientas de ataque o cambian los costos de transacción. 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 oleada es importante no solo por su valor observado, sino porque indica que las semillas no migradas pueden seguir siendo explotables después de que hayan terminado los robos iniciales más visibles.

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 RNG de hardware de MicroPython hizo que una biblioteca externa recurriera al generador de software determinista Yasmarang en lugar del esperado RNG de hardware STM32. La biblioteca verificaba si existía una macro de configuración, pero no si estaba habilitada.

Para el firmware afectado de 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, las salidas candidatas 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 llegaban a la función de reseeding, limitando el estado diferenciado de forma segura a no más de (2^{32}) posibilidades bajo las suposiciones 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 blockchain pública. Una coincidencia proporciona una señal de validación que puede revelar la clave privada correspondiente sin acceso físico a la billetera.

Esto no es un fallo del sistema de firmas de Bitcoin ni de los estándares de semillas. La vulnerabilidad concerne 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 del aire o físicamente asegurado no puede evitar que otra parte reconstruya el mismo secreto mediante cálculo.

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 rutas de ataque posibles. Por lo tanto, sus hallazgos deben considerarse junto con la investigación de Coinkite y las conclusiones técnicas finales. Incluso con esa calificación, el problema central de seguridad 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é actualizar el firmware no es suficiente?

La guía oficial de Coinkite distingue entre prevenir la generación de semillas vulnerables en el futuro y reparar una semilla existente. El firmware corregido cambia cómo se generan nuevos secretos, pero no puede alterar una frase mnemotécnica creada bajo una versión afectada. Importar esa frase mnemotécnica en un firmware actualizado o en una billetera de hardware diferente recrea las mismas claves privadas y preserva el riesgo subyacente. La remediación completa requiere generar una semilla genuinamente nueva a través de un proceso corregido y transferir los fondos on-chain.

Coinkite identifica las semillas Mk2 y Mk3 generadas en versiones de firmware 4.0.1 a 4.1.9 como afectadas. También aconseja la migración para semillas Mk4 y Mk5 creadas antes del firmware estándar 5.6.0 o el firmware Edge 6.6.0X, así como para semillas Coldcard Q creadas antes del firmware estándar 1.5.0Q o el 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 blockchain sean movidos si se reconstruyen las claves privadas.

¿Qué deben hacer ahora los usuarios de Coldcard?

Los usuarios potencialmente afectados deben determinar el modelo del dispositivo y la versión del firmware utilizada cuando se generó originalmente la semilla actual. La versión actual del firmware por sí sola es insuficiente si la semilla se creó en un Coldcard antiguo o se importó desde otro dispositivo. Las verificaciones y descargas de firmware deben realizarse únicamente a través de los canales oficiales de Coinkite, sin seguir enlaces proporcionados por cuentas de soporte no solicitadas, mensajes de 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 la antigua frase mnemotécnica en un nuevo dispositivo o continuar usándola después de una actualización de firmware no resuelve la vulnerabilidad.

El incidente también crea una oportunidad para el fraude secundario. Los usuarios nunca deben divulgar palabras de la 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 exchange, las fuerzas del orden 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 multifirma deben evaluar cuántas claves afectadas participan en el umbral de gasto. Si se pueden reconstruir suficientes claves vulnerables, la protección de multifirma 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, particularmente para billeteras de alto valor o gestionadas institucionalmente.

Implicaciones más amplias para la seguridad de las billeteras de hardware

El incidente no demuestra que todas las billeteras de hardware o los 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 eventual migración. Etiquetas como “aislado del aire”, “fuera de línea”, “código abierto” o “protegido por elemento seguro” describen defensas individuales en lugar de la seguridad del sistema completo.

El firmware de código abierto permite la revisión independiente, pero no garantiza que los errores de implementación se descubran antes de la explotación. Una garantía más sólida 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 comportamiento de fallo cerrado 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 procedencia de la semilla. Mover una antigua frase mnemotécnica a un hardware más nuevo mejora su entorno de almacenamiento, pero no cambia su seguridad matemática. Las billeteras de hardware protegen cómo se almacenan y utilizan las claves privadas; no pueden hacer retroactivamente que una semilla predecible sea impredecible.

Conclusión

La supuesta cuarta oleada de ataques de Coldcard indica que la ventana de riesgo permanece abierta. El timing 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 las transacciones apoyan la evaluación de Galaxy de una actividad sistemática. Sin embargo, las identidades de los atacantes y la relación entre las diferentes oleadas 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 los secretos recién generados, pero no puede reparar una semilla débil existente. El remedio efectivo es generar una nueva semilla a través de un proceso corregido y migrar los activos de forma segura.

Descargo de responsabilidad 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 del 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.