Revista Bitcoin
Cazando al Hacker de Coldcard. El Ladrón de la Ola 1 Puede Ser Conocido por el FBI
Las fuerzas del orden pueden ya saber quién vació más de mil Bitcoin de las billeteras Coldcard en la primera y más grande ola de drenajes de julio de 2026. La investigación de Block cree que rastrearon los barridos en cadena del atacante hasta una cuenta paga en un importante proveedor de datos de blockchain cuyos registros internos coincidieron con el patrón de robo con “especificidad extraordinaria.”
PSA: El ataque está en curso, apuntando a claves privadas débiles generadas en dispositivos tan antiguos como el MK2 con firmware 4.0.1 en adelante. Si puedes tener una, verifica y mueve fondos lo antes posible. Consulta el aviso y la página de estado de Coinkite.
Las monedas de esa ola—1,082.65 BTC—siguen sin tocarse en la dirección del atacante, dejando la esperanza de que un reembolso pueda ser posible para las víctimas y los legítimos propietarios de esa primera ola de bitcoin robado. La pregunta ahora es, ¿quién es el hacker y si la misma pista apunta a un extraño sofisticado, o si el error de entropía de cinco años que hizo posible el robo fue algo más cercano al “ataque de retiro” interno del que Coinkite una vez advirtió.
Lo Que Sabemos
El 30 de julio de 2026, un atacante comenzó a drenar sistemáticamente Bitcoin de billeteras de hardware Coldcard que habían generado semillas bajo un firmware vulnerable, un error que no se había descubierto durante años. La primera y mayor ola sola movió 1,082.65 BTC. Olas posteriores siguieron, con estimaciones superiores a 2k BTC. Alex Thorn de Galaxy Research ha rastreado la actividad a través de una combinación de análisis de patrones en la cadena y reportes voluntarios de víctimas. A principios de agosto, las pérdidas confirmadas y estimadas a través de múltiples olas superaron los 1,800 BTC de más de 5,000 direcciones, aunque los totales finales exactos continúan siendo refinados a medida que llegan nuevos informes. En términos de dólares, aproximadamente $118 millones han sido confirmados como robados.
Thorn ha discutido públicamente la posibilidad de que las fuerzas del orden ya tengan una pista concreta sobre el operador detrás de la mayor parte. En un segmento del Instituto de Políticas de Bitcoin presentado en el canal de YouTube de Bitcoin Magazine, Thorn declaró: “La identidad de la ola uno, la identidad del atacante, puede ser conocida por las fuerzas del orden.” Agregó que la Ola 1 sigue siendo el mayor bloque único identificado hasta ahora, con las monedas aún en la dirección del atacante, y señaló que el patrón de la Ola 2 se ve lo suficientemente similar como para que podría involucrar al mismo actor. La Ola 2 añade otros 76 bitcoins al total.
La fuente principal para la afirmación de que la identidad del hacker podría ser conocida es Clay Garrett, líder de ingeniería en Block trabajando en Bitkey. El 31 de julio de 2026, Garrett publicó los hallazgos de la investigación de Block:
“Durante nuestra investigación del drenaje de Coldcard ayer, identificamos un patrón inusual en las barridas. Ese patrón nos llevó a una hipótesis que desde entonces ha sido confirmada: el operador utilizó una cuenta paga en un proveedor de servicios de blockchain bien conocido para consultar las direcciones de origen y realizar otras actividades relacionadas durante las barridas.”
“Contactamos directamente al proveedor. Sus registros internos coincidieron con el flujo de trabajo sospechoso con una especificidad extraordinaria, incluyendo el número, el tiempo y la secuencia de las solicitudes. El proveedor estaba suministrando sus servicios estándar en respuesta a solicitudes que no revelaban su propósito más amplio. No hemos visto evidencia de que el proveedor haya participado o facilitado conscientemente el robo sospechado.” dijo Garrett, y añadió que; “Estamos compartiendo la información relevante con las autoridades apropiadas. Proporcionaremos más actualizaciones cuando hacerlo no interfiera con la investigación.”
Thorn y otros han señalado que más tarde, las olas más pequeñas muestran diferentes patrones operativos—algunos drenajes rápidos y oportunistas seguidos de un rápido lavado—sugiriendo que actores adicionales pueden haber descompuesto el mismo espacio de semillas débiles después de la divulgación pública inicial. Los drenajes confirmados autoinformados parecen haber disminuido drásticamente después del 6 de agosto, aunque muchas semillas potencialmente vulnerables generadas en el firmware afectado entre 2021 y el parche de julio de 2026 siguen en riesgo hasta que los usuarios migren.
¿Un ataque de jubilación?
La naturaleza de la falla ha llevado a teorías de conspiración sobre ataques internos que Coinkite mismo discutió públicamente en una ocasión. En octubre de 2021, la cuenta oficial de COLDCARD definió un “ataque de jubilación” como el escenario “cuando los creadores del proyecto podrían tener un ‘error’ en la generación de entropía para su recuperación posterior.”
El cambio crítico ingresó a la base de código el 1 de marzo de 2021, en un commit titulado “Primera pasada con libNgU” (b18723dd). Ese commit reemplazó la criptografía derivada de Trezor y el código BIP-39 restantes con una nueva biblioteca, libngu, y reconfiguró la generación de semillas. El resultado previsto era que la llamada a la aleatoriedad se resolviera en el generador de números aleatorios verdadero del hardware STM32. Sin embargo, el error redirigió la llamada al PRNG de software Yasmarang de MicroPython, lo que resultó en un colapso efectivo de entropía a aproximadamente 40 bits en modelos más antiguos y alrededor de 72 bits en los más nuevos. Eso significaba que las claves privadas de Bitocin generadas eran efectivamente adivinables por el hardware de computación moderno. Este intercambio de bibliotecas criptográficas fue impulsado en la base de código por Doc-Hex, también conocido como Peter Gray, el Director Técnico de Coinkite.
El movimiento fue impulsado, en parte, por la presión de licencias, según el CEO y fundador de Foundation Devices, Zach Herbert, aunque Coinkite ha negado que esto sea una motivación principal para el cambio de código, diciendo: “COLDCARD tuvo que hacer este cambio para pasar a libsecp256k1; el cambio de licencia es irrelevante para esto. libsecp256k1 es la biblioteca estándar utilizada por Bitcoin Core.”
Coldcard había estado utilizando código derivado de Trezor bajo la licencia de código abierto GPLv3. Después de que Foundation Devices bifurcara material relacionado, Coinkite buscó mover los componentes restantes a un arreglo más restrictivo de MIT + Commons Clause que limitaba la reutilización comercial. La reescritura fue grande y llevó a objetivos de ingeniería complejos; fue esta integración la que, sin duda, dejó la falla silenciosa en la ruta de entropía.
El escepticismo sobre la migración lejos de la biblioteca criptográfica de Trezor surgió tan pronto como el 7 de abril de 2021, por un miembro del grupo de Telegram de Coinkite, quien escribió: “¿realmente queremos reemplazar el código TrezorCrypto de muchos años que ha sido examinado minuciosamente por hackers éticos como Johoe y probado por wallet.fail?”, añadiendo “switch puede ser un talentoso programador seudónimo, pero su historial de commits apesta.” Sin embargo, la crítica fue insuficiente y rápidamente desestimada por NVK, quien criticó la biblioteca de Trezor como un “espectáculo de shitcoin.” Irónicamente, compartir esa base de código con el mercado criptográfico más amplio, bajo una licencia abierta, significaba que la biblioteca criptográfica de Trezor tenía una revisión de código mucho más profunda de lo que Libngu podría obtener, incluso años después.
Switch y Peter Gray alias Doc-Hex
El intercambio de bibliotecas criptográficas que introdujo el error fue impulsado en la base de código por Doc-Hex, el Director Técnico de Coinkite, también conocido como Peter D. Gray. Reemplazó la biblioteca de criptografía Trezor GPLv3 con Libngu, una base de código poco conocida creada por el llamado “Switch”, un seudónimo que, hasta la creación de Libngu, no tenía una historia previa obvia. La cuenta de Switch apareció en X el 3 de agosto de 2019 con una mención de DEFCON, la conferencia internacional de hackers, un evento al que normalmente asisten ingenieros de ciberseguridad de todo tipo.
El 16 de octubre de 2020, Switch agradeció a Doc-Hex en X por fusionar su código; “Gracias por la fusión @DocHex … Estoy creando otra biblioteca de bitcoin. Podría ser útil en @COLDCARDwallet algún día.” Unos días después, Switch tuiteó un enlace a Libngu, orgulloso de haber construido una “cosa útil.”
Sin embargo, aquí es donde se pone raro. Según la investigación del contribuyente principal de Bitcoin, James O’Beirne, Switch y Peter D. Gray han firmado compromisos de código con las mismas claves GPG. O’Beirne demostró a través de las firmas de compromiso GPG que docenas de compromisos autoría como switck fueron firmados con la clave personal de Peter D. Gray, cofundador y CTO de Coinkite, quien también opera como DocHex. Zach Herbert también afirmó que los números de teléfono que terminan en los mismos dos dígitos estaban vinculados a ambas cuentas de X, DocHex y switck (publicación). Investigadores adicionales señalaron patrones de registro de DNS coincidentes.
Ni Gray ni Coinkite han abordado públicamente los hallazgos de la firma GPG hasta el momento de escribir esto, y no respondieron cuando se les pidió comentar sobre el tema. La cuenta de Switch sigue activa hasta el día de hoy, habiendo fusionado cambios de código en Libngu tan recientemente como el 17 de agosto de 2026.
Muchos en la industria de Bitcoin están tomando esto como una especie de evidencia tangencial de mala conducta. ¿Por qué esforzarse en crear un nym solo para una biblioteca de criptografía en particular? Esto se ha tomado como una especie de evidencia de mala intención; sin embargo, un análisis más profundo sugiere lo contrario. Si Gray realmente hubiera tenido la intención de engañar a los usuarios de Coldcard con este error de RNG, ¿realmente habría estado firmando commits con su clave GPG personal? ¿Podría alguien ser tan astuto como para ocultar un error durante años, esperando que su adopción se extendiera; y al mismo tiempo olvidar crear una firma GPG dedicada para el nym desechable? No creo que eso tenga sentido.
Es más probable que esta fuera una identidad aleatoria creada en DEFCON por Gray, probablemente en un ataque de paranoia aleatoria. Una identidad que continuó usando para ciertos proyectos a lo largo de los años. Las identidades seudónimas no son inusuales en los círculos de desarrolladores de Bitcoin, después de todo. Satoshi mismo sigue siendo el ejemplo más famoso. Y así, por sí sola, esta conexión entre Gray y Switch no equivale a mucho en la búsqueda del hacker de Coldcard.
Contribuidores de MicroPython
Un puñado de otros desarrolladores de código abierto también han sido identificados recientemente como aquellos que tocaron o influyeron en el código que jugó un papel en el error del RNG de Coldcard.
El analista de datos LaurentMT ha examinado el lado de MicroPython del camino del RNG. MicroPython es una implementación ligera y de código abierto de Python 3, diseñada para ejecutarse en microcontroladores y computadoras con recursos limitados. El firmware de Coldcard finalmente llamó al generador de números pseudoaleatorios (PRNG) Yasmarang de MicroPython como resultado del error, lo que llevó a una generación de baja entropía.
Los cambios en el código de la lógica del PRNG en MicroPython comenzaron el 20 de agosto de 2020, con el problema (#6347) abierto en GitHub por un usuario llamado ‘mirko’. Se quejó de que su hardware ESP32 siempre devolvía el mismo resultado al llamar a la función ‘random.choice()’ en el código de cierta manera. Mirko esperaba resultados aleatorios en su lugar. El problema de GitHub registra una discusión durante los meses siguientes sobre la forma adecuada de manejar la lógica relacionada y el comportamiento esperado, que Mirko reveló tener un diseño contraintuitivo.
Laurent señala que “robert-hh inicializó una [Solicitud de Extracción] implementando el cambio de siembra del PRNG” el 22 de agosto de 2020. Dpgeorge, un mantenedor de MicroPython, más tarde el 29 de octubre de 2020, fusionó una versión ligeramente modificada de esa solicitud de extracción en el repositorio principal, implementando “el (UID+SysTick+RTC) para abordar algunas limitaciones en la solución de robert-hh.”
Los cambios en este código crítico relacionado con RNG estaban, por lo tanto, en el repositorio principal de MicroPython cuando Coldcard lo bifurcó para ser utilizado por Libngu, pero antes de que MicroPython hiciera un lanzamiento oficial de una nueva versión de la biblioteca. Aparentemente, se considera arriesgado construir sobre la versión maestra de un repositorio de software, que probablemente esté evolucionando con cambios en el código, en lugar de construir sobre una versión oficial y estable. El nuevo lanzamiento de MicroPython no llegó hasta el 3 de febrero de 2021, con la versión v1.14. Para colmo, el cambio en la lógica de RNG solo se mencionó brevemente en el anuncio del lanzamiento, diciendo “el módulo urandom aleatorizará su semilla al importarse en los puertos stm32, esp8266, esp32 y rp2.”
Fuente: BitcoinMagazine
