O chefe de pesquisa da Galaxy, Alex Thorn, identificou o que parece ser uma quarta onda organizada de roubo de Bitcoin envolvendo sementes geradas pelo firmware afetado da Coldcard. Durante o período de aproximadamente 2,5 horas entre os blocos 960.778 e 960.792, os pesquisadores observaram 218 transações envolvendo 462 endereços suspeitos de vítimas, 216 novos destinos e 388,92748828 BTC. Transações semelhantes permaneceram na mempool, enquanto as transações confirmadas tinham replace-by-fee (RBF) habilitado.
A atividade sugere que a divulgação pública e as atualizações de firmware de emergência não eliminaram o risco associado às sementes geradas anteriormente. A taxa de varredura observada atingiu 13,8 por bloco, em comparação com 0,3 durante uma janela de controle pré-incidente—um aumento de aproximadamente 45 vezes. No entanto, a "quarta onda" continua sendo uma classificação de pesquisa baseada em padrões on-chain. As evidências não identificam conclusivamente os atacantes nem provam que a mesma entidade conduziu todas as ondas.
Principais Conclusões
- A suspeita quarta onda envolveu 218 transações, 462 endereços suspeitos de vítimas, 216 novos destinos e 388,92748828 BTC.
- A concentração de atividade e o aumento de aproximadamente 45 vezes na taxa de varredura apoiam a interpretação de exploração sistemática, em vez de migração comum de carteiras.
- Transferências predominantemente 1:1, reutilização mínima de destinos e movimentos de segundo salto podem indicar uma estratégia de gestão de fundos mais dispersa.
- Atualizar o firmware da Coldcard não repara uma semente fraca existente; usuários potencialmente afetados devem gerar uma nova semente por meio de um processo corrigido e migrar seus ativos.
O Que Aconteceu Durante a Suspeita Quarta Onda de Ataque?
De acordo com o monitoramento de Thorn, o cluster de transações mais recente apareceu entre os blocos 960.778 e 960.792 do Bitcoin. Ao longo de aproximadamente 2,5 horas, os pesquisadores identificaram 218 transações com características associadas ao incidente contínuo da Coldcard. As transações envolveram 462 endereços classificados como endereços suspeitos de vítimas, 216 novos endereços de destino e 388,92748828 BTC. Transações semelhantes ainda aguardavam confirmação na mempool, sugerindo que a janela observada pode não representar o fim da atividade.
As transações confirmadas anteriormente também habilitaram RBF, que permite que uma transação Bitcoin não confirmada seja substituída por uma versão com taxa mais alta. RBF é um recurso normal da rede e não demonstra intenção maliciosa de forma independente. No contexto de uma varredura em massa em andamento, no entanto, seu uso sugere que quem iniciou as transações estava gerenciando ativamente a prioridade de confirmação e poderia aumentar as taxas se transações concorrentes aparecessem.
Os números de endereços e valores relatados exigem interpretação cuidadosa. Um "endereço de vítima" é um endereço classificado pelos pesquisadores por meio de seu comportamento de transação e conexão com o limite do firmware relevante da Coldcard; não representa necessariamente um usuário individual. Uma carteira pode controlar vários endereços, e uma transação pode gastar várias entradas. Da mesma forma, os 388,92748828 BTC observados nesta janela não devem ser automaticamente adicionados às estimativas de perdas anteriores até que os pesquisadores confirmem que os endereços, entradas e fundos transferidos não se sobrepõem a clusters anteriores.
A evidência mais importante é a intensidade e consistência da atividade. Os pesquisadores calcularam 13,8 varreduras por bloco durante o período monitorado, em comparação com 0,3 por bloco em uma janela de controle pré-incidente. Um aumento tão acentuado é difícil de explicar apenas como usuários independentes reagindo a um aviso de segurança. As transações também não continham entradas anteriores ao limite do firmware relevante da Coldcard, reforçando a associação entre os fundos varridos e as sementes criadas sob firmware afetado.
A avaliação da Galaxy, portanto, baseia-se no peso combinado de tempo, seleção de endereços, construção de transações e comportamento de destino. Nenhuma característica isolada é conclusiva: usuários legítimos podem habilitar RBF, gerar novos endereços de recebimento ou migrar fundos simultaneamente após um aviso oficial. A interpretação de ataque organizado torna-se mais persuasiva quando essas características aparecem com regularidade incomum em centenas de endereços vinculados ao firmware.
No entanto, a análise on-chain não pode revelar diretamente quem controla as chaves privadas. Um atacante poderia mudar as estratégias de transação entre as ondas, enquanto vários operadores poderiam explorar independentemente a mesma fraqueza depois que ela se tornou pública. A Galaxy, consequentemente, tratou os clusters como ondas de ataque coordenadas sem afirmar que cada onda foi definitivamente atribuída à mesma entidade.
O Que a Nova Topologia de Transações Revela?
A suspeita quarta onda exibiu uma estrutura predominantemente 1:1, na qual os fundos dos endereços das vítimas foram enviados para novos destinos separados. Apenas um destino recebeu duas varreduras, e nenhum endereço central de agregação óbvio apareceu durante o período inicial de monitoramento. Alguns dos fundos posteriormente foram movidos para endereços de segundo salto.
Esta estrutura difere das impressões digitais mais claras observadas anteriormente no incidente. A análise da Galaxy descobriu que as duas primeiras grandes ondas usaram repetidamente taxas fixas de 30 sat/vB e padrões de agrupamento semelhantes, apoiando a possibilidade de um operador compartilhado ou ferramenta de ataque. Uma onda posterior mudou para transferências individuais e destinos dispersos. Nas três primeiras ondas identificadas, os relatórios ligados à Galaxy colocaram o valor afetado em 1.367,05 BTC de 4.585 endereços, enfatizando que diferenças nas impressões digitais das transações impediam a atribuição definitiva a um único atacante.
Uma explicação é que um atacante reconheceu que endereços de coleta centralizados tornavam as transações anteriores mais fáceis de agrupar e monitorar, e então adotou novos destinos e saltos adicionais para reduzir a visibilidade imediata. Outra é que a divulgação da fraqueza permitiu que atacantes imitadores procurassem sementes vulneráveis restantes usando ferramentas desenvolvidas independentemente. Ambas as interpretações são consistentes com os padrões de transação, mas nenhuma pode ser comprovada apenas pela topologia.
Transferências de segundo salto não devem ser automaticamente descritas como lavagem de dinheiro. Elas podem separar a extração inicial da custódia de longo prazo, preparar fundos para consolidação posterior, testar se os endereços foram sinalizados ou rotear ativos para serviços externos. Os investigadores precisarão determinar se os endereços de segundo salto eventualmente convergem ou interagem com entidades identificáveis. Nesta fase, a conclusão defensável é que as transações mais recentes mostram varredura sistemática combinada com gestão de fundos cada vez mais dispersa.
A evolução dos ataques também muda o risco prático para os usuários. A Galaxy identificou uma explosão inicial em que 1.082,65 BTC foram varridos de 1.196 endereços em aproximadamente 41 minutos. Atividade posterior visou endereços adicionais e saldos menores usando estruturas diferentes. Isso pode indicar uma transição de extrair rapidamente carteiras visíveis de alto valor para escanear continuamente a população restante de sementes fracas.
Uma campanha contínua de enumeração pode revisitar o mesmo espaço de sementes vulneráveis e visar saldos menores à medida que as ferramentas de ataque melhoram ou os custos de transação mudam. A divulgação pública também pode criar uma corrida entre proprietários legítimos tentando migrar e atacantes tentando reconstruir suas chaves. A suspeita quarta onda é, portanto, importante não apenas pelo seu valor observado, mas porque indica que sementes não migradas podem permanecer exploráveis após os roubos iniciais mais visíveis terem terminado.
A Causa Raiz Técnica: Aleatoriedade Previsível
A equipe de Engenharia e Segurança Bitcoin da Block rastreou o problema subjacente à integração do firmware Coldcard com seu caminho de geração de números aleatórios. De acordo com a Block, uma configuração destinada a desabilitar a implementação de RNG de hardware do MicroPython fez com que uma biblioteca externa recorresse ao gerador de software determinístico Yasmarang em vez do RNG de hardware STM32 esperado. A biblioteca verificava se uma macro de configuração existia, mas não se estava habilitada.
Para firmware Mk2 e Mk3 afetados, o gerador de fallback poderia ser inicializado usando metadados do dispositivo e estado de temporização sem receber entropia criptograficamente segura através do caminho vulnerável. Se um atacante pudesse determinar ou restringir suficientemente o UID do dispositivo, o estado do temporizador e chamadas anteriores de números aleatórios, saídas candidatas poderiam potencialmente ser reproduzidas offline. Em dispositivos posteriores, a entrada do elemento seguro foi adicionada, mas a Block relatou que apenas quatro bytes do digest resultante alcançaram a função de re-semeação, limitando o estado diferenciado com segurança a não mais que (2^{32}) possibilidades sob as suposições relevantes.
Passar saída aleatória fraca por um hash criptográfico não resolve o problema. Um hash pode fazer os resultados parecerem uniformemente distribuídos, mas não pode criar mais segredos possíveis do que existiam no espaço de entrada original. Um atacante pode enumerar sementes candidatas, derivar seus endereços Bitcoin e comparar esses endereços com o blockchain público. Uma correspondência fornece um sinal de validação que pode revelar a chave privada correspondente sem acesso físico à carteira.
Isso não é uma falha do sistema de assinatura do Bitcoin ou dos padrões de semente. A vulnerabilidade diz respeito à aleatoriedade usada antes de as chaves privadas serem criadas. Uma vez que uma semente fraca existe, um dispositivo offline, isolado ou fisicamente seguro não pode impedir que outra parte reconstrua o mesmo segredo por meio de computação.
A Block descreveu seu relatório como uma avaliação técnica inicial publicada enquanto a exploração parecia estar ativa e observou que não havia concluído testes empíricos de todos os possíveis caminhos de ataque. Portanto, suas descobertas devem ser consideradas juntamente com a investigação da Coinkite e as conclusões técnicas finais. Mesmo com essa ressalva, a questão central de segurança é clara: proteções aplicadas após a geração da chave não podem restaurar a entropia que estava ausente quando a semente foi criada.
Por que Atualizar o Firmware Não é Suficiente?
A orientação oficial da Coinkite distingue entre prevenir a geração vulnerável de sementes no futuro e reparar uma semente existente. O firmware corrigido altera como novos segredos são gerados, mas não pode alterar um mnemônico criado sob uma versão afetada. Importar esse mnemônico para um firmware atualizado ou para uma carteira de hardware diferente recria as mesmas chaves privadas e preserva o risco subjacente. A remediação completa requer gerar uma nova semente genuinamente por meio de um processo corrigido e transferir os fundos na cadeia.
A Coinkite identifica sementes Mk2 e Mk3 geradas nas versões de firmware 4.0.1 a 4.1.9 como afetadas. Ela também aconselha a migração para sementes Mk4 e Mk5 criadas antes do firmware padrão 5.6.0 ou do firmware Edge 6.6.0X, bem como sementes Coldcard Q criadas antes do firmware padrão 1.5.0Q ou do firmware Edge 6.6.0QX. A empresa descreve o impacto em Mk4, Mk5 e Q como menos severo do que em dispositivos Mk2 e Mk3 afetados, mas ainda sério. Os proprietários de Mk2 e Mk3 podem gerar sementes substitutas após instalar a versão 4.2.0 ou posterior.
Entropia genuinamente independente pode fornecer exceções limitadas. A Coinkite afirma que pelo menos 50 lançamentos de dados justos, independentes e privados podem contribuir com 128 bits de entropia, enquanto 99 ou mais lançamentos contribuem com aproximadamente 256 bits. Usuários que não podem confirmar com confiança como os lançamentos foram gerados e incorporados não devem confiar nesta exceção. Uma frase-senha BIP-39 forte pode criar uma barreira adicional, mas a Coinkite ainda recomenda a migração porque a frase-senha não repara a semente original. Um PIN Coldcard não é uma frase-senha BIP-39 e não impede que fundos de blockchain sejam movidos se as chaves privadas forem reconstruídas.
O Que os Usuários do Coldcard Devem Fazer Agora?
Usuários potencialmente afetados devem determinar o modelo do dispositivo e a versão do firmware usada quando a semente atual foi originalmente gerada. A versão atual do firmware sozinha é insuficiente se a semente foi criada em um Coldcard mais antigo ou importada de outro dispositivo. Verificações e downloads de firmware devem ser conduzidos apenas por meio dos canais oficiais da Coinkite, sem seguir links fornecidos por contas de suporte não solicitadas, mensagens de mídia social ou serviços de recuperação.
Usuários dentro de uma faixa afetada devem instalar o firmware corrigido aplicável e gerar uma semente totalmente nova. Eles devem registrar com segurança o novo backup, verificar a impressão digital da carteira e o endereço de recebimento diretamente na tela do hardware e enviar uma pequena transação de teste antes de transferir o saldo restante. Restaurar o mnemônico antigo em um novo dispositivo ou continuar a usá-lo após uma atualização de firmware não resolve a vulnerabilidade.
O incidente também cria uma oportunidade para fraude secundária. Os usuários nunca devem divulgar palavras-semente, chaves privadas, frases-senha, sequências de lançamentos de dados ou backups de carteira a qualquer pessoa que alegue representar Coldcard, Coinkite, Galaxy, uma exchange, aplicação da lei ou uma empresa de recuperação. O pessoal de suporte legítimo não precisa desses segredos para verificar o firmware ou explicar procedimentos de migração.
Usuários de multisig devem avaliar quantas chaves afetadas participam do limite de gastos. Se chaves vulneráveis suficientes puderem ser reconstruídas, a proteção multisig também pode falhar. Substituir chaves sem enfraquecer o limite ou expor desnecessariamente scripts de carteira pode exigir uma migração mais cuidadosamente planejada, particularmente para carteiras de alto valor ou gerenciadas institucionalmente.
Implicações Mais Amplas para a Segurança de Carteiras de Hardware
O incidente não demonstra que todas as carteiras de hardware ou sistemas de autocustódia são inseguros. Mostra que a segurança da carteira depende de todo o ciclo de vida da chave: geração de entropia, configuração do firmware, revisão de dependências, backup da semente, verificação de transações e eventual migração. Rótulos como "isolado do ar", "offline", "código aberto" ou "protegido por elemento seguro" descrevem defesas individuais, não a segurança do sistema completo.
O firmware de código aberto permite revisão independente, mas não garante que erros de implementação serão descobertos antes da exploração. Garantia mais forte requer builds reproduzíveis, testes de entropia, revisão de código através de limites de bibliotecas, vetores de teste determinísticos e comportamento de falha fechada quando a aleatoriedade segura não está disponível. Uma carteira pode, de outra forma, continuar recebendo fundos e assinando transações válidas enquanto oculta uma fraqueza que existe desde a criação da semente.
A lição central é a da proveniência da semente. Mover um mnemônico antigo para hardware mais novo melhora seu ambiente de armazenamento, mas não altera sua segurança matemática. As carteiras de hardware protegem como as chaves privadas são armazenadas e usadas; elas não podem retroativamente tornar uma semente previsível imprevisível.
Conclusão
A suspeita quarta onda de ataques ao Coldcard indica que a janela de risco permanece aberta. O tempo comprimido, o aumento de aproximadamente 45 vezes na taxa de varredura, o limite de entrada vinculado ao firmware e a estrutura regular de transações apoiam a avaliação da Galaxy de atividade sistemática. As identidades dos atacantes e a relação entre as diferentes ondas, no entanto, permanecem não confirmadas.
Para usuários potencialmente afetados, a prioridade é verificar quando e como sua seed atual foi criada. Firmware corrigido pode proteger novos segredos gerados, mas não pode reparar uma seed fraca existente. O remédio eficaz é gerar uma nova seed por meio de um processo corrigido e migrar os ativos com segurança.
Aviso de Risco: Este artigo é apenas para fins informativos e não constitui aconselhamento de investimento, jurídico ou de segurança cibernética. Os usuários devem verificar versões de firmware e procedimentos de migração através da documentação oficial da Coinkite e buscar assistência qualificada para configurações complexas de carteira.
