Rastreando al hacker de Coldcard: el ladrón de la ola 1 podría ser conocido por el FBI
Puntos clave
- •La primera ola de los drenajes de Coldcard movió 1,082.65 BTC el 30 de julio de 2026, y esos fondos aún no se han movido desde la dirección del atacante.
- •Block dijo que su investigación vinculó los barridos a una cuenta de pago en un proveedor de servicios blockchain, y que los registros del proveedor coincidieron con el patrón de solicitudes con una precisión extraordinaria.
- •A comienzos de agosto, las pérdidas confirmadas y estimadas de múltiples olas superaban 1,800 BTC en más de 5,000 direcciones, con unos $118 millones confirmados como robados.
- •La vulnerabilidad surgió de un fallo de entropía en la generación de semillas del firmware de Coldcard que afectó a dispositivos tan antiguos como el MK2 con firmware 4.0.1 y posteriores.
- •Los investigadores dicen que algunas olas posteriores muestran comportamientos operativos distintos, lo que sugiere que otros actores podrían haber explotado el mismo espacio de semillas débiles después de la divulgación.

Las fuerzas del orden ya podrían saber quién vació más de 1,000 bitcoin de las carteras Coldcard en la primera y mayor ola de los drenajes de julio de 2026. La investigación de Block indica que rastreó los barridos en cadena del atacante hasta una cuenta de pago en un importante proveedor de datos blockchain, y que los registros internos del proveedor coincidieron con el patrón del robo con “extraordinary specificity”.
PSA: El ataque continúa y está apuntando a claves privadas débiles generadas en dispositivos tan antiguos como el MK2 con firmware 4.0.1 y versiones posteriores. Si crees que podrías tener uno, revísalo y mueve los fondos lo antes posible. Consulta el aviso de Coinkite y la página de estado.
Los fondos de esa primera ola — 1,082.65 BTC — permanecen intactos en la dirección del atacante. Eso deja abierta la posibilidad de que las víctimas recuperen al menos parte de los fondos robados. La pregunta clave ahora es quién es el hacker y si la misma pista apunta a un atacante externo sofisticado o a algo más cercano al “retirement attack” interno sobre el que Coinkite ya había advertido.
Los riesgos van más allá de los propios usuarios de Coldcard. Los dispositivos Coldcard, fabricados por Coinkite, están entre las carteras de hardware más conocidas para mantener bitcoin en autocustodia, con claves privadas generadas y almacenadas fuera de línea en lugar de en servidores conectados a Internet. Un fallo en la aleatoriedad usada para generar esas claves golpea el fundamento mismo de ese modelo.
Lo que sabemos
El 30 de julio de 2026, un atacante comenzó a vaciar sistemáticamente bitcoin de carteras hardware Coldcard que habían generado semillas con firmware vulnerable, un error que pasó desapercibido durante años. La primera y mayor ola movió 1,082.65 BTC. Siguieron olas adicionales, con estimaciones por encima de 2,000 BTC. Alex Thorn, de Galaxy Research, ha seguido la actividad mediante análisis de patrones en cadena e informes voluntarios de víctimas. A comienzos de agosto, las pérdidas confirmadas y estimadas en múltiples olas superaban 1,800 BTC de más de 5,000 direcciones, aunque el total final sigue ajustándose a medida que llegan nuevos reportes. En términos de dólares, se ha confirmado el robo de unos $118 millones.
Thorn ha dicho públicamente que las fuerzas del orden ya podrían tener una pista concreta sobre el operador detrás del tramo más grande. En un segmento de Bitcoin Policy Institute alojado en el canal de YouTube de Bitcoin Magazine, Thorn afirmó: “Wave one’s identity, attacker identity, may be known to law enforcement.” Añadió que Wave 1 sigue siendo el mayor bloque individual identificado hasta ahora, con los fondos aún en la dirección del atacante, y señaló que el patrón de Wave 2 parece lo bastante similar como para que pudiera tratarse del mismo actor. Wave 2 añade otros 76 aproximadamente bitcoin al total.
La principal fuente de la afirmación de que la identidad del hacker podría ser conocida es Clay Garrett, líder de ingeniería en Block y responsable de Bitkey. El 31 de julio de 2026, Garrett publicó los hallazgos de la investigación de Block:
“During our investigation of the Coldcard drain yesterday, we identified an unusual pattern in the sweeps. That pattern led us to a hypothesis that has since been confirmed: the operator used a paid account at a well-known blockchain-services provider to query the source addresses and perform other related activity during the sweeps.”
“We contacted the provider directly. Their internal logs matched the suspected workflow with extraordinary specificity, including the number, timing and sequence of requests. The provider was supplying its standard services in response to requests that did not reveal their broader purpose. We have seen no evidence that the provider knowingly participated in or facilitated the suspected theft.” Garrett said, and added that; “We are sharing the relevant information with the appropriate authorities. We will provide further updates when doing so will not interfere with the investigation.”
Para los investigadores, el hallazgo es importante porque conecta el robo en cadena con una identidad del mundo real: los barridos estaban asociados a una cuenta de pago cuyos registros de solicitudes —el número, el momento y la secuencia de consultas— fueron conservados por el proveedor, creando un rastro fuera de la cadena que Garrett dice que Block está compartiendo ahora con las autoridades correspondientes.
Thorn y otros han señalado que las olas posteriores, más pequeñas, muestran patrones operativos distintos —incluidos drenajes rápidos y oportunistas seguidos de un lavado veloz—, lo que sugiere que actores adicionales podrían haber reconstruido el mismo espacio de semillas débiles después de la divulgación pública inicial. Los drenajes confirmados auto-reportados parecen haberse ralentizado de forma marcada 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 “retirement attack”?
La naturaleza del fallo ha alimentado teorías de conspiración sobre ataques internos, algo que Coinkite ya había discutido públicamente. En octubre de 2021, la cuenta oficial de COLDCARD definió un “retirement attack” como la situación “when the project makers could have a ‘bug’ in the entropy generation for later retrieval.” La publicación sigue disponible aquí.
La vulnerabilidad de 2026 produjo exactamente ese resultado: se generaron semillas con mucha menos entropía de la prevista, dejándolas buscables años después. Algunas personas en el ecosistema de Bitcoin creen ahora que el hack podría haber sido un trabajo interno en Coinkite, mientras que otras discrepan. La evidencia pública sigue siendo demasiado escasa para llegar a una conclusión definitiva, y es probable que no aparezcan más pruebas hasta dentro de años, probablemente solo a través de litigios.
El cambio crítico entró en la base de código el 1 de marzo de 2021, en un commit titulado “First pass w/ libNgU” (b18723dd). Ese commit reemplazó el código restante de criptografía y BIP-39 derivado de Trezor por una nueva biblioteca, libngu, y reconfiguró la generación de semillas. El resultado previsto era que la llamada de aleatoriedad resolviera al verdadero generador aleatorio de hardware del STM32. Sin embargo, el error redirigió la llamada al PRNG de software Yasmarang de MicroPython, provocando un colapso efectivo de la entropía a unas 40 bits en los modelos más antiguos y alrededor de 72 bits en los más nuevos. Eso significaba que las claves privadas de bitcoin generadas eran, en la práctica, adivinables por hardware informático moderno. Para ponerlo en perspectiva, se espera que una semilla de Bitcoin correctamente generada contenga entre 128 y 256 bits de entropía, por lo que una caída a unas 40 bits reduce el espacio de búsqueda del atacante en muchos órdenes de magnitud: la diferencia entre claves prácticamente imposibles de adivinar y claves que pueden enumerarse directamente.
El cambio fue incorporado a la base de código por Doc-Hex, también conocido como Peter Gray, el director técnico de Coinkite.
Según Zach Herbert, director ejecutivo y fundador de Foundation Devices, el movimiento pudo haber estado impulsado por presión de licencias, aunque Coinkite ha negado que la licencia fuera la motivación principal del cambio de código, afirmando: “COLDCARD had to make this change to move to libsecp256k1; the license change is irrelevant to this. libsecp256k1 is the standard library used by Bitcoin Core.”
Coldcard utilizaba código derivado de Trezor bajo la licencia de código abierto GPLv3. Después de que Foundation Devices bifurcara material relacionado, Coinkite buscó trasladar los componentes restantes a un esquema más restrictivo MIT + Commons Clause, que limitaba la reutilización comercial. La reescritura fue amplia y tenía objetivos de ingeniería complejos; esa integración parece haber dejado el fallo silencioso en la ruta de entropía.
El escepticismo sobre la migración lejos de la biblioteca criptográfica de Trezor apareció tan pronto como el 7 de abril de 2021, cuando un miembro del grupo de Telegram de Coinkite escribió: “do we really want to replace the many-years-old TrezorCrypto code that has been heavily scrutinized by white hatters like Johoe and penetration tested by wallet.fail”, añadiendo “switch may be a talented pseudonymous coder, but their commit history sucks.” La crítica, sin embargo, fue insuficiente y quedó rápidamente desestimada por NVK, quien calificó la biblioteca de Trezor como un “shitcoin shitshow.” Irónicamente, compartir esa base de código con el mercado cripto más amplio bajo una licencia abierta significó que la biblioteca criptográfica de Trezor recibió una revisión mucho más profunda de la que jamás obtendría Libngu, incluso años después.
Switch y Peter Gray, alias Doc-Hex
El cambio de bibliotecas criptográficas que introdujo el error fue incorporado por Doc-Hex, CTO de Coinkite, Peter D. Gray. Sustituyó la biblioteca criptográfica Trezor con licencia GPLv3 por Libngu, una base de código poco conocida creada por “Switch”, un seudónimo que, hasta la creación de Libngu, no tenía un historial previo evidente.
La cuenta de Switch apareció por primera vez en X el 3 de agosto de 2019, con una mención a DEFCON, la conferencia internacional de hackers, un evento al que suelen asistir ingenieros de ciberseguridad de todo tipo. El 16 de octubre de 2020, Switch agradeció a Doc-Hex en X haber fusionado su código; “Thanks for merge @DocHex … I’m making yet another bitcoin library. Could be useful on @COLDCARDwallet someday.” Unos días después, Switch publicó un enlace a Libngu, orgulloso de haber construido una “useful thing.”
Sin embargo, aquí es donde la historia se vuelve extraña. Según una investigación del contribuidor de Bitcoin Core James O’Beirne, Switch y Peter D. Gray han firmado commits de código con las mismas claves GPG. O’Beirne demostró mediante firmas GPG de commits que docenas de commits atribuidos a 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 números de teléfono que terminan en los mismos dos dígitos estaban vinculados a las cuentas DocHex y switck en X (post). Otros investigadores señalaron patrones coincidentes de registro DNS.
Ni Gray ni Coinkite han abordado públicamente los hallazgos sobre la firma GPG al momento de escribir esto, y tampoco respondieron cuando se les pidió comentar el tema. La cuenta de Switch sigue activa hasta el día de hoy y ha fusionado cambios de código en Libngu tan recientemente como el 17 de agosto de 2026. Muchas personas en la industria de Bitcoin toman esto como una especie de evidencia indirecta de conducta indebida. ¿Por qué molestarse en crear un nym solo para una biblioteca criptográfica concreta? Eso ha sido tomado como alguna forma de indicio de mala intención; sin embargo, un análisis más profundo sugiere lo contrario. Si Gray realmente hubiera querido perjudicar a los usuarios de Coldcard con este error de RNG, ¿de verdad habría firmado commits con su clave GPG personal? ¿Podría alguien ser tan astuto como para ocultar un error durante años, esperando a que su adopción se extendiera, y al mismo tiempo olvidar crear una firma GPG dedicada para un nym de usar y tirar? No parece encajar.
Es más probable que se tratara de una identidad aleatoria creada en DEFCON por Gray, probablemente en un ataque de paranoia casual. Una identidad que luego siguió usando para ciertos proyectos a lo largo de los años. Después de todo, las identidades seudónimas no son inusuales en los círculos de desarrolladores de Bitcoin. El propio Satoshi sigue siendo el ejemplo más famoso. Y así, por sí sola, esta conexión entre Gray y Switch probablemente no aporte demasiado en la búsqueda del hacker de Coldcard.
Colaboradores de MicroPython
También se ha identificado recientemente a algunos otros desarrolladores de código abierto como personas que tocaron o influyeron en código que desempeñó un papel en el error de RNG de Coldcard.
El analista de datos LaurentMT examinó la parte de MicroPython de la ruta de 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 terminó llamando al respaldo del generador seudorrandom Yasmarang de MicroPython como resultado del error, lo que llevó a una generación de baja entropía.
Los cambios en la lógica del PRNG de MicroPython comenzaron el 20 de agosto de 2020, con el issue (#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() de cierta manera. Mirko esperaba resultados aleatorios. El issue de GitHub registra una discusión durante los meses siguientes sobre la forma correcta de manejar la lógica relacionada y el comportamiento esperado, que Mirko mostró como contraintuitivo.
Laurent señala que “robert-hh initialized a [Pull Request] implementing the PRNG seeding change” el 22 de agosto de 2020. Más tarde, el 29 de octubre de 2020, dpgeorge, mantenedor de MicroPython, fusionó una versión ligeramente modificada de ese pull request en el repositorio principal, implementando “the (UID+SysTick+RTC) to address some limitations in robert-hh’s solution.” Los cambios en este código crítico relacionado con RNG estaban así en el repositorio principal de MicroPython cuando Coldcard lo bifurcó para usarlo en Libngu, pero antes de que MicroPython hubiera publicado una nueva versión oficial de la biblioteca.
Aparentemente, es arriesgado construir sobre la rama principal de un repositorio de software, que probablemente seguirá evolucionando con cambios de código, en lugar de basarse en una versión oficial y estable. La nueva versión de MicroPython no llegó hasta el 3 de febrero de 2021, con la versión v1.14. Incluso entonces, el cambio en la lógica RNG solo se mencionó brevemente en el anuncio de lanzamiento, diciendo “the urandom module will randomize its seed on import on stm32, esp8266, esp32 and rp2 ports.”
En una entrevista con Bitcoin Magazine, Laurent concluyó sin ambigüedades que “without this modification the bug in Coldcard code would have been immediately detected.” Al comentar la serie de acontecimientos que llevaron al error, también dijo que “there are a lot of ‘coincidences’ in this timeline,” y añadió que “while they don’t prove anything, I don’t see how an official investigation may completely ignore them.”
Es importante señalar que no hay evidencia de que ninguno de los desarrolladores mencionados arriba intentara introducir intencionalmente el error de RNG de Coldcard con estos cambios, y en última instancia es Coinkite, la empresa de carteras de hardware, la responsable de la implementación del código crítico. MicroPython es un proyecto de código abierto grande y ampliamente utilizado. No obstante, es probable que haya muchas lecciones que aprender de lo que, por ahora, bien podríamos llamar una trágica comedia de errores.
Por qué parece improbable un trabajo interno
Varios factores se oponen a la idea de un “retirement attack” interno y premeditado. La identidad “switck” estaba mal compartimentada; la clave GPG compartida y otros solapamientos hicieron que atribuirla a Doc-Hex, alias Peter Gray, fuera relativamente sencillo una vez que los investigadores la examinaron. La cuenta había estado prácticamente abandonada durante años. Los colaboradores de MicroPython, por su parte, operan abiertamente en un proyecto de alta visibilidad.
La investigación de Citadel21 de Hodlonaut y otras revisiones técnicas no encuentran evidencia clara de que el fallo de entropía fuera intencional. El informe técnico del ingeniero Alekos Filini deja constancia explícita de que “My goal is to purely present facts and NOT make any conclusions.” Wizardsardine detalló en su autopsia técnica múltiples salvaguardas fallidas y describe el fallo como situado “across a submodule boundary, which is precisely where reviewers stop looking.” El análisis en profundidad de Steven Geller sobre el tema tampoco hizo afirmaciones contundentes en un sentido u otro. La reconstrucción de prueba de concepto de DK27ss describe el problema como “a chain of four flaws, each harmless in appearance.”
Si los drenajes hubieran sido un clásico “retirement attack” interno, o una estafa de largo plazo como algunos la llamarían, la conversación de hoy sería muy distinta. La última gran estafa de largo plazo en la industria de Bitcoin probablemente fue QuadrigaCX, el exchange canadiense centralizado cuyo fundador, Gerald Cotten, fue reportado como “dead in India” en 2018 en circunstancias misteriosas, poco después de descubrirse los fondos desaparecidos. Se acusa a los fundadores, por parte de la Ontario Securities Commission, de haberse apropiado indebidamente de depósitos de usuarios del exchange por un total de casi 170 million CAD, durante muchos años, antes de desaparecer.
En cambio, el liderazgo de Coinkite sigue activo públicamente, respondiendo al incidente, distribuyendo firmware parcheado, ayudando a migrar a los usuarios y participando en los detalles técnicos. Los fundadores y operadores de Coinkite son bastante conocidos y siguen gestionando la empresa al momento de escribir esto; no desaparecieron al mismo tiempo que los fondos.
Mientras tanto, los fondos de la Wave 1, por un total superior a 1000 BTC, siguen agrupados en tres direcciones, vigilados por cientos de ingenieros y probablemente por fuerzas del orden como el FBI. Si Coinkite estuviera intentando un “retirement attack” estilo ajedrez 5D, habría sido mucho más cuidadoso al robar las monedas. No las habría agrupado en un puñado de direcciones fáciles de rastrear, y es probable que sus fundadores estuvieran “misteriosamente muertos en India.” Aunque no hay conclusiones y las investigaciones probablemente continuarán durante años, hasta ahora la evidencia apunta a un fallo cultural en la comunidad maximalista de Bitcoin y de autocustodia, a una falta de educación generalizada sobre la buena o mala etiqueta en la cultura de código abierto y, francamente, a la arrogancia por parte de los OG de Coinkite, que en retrospectiva sobreestimaron sus propias capacidades.
Este artículo Hunting Down the Coldcard Hacker. Wave 1 Thief May Be Known to FBI apareció por primera vez en Bitcoin Magazine y fue escrito por Juan Galt.