Carteiras de usuários drenadas por bot cripto da Bloom: o que aconteceu e o que os usuários devem verificar

Usuários do bot cripto da Bloom relataram transferências não autorizadas de carteiras, enquanto a Bloom se comprometeu publicamente a reembolsar os usuários afetados e investigar a causa. A Onchain Lens relatou aproximadamente 9,408 Solana (SOL), avaliados em cerca de $954.000, associados a 49 possíveis vítimas. Separadamente, a resposta da Bloom indexada publicamente identificou nove usuários afetados. Esses números descrevem escopos diferentes de apuração e não devem ser tratados como um total consolidado do incidente.

Em nossa avaliação, a prioridade imediata é proteger os ativos restantes e documentar as perdas — não aceitar uma explicação preliminar como causa definitiva. Um compromisso de reembolso é importante, mas não equivale à compensação concluída. Da mesma forma, desconectar um bot de trading não é uma solução completa se outra pessoa ainda puder autorizar transações pela carteira.

Esta análise reflete as informações disponíveis em 26/10/2026. A investigação continua em andamento, e a causa técnica e o resultado completo dos reembolsos não foram estabelecidos de forma independente durante esta análise.

O que é a Bloom Crypto e qual produto está envolvido?

Neste incidente, “Bloom crypto” se refere ao ecossistema de bots de trading BloomTrading, não simplesmente a qualquer criptomoeda ou carteira que tenha o nome Bloom.

O site da Bloom apresenta três produtos conectados: uma extensão para navegador, o Bloom Manager baseado na web e ferramentas de trading no Telegram. A documentação descreve funções de trading automatizado e gerenciamento de carteiras em várias redes compatíveis. (A automação de trading cross-chain mais avançada)

Essa estrutura de produtos é importante ao investigar a exposição. Alguém que interagiu com uma extensão pode ter um histórico diferente de quem criou uma carteira por meio de um bot ou importou uma carteira existente.

As perguntas relevantes, portanto, são específicas: qual produto você usou? Qual carteira estava envolvida? Que informações ou autoridade você concedeu? Quais transações realmente ocorreram?

Um nome compartilhado não basta para estabelecer que dois produtos estão conectados. Os leitores também devem evitar confundir a BloomTrading com a vulnerabilidade de geração de carteiras chamada “Ill Bloom”. Um nome parecido não demonstra que haja uma causa, um operador ou um conjunto de carteiras afetadas em comum.

O que sabemos sobre as carteiras drenadas da Bloom?

As evidências disponíveis vêm de fontes diferentes, com objetivos distintos. Reclamações de usuários descrevem experiências individuais, contas de monitoramento identificam padrões de transações e a plataforma descreve a própria resposta.

Essas categorias podem se sobrepor sem serem intercambiáveis.

Os números de monitoramento devem continuar atribuídos à Onchain Lens. Este artigo não reconstruiu de forma independente todas as transações nem estabeleceu a propriedade de todos os endereços do grupo relatado.

A distinção é prática. Uma transação pode demonstrar que ativos foram transferidos entre endereços. São necessárias evidências adicionais para estabelecer se uma transferência foi não autorizada, quem controlava os endereços e qual produto ou credencial possibilitou isso.

Da mesma forma, a declaração de uma plataforma pode comprovar o que ela prometeu. Por si só, não demonstra que a promessa foi cumprida.

Por que os relatos mencionam nove usuários e 49 carteiras?

Usuários, carteiras e endereços são unidades de medida diferentes.

A declaração indexada da Bloom se refere a nove usuários afetados. O monitoramento externo menciona um grupo suspeito mais amplo. Seria prematuro apresentar esses dados como duas contagens de clientes diretamente comparáveis.

Uma pessoa pode controlar várias carteiras. Um conjunto de dados de monitoramento também pode conter endereços cuja relação com uma plataforma ainda não foi confirmada.

Considere um exemplo ilustrativo: um trader pode manter uma carteira principal, duas carteiras de trading e outra carteira para estratégias automatizadas. Quatro endereços afetados não representariam necessariamente quatro pessoas afetadas.

O problema inverso também importa. A contagem inicial de usuários confirmados por uma plataforma pode abranger apenas as reclamações que ela analisou. Isso não comprova que todos os endereços de uma investigação externa pertençam a clientes adicionais.

Um relatório de incidente devidamente reconciliado explicaria suas definições e metodologia. Ele distinguiria endereços únicos, contas de clientes, relatos confirmados e casos não resolvidos.

Até lá, dividir uma contagem pela outra para estimar “a porcentagem de vítimas que receberá reembolso” produziria um resultado enganoso. Não foi demonstrado que o numerador e o denominador descrevam o mesmo grupo.

A causa do incidente da Bloom foi confirmada?

A causa técnica definitiva não foi verificada nesta análise.

A resposta pública da Bloom descreve uma investigação em andamento. Reportagens mencionaram possível envolvimento de terceiros, mas uma explicação possível não deve ser apresentada como um mecanismo de ataque comprovado. (x.com)

Várias perguntas continuam em aberto.

Uma transação não autorizada foi assinada com uma chave privada exposta? Um aplicativo ou serviço foi comprometido? Um usuário aprovou uma transação prejudicial? Diferentes usuários foram afetados pelo mesmo mecanismo?

As evidências que apoiam uma possibilidade não eliminam automaticamente as demais. Uma transferência suspeita é o ponto de partida para investigar a autorização, não uma explicação completa.

O que a pesquisa da HashDit sobre a BloomEVM acrescenta?

Uma análise de segurança publicada pela HashDit descreve testes dos fluxos de carteira da BloomEVM. A HashDit relatou que interações de geração e importação de carteiras envolviam a passagem de informações de chaves privadas pela infraestrutura de back-end. Essas são as conclusões da pesquisadora, não testes reproduzidos de forma independente para este artigo.

Esse material acrescenta uma pergunta útil sobre o significado do controle de uma carteira: um serviço ou sua infraestrutura consegue acessar as informações necessárias para autorizar transações?

No entanto, o escopo precisa ficar claro. Uma pesquisa sobre o fluxo de um produto EVM específico não estabelece como ocorreram as transferências de Solana relatadas atualmente. Também não comprova que todas as versões implantadas ou todas as carteiras seguiram um caminho idêntico.

A documentação EVM da própria Bloom descreve a criação e a importação de carteiras, incluindo a obtenção de uma chave privada e de um endereço. Isso confirma a relevância de examinar a arquitetura de gerenciamento de carteiras, mas a documentação, por si só, não esclarece o incidente.

A conclusão apropriada é que o tratamento de chaves merece análise. A conclusão sem fundamento seria afirmar que essa pesquisa já comprovou a causa raiz do incidente atual.

Por que desconectar, revogar permissões e substituir chaves são coisas diferentes?

Essas ações lidam com diferentes formas de acesso. Tratá-las como se fossem intercambiáveis pode deixar um risco importante sem solução.

Desconectar diz respeito à conexão de um aplicativo com uma carteira. Revogar permissões diz respeito à autoridade previamente concedida a um aplicativo ou a outra parte. Substituir chaves comprometidas significa migrar para uma identidade de carteira realmente nova.

As orientações de segurança da Phantom distinguem explicitamente a desconexão de aplicativos da revogação de permissões de gasto. Também recomendam deixar de usar uma carteira quando a frase de recuperação, a chave privada ou o dispositivo puderem ter sido comprometidos.

A forma mais simples de avaliar a situação é perguntar: o que a outra parte ainda poderia fazer sem minha próxima aprovação?

Se a preocupação for a conexão com um aplicativo, desconectar remove essa conexão. Se houver autorização contínua, ela precisa ser analisada separadamente. Se uma chave privada saiu dos limites de segurança previstos, alterar as configurações da interface não elimina a cópia da outra parte.

Esse é um raciocínio geral sobre segurança de carteiras. Ele não estabelece qual situação causou os relatos sobre a Bloom.

O que os usuários da Bloom devem verificar primeiro?

Comece avaliando sua própria exposição, em vez de presumir que todas as pessoas que visitaram um site enfrentam o mesmo risco.

O histórico de exposição de alguém que apenas leu uma página pública é diferente do de quem importou uma chave privada. Uma pessoa que assinou uma transação precisa verificar o que essa transação autorizou.

A sequência a seguir ajuda a organizar a investigação.

1. Identifique quais carteiras foram usadas

Anote os endereços públicos que você usou com o produto e as redes envolvidas.

Diferencie uma carteira criada para trading automatizado de uma carteira existente importada para o serviço. Registre também se você reutilizou essa carteira em outros lugares.

Não inclua frases de recuperação, chaves privadas, senhas ou códigos de autenticação em um chamado de suporte. Endereços públicos ajudam a identificar transações; credenciais secretas permitem controlar a carteira.

2. Verifique o histórico de transações, não apenas o saldo exibido

Uma alteração no saldo pode refletir transferências, trades, taxas ou um problema de exibição no aplicativo. Confira os registros das transações relevantes.

Anote o identificador da transação, o horário, o ativo, o valor e o destino. Guarde os links originais junto com as capturas de tela.

Um registro em um explorador não identifica necessariamente quem controla de fato o endereço de destino. Diferencie “os ativos foram transferidos para este endereço” de “esta pessoa roubou os ativos”.

3. Revise as conexões e as permissões contínuas

Use as orientações oficiais do provedor da sua carteira para verificar os aplicativos conectados e as permissões compatíveis.

As ferramentas e os modelos de autorização variam entre redes. Não presuma que uma instrução para aprovar tokens EVM descreva todos os tipos de autoridade de contas Solana.

A Phantom fornece instruções separadas e específicas para cada rede para revisar permissões em suas orientações sobre carteiras drenadas. Acesse essas ferramentas por meio da documentação verificada, não por mensagens não solicitadas.

4. Avalie se é necessário criar uma nova carteira

Se as credenciais de assinatura ou o próprio dispositivo puderem ter sido comprometidos, uma nova carteira precisa ter chaves realmente novas.

Importar a frase de recuperação antiga para outro aplicativo não cria uma nova identidade de segurança. As orientações de migração da Phantom explicam que, para obter uma nova frase de recuperação, é preciso criar uma nova carteira e transferir os ativos.

Antes da migração, considere os ativos em staking e as posições abertas, além dos saldos que podem ser transferidos livremente. Alguns ativos exigem etapas adicionais.

5. Evite continuar abastecendo uma carteira que perde depósitos imediatamente

Se novos depósitos desaparecem quase imediatamente, pare de fazer depósitos de teste.

A Phantom identifica esse padrão como potencialmente compatível com um bot varredor e alerta para não tentar vencê-lo com transferências repetidas. Este é um alerta geral, não uma conclusão de que um bot varredor operou em todos os casos relatados envolvendo a Bloom.

O que é necessário para um reembolso legítimo da Bloom?

Um compromisso de reembolso deve ser avaliado pelo processo de pagamento, não apenas pela redação de um anúncio.

A Bloom se comprometeu publicamente a reembolsar os usuários. Esta análise não estabeleceu um registro completo que demonstre que todos os usuários afetados receberam compensação.

Ao avaliar futuras atualizações, os leitores devem buscar uma progressão clara:

A tabela é uma estrutura editorial de verificação, não uma alegação de que a Bloom publicou exatamente esse processo.

Um endereço de recebimento substituto pode fazer sentido quando a carteira antiga talvez não seja segura. No entanto, o processo usado para registrar esse endereço também precisa ser autenticado.

Uma conversa legítima com o suporte não deve exigir que você forneça a um atendente a chave privada da carteira substituta. Alguém pode enviar ativos para um endereço público de recebimento sem possuir as credenciais de assinatura correspondentes.

Guarde o registro do endereço que você informou e de como o informou. Isso ajuda a distinguir um erro genuíno de pagamento de uma falsificação de identidade ou alteração do endereço de destino.

Como calcular o valor de um reembolso?

O valor de um reembolso precisa ter uma unidade de referência definida.

O valor em dólares dos ativos roubados relatado corresponde a uma avaliação feita em determinado momento. Isso não é automaticamente o valor que uma plataforma concordou em pagar.

Considere este exemplo hipotético, sem relação com uma solicitação da Bloom verificada:

Um usuário perde 20 unidades de um ativo avaliado em $100 cada. A perda relatada no momento do incidente é de $2.000.

Se o ativo passar a ser negociado por $110 posteriormente, devolver 20 unidades e devolver $2.000 resultam em desfechos diferentes. Não se pode presumir nenhum dos métodos sem conhecer os termos da compensação.

Uma liquidação clara deve especificar se o reembolso se baseia na quantidade do ativo, em um valor em dólares acordado ou em outro método. Também deve indicar se alguma taxa incluída na solicitação será considerada.

Por isso, os usuários afetados devem guardar tanto a quantidade transferida quanto o horário. Uma captura de tela de um saldo em dólares arredondado pode não ser suficiente para reconciliar um pagamento posteriormente.

O mesmo cuidado evita a contagem dupla. Várias transferências de saída podem estar relacionadas a um único evento de perda, enquanto uma transferência posterior pode ser uma tentativa de recuperação ou a movimentação de ativos restantes. Cada registro precisa de contexto.

“Autocustódia” significa automaticamente que um bot de trading não pode acessar os fundos?

Não. O rótulo de custódia informa menos do que o arranjo real de autorização.

O usuário precisa entender como uma carteira é criada, onde ocorre a assinatura, se as credenciais são importadas e que autoridade contínua é concedida ao serviço.

Um produto de automação precisa de algum mecanismo para executar as ações que promete. As questões importantes dizem respeito ao escopo, à duração e à segurança desse mecanismo.

Por exemplo, um sistema que exige aprovação para cada transação oferece controles diferentes dos de um sistema capaz de executar uma estratégia enquanto o usuário está offline. Essa diferença não torna automaticamente nenhum dos sistemas fraudulento. Ela muda o que os usuários precisam verificar.

Uma documentação útil deve explicar o que o operador pode acessar, o que não pode acessar e como essa afirmação é respaldada. Uma frase tranquilizadora em uma página inicial não substitui uma explicação técnica clara.

Essa é a lição mais ampla de examinar a documentação da Bloom junto com as questões de segurança. O controle deve ser avaliado pela autoridade de assinatura, não pela marca.

Como os usuários podem evitar mensagens falsas de reembolso e recuperação?

Um incidente em andamento atrai pessoas que querem ajuda com urgência. Essa urgência pode dificultar uma avaliação tranquila de tentativas de falsificação de identidade.

Trate uma mensagem inesperada que prometa recuperação garantida como uma decisão de segurança separada. Não presuma que conhecer o endereço público da sua carteira prove que o remetente é legítimo.

As orientações de suporte da Phantom afirmam que a equipe de suporte não solicitará frases de recuperação nem chaves privadas. O material de segurança também identifica chats falsos de suporte e solicitações fraudulentas de verificação como métodos usados para obter acesso a carteiras.

Para comunicações que afirmem ser da WEEX, use o Verificador de Contatos da WEEX. Ele permite verificar sites, endereços de e-mail, números de telefone, IDs do Telegram e contas em redes sociais. Ele verifica canais relacionados à WEEX; não valida o processo de reembolso da Bloom. (Verifique contatos e evite golpes)

O Centro de Confiança da WEEX oferece um ponto de partida mais amplo para consultar informações de segurança e recursos de verificação da WEEX.

Nenhum desses recursos reverte uma transação de carteira externa ou determina a elegibilidade para receber compensação de outro serviço.

O que demonstraria que o incidente da Bloom está sendo resolvido?

Uma interface restaurada ou a retomada das negociações não são evidências suficientes de que o problema foi resolvido.

Uma atualização significativa deve conectar três resultados: o grupo afetado foi identificado, a falha de segurança relevante foi corrigida e as perdas aceitas foram reconciliadas com a compensação efetivamente paga.

Uma explicação técnica deve descrever os produtos ou versões afetados e as condições em que ocorreu a exposição. Deve distinguir conclusões confirmadas das hipóteses ainda em aberto.

Uma atualização sobre reembolsos deve explicar o que foi pago e o que continua em análise. Quando registros públicos de transações forem apropriados, eles devem ser compreensíveis sem expor informações pessoais desnecessárias.

Por fim, os usuários precisam saber o que mudou. A disponibilidade do serviço responde a uma questão operacional. Uma alteração documentada no processo vulnerável responde a uma questão de segurança.

Para os leitores que acompanham a história, esses marcos são mais úteis do que uma sequência de declarações cada vez mais categóricas.

Visão editorial da WEEX

A questão mais importante nos relatos sobre o bot cripto da Bloom é a relação entre conveniência e autoridade de assinatura.

Uma interface automatizada pode simplificar o trading e, ao mesmo tempo, tornar mais difícil perceber o arranjo de acesso subjacente. Os usuários precisam de uma descrição precisa desse arranjo para avaliar o risco.

O compromisso de reembolso da Bloom deve ser avaliado pela execução documentada. A investigação técnica deve ser avaliada por uma descrição clara do escopo, da causa e das medidas corretivas. As contagens externas de carteiras devem continuar atribuídas às respectivas fontes e ser definidas com cuidado.

Até que esses elementos sejam reconciliados, a abordagem responsável é proteger os ativos restantes, guardar as evidências das transações e evitar tratar tanto uma acusação preliminar quanto uma garantia inicial como resposta definitiva.

Perguntas frequentes

1. O que aconteceu com o bot cripto da Bloom?

Usuários relataram transferências não autorizadas de carteiras associadas à BloomTrading. O monitoramento da blockchain descreveu saídas suspeitas, enquanto a resposta indexada da Bloom reconheceu usuários afetados e se comprometeu a reembolsá-los durante uma investigação. A causa técnica completa não foi verificada nesta análise. (x.com)

2. Os números de nove usuários e 49 carteiras são contraditórios?

Não necessariamente. Uma pessoa pode controlar várias carteiras, e diferentes relatos podem usar padrões de confirmação distintos. É preciso reconciliar a metodologia antes de comparar diretamente os números.

3. A Bloom concluiu todos os reembolsos?

Esta análise não estabeleceu de forma independente o resultado completo dos reembolsos. É importante distinguir um compromisso de pagamento de solicitações aceitas, registros de pagamento e reconciliação final.

4. Desconectar a Bloom é suficiente para proteger uma carteira?

Não se as credenciais de assinatura tiverem sido comprometidas. Desconectar um aplicativo, remover permissões contínuas e transferir ativos para chaves recém-geradas são medidas para riscos diferentes. Siga as orientações verificadas do provedor da carteira para a exposição relevante.

5. Este incidente prova que a rede Solana foi hackeada?

Não. Relatos de transferências não autorizadas envolvendo uma ferramenta de trading não comprovam, por si só, uma falha da blockchain subjacente. Para determinar a causa, são necessárias evidências sobre como as transações foram autorizadas.

Fontes