Hack do Coldcard drena US$89 milhões em BTC devido a vulnerabilidade no firmware

O ataque ao Coldcard expôs uma falha crítica em uma das carteiras de hardware mais confiáveis do Bitcoin. Durante três ondas de ataque, os invasores exploraram a geração fraca de seed no firmware afetado e esvaziaram aproximadamente 1.367 BTC, equivalentes a cerca de US$ 89 milhões, de milhares de endereços.

Ao contrário de um golpe de phishing típico ou uma violação de exchange, este ataque visou o processo interno de geração de chaves da carteira. Especificamente, um bug de firmware com cinco anos de idade produziu sementes com aleatoriedade insuficiente, permitindo que atacantes reconstruíssem chaves privadas offline e transferissem os fundos dos usuários. Portanto, este artigo explica como a vulnerabilidade funcionou, quais modelos Coldcard estão em risco e o que os usuários afetados devem fazer a seguir.

Em 30 de julho de 2026, o ataque ao Coldcard começou quando um atacante desconhecido começou a esvaziar bitcoin de carteiras de hardware Coldcard. Durante a primeira onda, 594 BTC, avaliados em aproximadamente US$ 38 milhões, desapareceram de cerca de 500 carteiras em apenas 25 minutos. O atacante alvejou primeiro as carteiras de maior valor. Uma segunda onda aumentou os prejuízos para 1.082 BTC, avaliados em aproximadamente US$ 70 milhões, em 1.196 endereços dentro de 41 minutos. Em 2 de agosto, três ondas de ataque haviam esvaziado um total de 1.367 BTC, avaliados em aproximadamente US$ 89 milhões, de 4.585 endereços.

O atacante não selecionou carteiras aleatoriamente. Segundo a Chainalysis, o operador priorizou os alvos mais ricos e coletou mais de US$ 30 milhões nos primeiros 10 minutos. Uma única carteira perdeu aproximadamente US$ 1,8 milhão. Esse padrão sugere que o atacante já havia identificado endereços valiosos e executou o roubo em uma sequência deliberada.

Enquanto isso, a varredura mais ampla continuou por quase 30 horas antes que a Coinkite publicasse seu primeiro aviso público. A Galaxy Research posteriormente identificou aproximadamente 600 endereços suspeitos de atacantes e os relatou aos investigadores. A empresa de pesquisa também encontrou padrões operacionais semelhantes nas duas primeiras ondas, enquanto a terceira onda utilizou métodos de coleta diferentes.

Mais importante, o ataque ao Coldcard não foi um ataque de phishing, uma violação da exchange ou um caso de alguém roubando fisicamente as chaves privadas dos usuários. O atacante nunca precisou de acesso direto aos dispositivos Coldcard afetados. Em vez disso, as carteiras geraram sementes fracas quando os usuários as inicializaram, permitindo que o atacante reconstruísse as chaves privadas offline.

Essa distinção torna o incidente especialmente grave. Os usuários compraram dispositivos Coldcard para isolar suas chaves de Bitcoin de ameaças online. No entanto, o hardware gerou essas chaves com aleatoriedade insuficiente. Em outras palavras, o produto projetado para proteger os usuários criou a vulnerabilidade por si só. A falha de segurança existia desde o momento em que as carteiras afetadas geraram suas sementes.

Imaginem comprar uma fechadura de alta segurança que promete gerar cada combinação com um verdadeiro randomizador físico. Em vez disso, o fabricante instala uma fórmula previsível que produz combinações a partir de um conjunto limitado de entradas. Uma vez que alguém descobre essa fórmula, pode testar todas as combinações possíveis até encontrar a sua. Essencialmente, foi assim que o ataque ao Coldcard se tornou possível.

Em 1º de março de 2021, um único commit de código alterou a função responsável por gerar as sementes da carteira. Originalmente, ckcc.rng_bytes coletava aleatoriedade genuína do gerador de números aleatórios de hardware integrado ao chip STM32 do dispositivo. No entanto, os desenvolvedores o substituíram por ngu.random.bytes, um gerador de números pseudoaleatórios baseado em software que dependia de entradas determinísticas.

Especificamente, o PRNG do software utilizou o número de série do dispositivo, os valores do temporizador interno e o histórico das chamadas anteriores do RNG. O firmware, em seguida, processou essas entradas com a função criptográfica de hash SHA256d. Embora o hashing possa embaralhar dados existentes, ele não pode criar nova aleatoriedade. Portanto, se o sistema começa com apenas 2^40 entradas possíveis, ainda pode produzir apenas 2^40 saídas possíveis.

Como resultado, os dispositivos Mk3 afetados geraram seeds com aproximadamente 40 bits de entropia. Enquanto isso, os dispositivos Mk4, Mk5 e Q receberam entrada adicional de um elemento seguro, aumentando sua entropia efetiva para cerca de 72 bits. Contudo, ambos os valores permaneceram abaixo do nível de segurança de 128 bits esperado na geração de seeds do bitcoin.

O CEO da Foundation Devices, Zach Herbert, disse que o bug foi introduzido durante uma grande reescrita do firmware em março de 2021, que substituiu o código GPL restante por novas bibliotecas criptográficas. Em outras palavras, a variação fez parte de uma revisão de licenciamento, e não de uma decisão de segurança deliberada.

Mesmo assim, o código com defeito permaneceu ativo por cinco anos. A Coinkite realizou uma auditoria de firmware assistida por IA apenas semanas antes do ataque, mas a revisão não conseguiu identificar o problema. Além disso, múltiplas atualizações de firmware, incluindo lançamentos focados em segurança, também o ignoraram.

Em última análise, a carteira deveria ter usado uma fonte física de aleatoriedade para gerar chaves imprevisíveis. Em vez disso, utilizou uma fórmula limitada e previsível. Uma vez que o atacante compreendeu essa fórmula, pôde começar a reconstruir as sementes dos usuários e realizar o ataque ao Coldcard.

O atacante por trás do ataque ao Coldcard não precisou roubar o dispositivo nem se conectar a ele remotamente. Em vez disso, o atacante pôde estimar variáveis-chave, como o UID do dispositivo, o estado do temporizador e a sequência de chamadas anteriores ao RNG. Com essas restrições, o atacante pôde reproduzir fluxos de saída de seed possíveis totalmente off-line.

Em seguida, o atacante converteu cada semente candidata em endereços Bitcoin e comparou-os com dados públicos da blockchain. Esse processo funciona como testar combinações em um cadeado. Com aproximadamente 40 bits de entropia, as sementes afetadas vieram de um pool de cerca de um trilhão de possibilidades. Embora esse número pareça grande, hardware computacional moderno pode pesquisar esse espaço dentro de um prazo prático, especialmente quando o atacante reduz o conjunto de alvos.

O atacante provavelmente se concentrou em endereços associados a seeds do Coldcard criados durante o período vulnerável de 2021 a 2026. A partir daí, o atacante gerou seeds candidatas, derivou seus respectivos endereços e buscou correspondências na blockchain. Uma vez que uma seed candidata produziu um endereço contendo bitcoin, o atacante obteve controle da chave privada correspondente e transferiu os fundos. Portanto, esse processo de força bruta formou o núcleo do ataque ao Coldcard.

Enquanto isso, a Galaxy Research descobriu que as Ondas 1 e 2 podem compartilhar o mesmo operador. No entanto, a Onda 3 apresentou comportamento diferente na cadeia. Como resultado, outro atacante pode ter descoberto e explorado independentemente a vulnerabilidade.

Os dispositivos Mk4, Mk5 e Q tinham entropia mais forte, de aproximadamente 72 bits. No entanto, ainda ficaram abaixo do padrão esperado de 128 bits. Block descreveu o design como uma “estrutura perigosa com falha aberta” porque certas condições de inicialização podiam reduzir a busca para apenas 2^32 valores possíveis. Os atacantes ainda não exploraram essa fraqueza em larga escala. Mesmo assim, a estrutura restante mostra que os dispositivos afetados não conseguiram fornecer o nível de aleatoriedade que os usuários esperavam de uma carteira de hardware.

O ataque ao Coldcard afeta cada modelo de forma diferente, dependendo da versão do firmware que gerou a semente da carteira. Dispositivos Mk2 e Mk3 enfrentam o maior risco, pois o firmware afetado produziu sementes com apenas cerca de 40 bits de entropia. Enquanto isso, os dispositivos Mk4, Mk5 e Q receberam entropia adicional de um elemento seguro, elevando sua segurança efetiva para cerca de 72 bits. No entanto, esse nível ainda permaneceu abaixo do padrão de 128 bits esperado para a geração de sementes de bitcoin.

Crucialmente, a versão do firmware instalada quando o dispositivo criou a seed determina se o usuário está exposto ao ataque do Coldcard. A versão atual do firmware não altera a segurança de uma seed existente. Por exemplo, um usuário que gerou uma seed em um firmware vulnerável e posteriormente atualizou o dispositivo ainda possui uma seed fraca. A fraqueza existe dentro do número que o dispositivo já gerou. Portanto, uma atualização de firmware protege apenas a geração futura de seeds. Ela não pode corrigir seeds antigas nem tornar seguros os endereços associados a elas.

No entanto, usuários que inseriram pelo menos 50 rolagens de dados independentes e privadas durante a configuração da semente adicionaram uma fonte externa de entropia genuína. Essa aleatoriedade adicional anula a fraqueza no RNG de software do dispositivo. Como resultado, esses usuários enfrentam risco mínimo dessa vulnerabilidade específica. Uma frase de passe BIP-39 forte também torna os ataques de força bruta mais difíceis, mas não fortalece nem corrige a semente subjacente. Consequentemente, a Coinkite ainda recomenda migrar os fundos gerados a partir do firmware afetado.

Finalmente, o ataque ao Coldcard não afeta todas as carteiras de hardware. Trezor, Ledger e Block, que produz o Bitkey, confirmaram que seus produtos utilizam sistemas diferentes de geração de entropia. Portanto, essa falha específica de firmware não afeta as sementes criadas por esses dispositivos.

Após o ataque ao Coldcard, a Coinkite publicou seu primeiro aviso de segurança em 30 de julho e 31 de julho, aproximadamente 30 horas após o início da transferência inicial. A empresa então lançou firmware corrigido para todos os modelos afetados, incluindo v4.2.0 para o Mk3, v5.6.0 para o Mk4 e Mk5, e v1.5.0Q para o Q. Além disso, Coinkite publicou uma análise técnica da vulnerabilidade e forneceu um guia de migração para ajudar os usuários a transferir fundos de sementes fracas.

Além disso, a Coinkite atualizou seu aviso em 1º de agosto para reconhecer que os dispositivos Mk4, Mk5 e Q também enfrentaram entropia reduzida. Embora os atacantes tenham alvejado principalmente sementes Mk2 e Mk3 durante o ataque ao Coldcard, os modelos mais recentes ainda ficaram abaixo do padrão esperado de segurança de 128 bits. Ao divulgar o escopo mais amplo e lançar correções em todas as linhas de produtos afetadas, a Coinkite ofereceu aos usuários um caminho mais claro para proteger seu bitcoin.

No entanto, a resposta também gerou críticas legítimas. O bug permaneceu em produção por cinco anos, apesar de revisões internas, lançamentos de firmware focados em segurança e uma auditoria assistida por IA realizada pouco antes do ataque. Mais importante ainda, a transferência continuou por quase 30 horas antes que a Coinkite emitisse seu primeiro aviso público. Como resultado, os usuários afetados não tinham informações oficiais que poderiam ter ajudado a migrar seus bitcoins antes que o atacante alcançasse suas carteiras.

Enquanto isso, as circunstâncias em torno da alteração original no código levantaram mais perguntas. O CEO da Foundation Devices, Zach Herbert, argumenta que o bug foi introduzido durante uma revisão de licenciamento, e não durante uma reestruturação focada em segurança. Portanto, o incidente provocou escrutínio sobre como a Coinkite gerenciou riscos de segurança durante a reescrita de 2021. Da mesma forma, o pesquisador de segurança Wizardsardine Kevin Loaec diz que os usuários devem considerar configurações multisig contendo chaves do Coldcard afetadas como expostas, um problema que o aviso da Coinkite não aborda totalmente.

Por fim, a Coinkite lançou patches funcionais, detalhes técnicos e instruções de migração após o ataque ao Coldcard se tornar público. No entanto, essas ações não apagam a falha de detecção de cinco anos nem o aviso atrasado que impediu alguns usuários de proteger seus fundos a tempo.

Atualizar o firmware do Coldcard sozinho não irá proteger uma carteira existente. O firmware vulnerável já gerou uma seed fraca, e essa fraqueza permanece incorporada na própria seed. Portanto, os usuários afetados devem criar uma nova seed e transferir seu bitcoin para endereços derivados dela. O aviso da Coinkite e o guia da Shinobi no Bitcoin Magazine recomendam o seguinte processo de migração.

1. Atualize o firmware do seu Coldcard. Instale o firmware mais recente corrigido disponível para o seu modelo específico de Coldcard e a trilha de lançamento. Verifique se você baixou o firmware do site oficial da Coinkite antes de instalá-lo.
2. Gere uma nova semente completamente. Crie a semente no dispositivo atualizado, em vez de importar ou restaurar a antiga. Para maior entropia, considere usar pelo menos 50 rolagens de dados independentes e privadas durante a geração da semente.
3. Verifique o novo backup da seed. Anote as novas palavras da seed na ordem correta e conclua o processo de verificação no dispositivo. Em seguida, gere um endereço de recebimento e confirme se o endereço exibido no software da sua carteira corresponde ao endereço mostrado na tela do Coldcard.
4. Transfera todo o bitcoin para a nova carteira. Envie todos os saldos de BTC controlados pela antiga seed para endereços derivados da nova seed gerada. Verifique cuidadosamente o endereço de destino e os detalhes da transação no Coldcard antes de assinar.
5. Confirme a migração. Use um Explorador de blocos de bitcoin confiável para verificar que as transações foram confirmadas. Em seguida, verifique se os endereços antigos não possuem mais bitcoin e se a nova carteira mostra o saldo transferido completo.
6. Destrua o antigo backup da seed de forma segura. Apenas destrua o backup antigo após todas as transferências terem sido confirmadas e você ter verificado o acesso à nova carteira. Remova todas as cópias físicas e digitais da seed comprometida para que ninguém possa usá-la novamente.

Não atualize o firmware e assuma que a carteira existente se tornou segura. A atualização corrige a geração futura de seed, mas não pode fortalecer um seed que o dispositivo criou anteriormente. Além disso, cada migração exige uma transação Bitcoin na cadeia, portanto os usuários devem considerar as taxas de rede e evitar escolher uma taxa excessivamente baixa durante uma transferência urgente.

Usuários de multisig enfrentam uma complicação adicional. Cada chave derivada de uma semente afetada do Coldcard deve ser substituída. Os usuários devem revisar o limiar de assinatura da carteira, substituir cada chave vulnerável e verificar a nova configuração multisig antes de mover fundos significativos.

A autogestão depende de dois requisitos de segurança distintos. Primeiro, os usuários devem controlar suas chaves privadas. Segundo, as carteiras devem gerar essas chaves com aleatoriedade genuína e de alta qualidade. As empresas de carteiras de hardware tradicionalmente enfatizaram o primeiro requisito, pois apoia o princípio familiar de “não são suas chaves, não são seus coins”. No entanto, elas discutiram muito menos frequentemente o segundo requisito. Como mostra a exploração do Coldcard, os usuários podem controlar plenamente suas chaves e ainda assim perder fundos se o dispositivo gerar essas chaves a partir de entradas previsíveis.

Além disso, este incidente marca a terceira falha significativa de gerador de números pseudoaleatórios na criptomoeda nos últimos anos, seguindo Milk Sad em 2023 e Ill Bloom em 2026. Em cada caso, a falha ocorreu durante a geração da chave, um processo que usuários comuns não podiam verificar independentemente. Uma interface de carteira pode exibir uma frase semente válida e produzir endereços funcionais, enquanto ainda depende de entropia perigosamente fraca por baixo. Consequentemente, os usuários podem não descobrir o problema até que um atacante reconstrua a frase semente e mova os fundos.

Ao mesmo tempo, o incidente complica o debate em torno de carteiras de hardware de código aberto e fechado. A Coldcard disponibiliza publicamente o código-fonte de seu firmware, embora não libere o software sob uma licença permissiva totalmente de código aberto. Desenvolvedores poderiam inspecionar o código vulnerável, mas a falha permaneceu não detectada por cinco anos. Portanto, código público não garante código seguro. Contudo, a disponibilidade do código permanece necessária para uma auditoria comunitária significativa, pois pesquisadores não podem inspecionar software ao qual não têm acesso.

Enquanto isso, a CoinDesk relatou que a exploração pode impulsionar alguns investidores em direção aos Bitcoin ETFs. Os ETFs eliminam os riscos operacionais de gerar, armazenar e proteger chaves privadas. No entanto, os investidores substituem esses riscos pela dependência de um custodiante regulado e instituição financeira. Em outras palavras, o trade-off não elimina o risco de custódia. Em vez disso, transfere a responsabilidade do detentor individual para um provedor institucional.

Finalmente, a Blockaid descobriu que chaves comprometidas e falhas de segurança operacional causaram a maioria das perdas de cripto durante o primeiro semestre de 2026, em vez de explorações de contratos inteligentes. Neste contexto, o incidente da Coldcard se encaixa no padrão mais amplo, pois o atacante alvejou o processo de geração de chaves em vez de explorar o bitcoin diretamente. O armazenamento frio ainda é a escolha certa para a maioria dos detentores de bitcoin a longo prazo. Mas “frio” não significa “infalível”. Confie no princípio. Verifique a implementação.

Este artigo tem finalidades informativas e educacionais apenas e não constitui aconselhamento financeiro, de investimento, legal ou de segurança. Sempre realize sua própria pesquisa antes de tomar decisões relacionadas a criptomoedas.