Quarta onda de ataque suspeita da Coldcard: por que razão 462 endereços continuam a ser varridos?

Alex Thorn, chefe de investigação da Galaxy, identificou o que parece ser uma quarta onda organizada de roubo de Bitcoin envolvendo seeds geradas por firmware Coldcard afetado. Durante o período de aproximadamente 2,5 horas entre os blocos 960.778 e 960.792, os investigadores observaram 218 transações envolvendo 462 endereços de vítimas suspeitas, 216 novos destinos e 388,92748828 BTC. Transações semelhantes permaneceram supostamente na mempool, enquanto as transações confirmadas tinham a função replace-by-fee (RBF) ativada.

A atividade sugere que a divulgação pública e as atualizações de emergência do firmware não eliminaram o risco associado às seeds geradas anteriormente. A taxa de varredura observada atingiu 13,8 por bloco, em comparação com 0,3 durante uma janela de controlo pré-incidente — um aumento de aproximadamente 45 vezes. No entanto, “quarta onda” permanece uma classificação de investigação baseada em padrões on-chain. As provas não identificam conclusivamente os atacantes nem provam que a mesma entidade conduziu cada onda.

Principais Conclusões

• A suposta quarta onda envolveu 218 transações, 462 endereços de vítimas suspeitas, 216 novos destinos e 388,92748828 BTC.
• A concentração de atividade e o aumento de aproximadamente 45 vezes na taxa de varredura suportam a interpretação de exploração sistemática em vez de migração comum de carteira.
• 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 Coldcard não repara uma seed fraca existente; os utilizadores potencialmente afetados devem gerar uma nova seed através de um processo corrigido e migrar os seus ativos.

O que aconteceu durante a suposta quarta onda de ataque?

De acordo com o monitoramento de Thorn, o mais recente cluster de transações apareceu entre os blocos Bitcoin 960.778 e 960.792. Ao longo de aproximadamente 2,5 horas, os investigadores identificaram 218 transações que partilhavam características associadas ao incidente Coldcard em curso. As transações envolveram 462 endereços classificados como endereços de vítimas suspeitas, 216 novos endereços de destino e 388,92748828 BTC. Transações semelhantes estavam supostamente ainda à espera de confirmação na mempool, sugerindo que a janela observada pode não representar o fim da atividade.

As transações previamente confirmadas também ativaram o RBF, que permite que uma transação Bitcoin não confirmada seja substituída por uma versão que paga uma taxa mais elevada. O RBF é uma funcionalidade normal da rede e não demonstra independentemente intenção maliciosa. No contexto de uma varredura em massa em curso, no entanto, o seu uso sugere que quem iniciou as transações estava a gerir ativamente a prioridade de confirmação e poderia aumentar as taxas se surgissem transações concorrentes.

Os valores reportados de endereços e valores requerem uma interpretação cuidadosa. Um “endereço de vítima” é um endereço classificado pelos investigadores através do seu comportamento de transação e conexão com o limite relevante do firmware Coldcard; não representa necessariamente um único utilizador individual. Uma carteira pode controlar múltiplos 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 anteriores de perdas até que os investigadores confirmem que os endereços, entradas e fundos transferidos não se sobrepõem com clusters anteriores.

A prova mais importante é a intensidade e consistência da atividade. Os investigadores calcularam 13,8 varreduras por bloco durante o período monitorizado, em comparação com 0,3 por bloco numa janela de controlo pré-incidente. Um aumento tão acentuado é difícil de explicar apenas como utilizadores independentes a reagir a um aviso de segurança. As transações também supostamente não continham entradas anteriores ao limite relevante do firmware Coldcard, reforçando a associação entre os fundos varridos e as seeds criadas sob firmware afetado.

A avaliação da Galaxy baseia-se, portanto, no peso combinado do timing, seleção de endereços, construção de transações e comportamento de destino. Nenhuma característica isolada é conclusiva: utilizadores legítimos podem ativar o RBF, gerar novos endereços de receção ou migrar fundos simultaneamente após um aviso oficial. A interpretação de ataque organizado torna-se mais persuasiva quando estas características aparecem com regularidade incomum em centenas de endereços ligados ao firmware.

No entanto, a análise on-chain não pode revelar diretamente quem controla as chaves privadas. Um atacante poderia alterar estratégias de transação entre ondas, enquanto vários operadores poderiam explorar independentemente a mesma vulnerabilidade após esta se tornar pública. A Galaxy tratou consequentemente os clusters como ondas de ataque coordenadas sem afirmar que cada onda foi definitivamente atribuída à mesma entidade.

O que revela a nova topologia de transações?

A suposta 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 supostamente duas varreduras, e nenhum endereço central de agregação óbvio apareceu durante o período inicial de monitorização. Alguns dos fundos moveram-se subsequentemente 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 codificadas de 30 sat/vB e padrões de loteamento semelhantes, apoiando a possibilidade de um operador partilhado ou ferramenta de ataque. Uma onda posterior mudou para transferências individuais e destinos dispersos. Nas primeiras três ondas identificadas, relatórios ligados à Galaxy situaram o montante afetado em 1.367,05 BTC de 4.585 endereços, enfatizando que as 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 recolha centralizados tornavam as transações anteriores mais fáceis de agrupar e monitorizar, adotando então novos destinos e saltos adicionais para reduzir a visibilidade imediata. Outra é que a divulgação da vulnerabilidade permitiu a atacantes imitadores procurar seeds vulneráveis remanescentes usando ferramentas desenvolvidas independentemente. Ambas as interpretações são consistentes com os padrões de transação, mas nenhuma pode ser provada apenas pela topologia.

As transferências de segundo salto não devem ser automaticamente descritas como lavagem de dinheiro. Podem separar a extração inicial da custódia a longo prazo, preparar fundos para consolidação posterior, testar se os endereços foram sinalizados ou encaminhar ativos para serviços externos. Os investigadores terão de 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 altera o risco prático para os utilizadores. A Galaxy identificou uma explosão inicial na qual 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. Isto pode indicar uma transição da extração rápida de carteiras de alto valor visíveis para a varredura contínua da população restante de seeds fracas.

Uma campanha de enumeração contínua pode revisitar o mesmo espaço de seeds 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 que tentam migrar e atacantes que tentam reconstruir as suas chaves. A suposta quarta onda é, portanto, importante não apenas pelo seu valor observado, mas porque indica que seeds 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 equipa de Engenharia e Segurança Bitcoin da Block rastreou o problema subjacente à integração do firmware Coldcard com o seu caminho de geração de números aleatórios. Segundo a Block, uma configuração destinada a desativar a implementação de hardware-RNG do MicroPython fez com que uma biblioteca externa recorresse ao gerador de software determinístico Yasmarang em vez do esperado RNG de hardware STM32. A biblioteca verificava se existia uma macro de configuração, mas não se estava ativada.

Para o firmware Mk2 e Mk3 afetado, o gerador de fallback podia 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, estado do temporizador e chamadas anteriores de números aleatórios, as saídas candidatas poderiam potencialmente ser reproduzidas offline. Em dispositivos mais recentes, foi adicionada entrada de elemento seguro, mas a Block relatou que apenas quatro bytes do resumo resultante atingiram a função de reseeding, limitando o estado seguramente diferenciado a não mais do que (2^{32}) possibilidades sob as premissas relevantes.

Passar saída aleatória fraca através de um hash criptográfico não resolve o problema. Um hash pode fazer com que os resultados pareçam uniformemente distribuídos, mas não pode criar mais segredos possíveis do que os existentes no espaço de entrada original. Um atacante pode enumerar seeds candidatas, derivar os seus endereços Bitcoin e comparar esses endereços com a blockchain pública. Uma correspondência fornece um sinal de validação que pode revelar a chave privada correspondente sem acesso físico à carteira.

Isto não é uma falha do sistema de assinatura do Bitcoin ou dos padrões de seed. A vulnerabilidade diz respeito à aleatoriedade usada antes da criação das chaves privadas. Uma vez que existe uma seed fraca, um dispositivo offline, air-gapped ou fisicamente seguro não pode impedir que outra parte reconstrua o mesmo segredo através de computação.

A Block descreveu o seu relatório como uma avaliação técnica inicial publicada enquanto a exploração parecia estar ativa e notou que não tinha concluído testes empíricos de todos os caminhos de ataque possíveis. As suas descobertas devem, portanto, ser consideradas juntamente com a investigação da Coinkite e conclusões técnicas finais. Mesmo com essa qualificação, 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 seed foi criada.

Porque é que atualizar o firmware não é suficiente?

A orientação oficial da Coinkite distingue entre prevenir a geração de seeds vulneráveis no futuro e reparar uma seed existente. O firmware corrigido altera a forma 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 firmware atualizado ou uma diferente carteira de hardware recria as mesmas chaves privadas e preserva o risco subjacente. A remediação completa requer a geração de uma seed genuinamente nova através de um processo corrigido e a transferência dos fundos on-chain.

A Coinkite identifica seeds Mk2 e Mk3 geradas em versões de firmware 4.0.1 a 4.1.9 como afetadas. Também aconselha a migração para seeds Mk4 e Mk5 criadas antes do firmware padrão 5.6.0 ou firmware Edge 6.6.0X, bem como seeds Coldcard Q criadas antes do firmware padrão 1.5.0Q ou 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. Proprietários de Mk2 e Mk3 podem gerar seeds de substituição 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. Utilizadores que não possam confirmar com confiança como os lançamentos foram gerados e incorporados não devem depender desta exceção. Uma passphrase BIP-39 forte pode criar uma barreira adicional, mas a Coinkite ainda recomenda a migração porque a passphrase não repara a seed original. Um PIN Coldcard não é uma passphrase BIP-39 e não impede que os fundos da blockchain sejam movidos se as chaves privadas forem reconstruídas.

O que devem fazer os utilizadores Coldcard agora?

Utilizadores potencialmente afetados devem determinar o modelo do dispositivo e a versão do firmware usada quando a seed atual foi originalmente gerada. A versão atual do firmware por si só é insuficiente se a seed foi criada num Coldcard mais antigo ou importada de outro dispositivo. Verificações e downloads de firmware devem ser realizados apenas através dos canais oficiais da Coinkite, sem seguir links fornecidos por contas de suporte não solicitadas, mensagens de redes sociais ou serviços de recuperação.

Utilizadores dentro de um intervalo afetado devem instalar o firmware corrigido aplicável e gerar uma seed totalmente nova. Devem registar seguramente o novo backup, verificar a impressão digital da carteira e o endereço de receção diretamente no ecrã do hardware, e enviar uma pequena transação de teste antes de transferir o saldo restante. Restaurar o antigo mnemónico num 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 utilizadores nunca devem divulgar palavras da seed, chaves privadas, passphrases, sequências de lançamento de dados ou backups de carteira a qualquer pessoa que alegue representar a Coldcard, Coinkite, Galaxy, uma exchange, autoridades policiais ou uma empresa de recuperação. Pessoal de suporte legítimo não precisa destes segredos para verificar o firmware ou explicar procedimentos de migração.

Utilizadores de multisignatura devem avaliar quantas chaves afetadas participam no limiar de gasto. Se chaves vulneráveis suficientes puderem ser reconstruídas, a proteção de multisignatura também pode falhar. Substituir chaves sem enfraquecer o limiar ou expor desnecessariamente scripts da carteira pode exigir uma migração mais cuidadosamente planeada, particularmente para carteiras de alto valor ou geridas 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 sejam inseguros. Mostra que a segurança da carteira depende de todo o ciclo de vida da chave: geração de entropia, configuração de firmware, revisão de dependências, backup da seed, verificação de transações e eventual migração. Rótulos como “air-gapped”, “offline”, “open source” ou “protegido por elemento seguro” descrevem defesas individuais em vez da segurança do sistema completo.

Firmware open source 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 fronteiras de bibliotecas, vetores de teste determinísticos e comportamento fail-closed quando a aleatoriedade segura não está disponível. Caso contrário, uma carteira pode continuar a receber fundos e assinar transações válidas enquanto oculta uma vulnerabilidade que existe desde a criação da seed.

A lição central é a proveniência da seed. Mover um antigo mnemónico para hardware mais novo melhora o seu ambiente de armazenamento, mas não altera a sua segurança matemática. Carteiras de hardware protegem como as chaves privadas são armazenadas e usadas; não podem retroativamente tornar uma seed previsível imprevisível.

Conclusão

A suposta quarta onda de ataque Coldcard indica que a janela de risco permanece aberta. O timing comprimido, o aumento de aproximadamente 45 vezes na taxa de varredura, o limite de entrada ligado ao firmware e a estrutura regular de transações suportam 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 utilizadores potencialmente afetados, a prioridade é verificar quando e como a sua seed atual foi criada. Firmware corrigido pode proteger segredos recém-gerados, mas não pode reparar uma seed fraca existente. O remédio eficaz é gerar uma nova seed através de um processo corrigido e migrar os ativos seguramente.

Aviso de Risco: Este artigo é apenas para fins informativos e não constitui aconselhamento de investimento, legal ou de cibersegurança. Os utilizadores devem verificar as versões de firmware e procedimentos de migração através da documentação oficial da Coinkite e procurar assistência qualificada para configurações complexas de carteira.