Drenaje de billeteras de Bloom Crypto Bot: qué pasó y qué deberían revisar los usuarios

Usuarios del bot de criptomonedas Bloom reportaron transferencias no autorizadas desde sus billeteras, mientras que Bloom se comprometió públicamente a reembolsar a los usuarios afectados e investigar la causa. Onchain Lens informó que se drenaron aproximadamente 9,408 Solana (SOL), con un valor estimado de $954.000, y que habría 49 víctimas sospechadas. Por separado, una respuesta de Bloom indexada públicamente identificó a nueve usuarios afectados. Estas cifras corresponden a distintos alcances de los reportes y no deben tomarse como un total consolidado del incidente.

Consideramos que la prioridad inmediata es proteger los activos restantes y documentar las pérdidas, no aceptar una explicación inicial como causa definitiva. Un compromiso de reembolso es importante, pero no equivale a una compensación ya realizada. Del mismo modo, desconectar un bot de trading no es una solución completa si otra persona todavía puede autorizar transacciones desde la billetera.

Este análisis refleja la información disponible al 26/10/2026. La investigación sigue en curso, y durante esta revisión no se verificaron de forma independiente ni la causa técnica ni el resultado completo de los reembolsos.

¿Qué es Bloom Crypto y qué producto está involucrado?

En este incidente, «Bloom crypto» se refiere al ecosistema de bots de trading BloomTrading, no simplemente a cualquier criptomoneda o billetera que lleve el nombre Bloom.

El sitio web de Bloom presenta tres productos conectados: una extensión de navegador, Bloom Manager, que funciona en la web, y herramientas de trading para Telegram. Su documentación describe funciones de trading automatizado y administración de billeteras en varias redes compatibles. (La automatización de trading cross-chain más avanzada)

La estructura de estos productos es importante al investigar una posible exposición. El historial de alguien que interactuó con una extensión puede ser distinto del de quien creó una billetera a través de un bot o importó una billetera existente.

Por eso, las preguntas relevantes son específicas: ¿Qué producto usaste? ¿Qué billetera estuvo involucrada? ¿Qué información o autoridad otorgaste? ¿Qué transacciones se realizaron realmente?

Compartir un nombre no alcanza para demostrar que dos productos están conectados. Los lectores también deberían evitar confundir BloomTrading con la vulnerabilidad de generación de billeteras llamada «Ill Bloom». Un nombre parecido no demuestra que haya una causa, un operador o un grupo de billeteras afectadas en común.

¿Qué sabemos sobre el drenaje de billeteras de Bloom?

La evidencia disponible proviene de distintas fuentes que cumplen funciones diferentes. Las quejas de usuarios describen experiencias individuales, las cuentas de monitoreo identifican patrones de transacciones y la plataforma describe su propia respuesta.

Estas categorías pueden superponerse, pero no son intercambiables.

Las cifras de monitoreo deben seguir atribuyéndose a Onchain Lens. Este artículo no reconstruyó de forma independiente todas las transacciones ni determinó quién es dueño de cada dirección del grupo reportado.

La distinción es práctica. Una transacción puede demostrar que los activos se movieron entre direcciones. Para determinar si una transferencia fue no autorizada, quién controlaba las direcciones y qué producto o credencial lo permitió, se necesitan pruebas adicionales.

Del mismo modo, la declaración de una plataforma puede confirmar lo que prometió. Por sí sola, no demuestra que haya cumplido la promesa.

¿Por qué los informes mencionan a nueve usuarios y 49 billeteras?

Usuarios, billeteras y direcciones son unidades de medida distintas.

La declaración de Bloom indexada se refiere a nueve usuarios afectados. El monitoreo externo menciona un grupo sospechado más amplio. Sería prematuro presentar estas cifras como dos conteos de clientes directamente comparables.

Una persona puede controlar varias billeteras. Además, un conjunto de datos de monitoreo puede incluir direcciones cuya relación con una plataforma todavía no se confirmó.

Veamos un ejemplo ilustrativo: un trader podría tener una billetera principal, dos billeteras de trading y otra billetera para estrategias automatizadas. Cuatro direcciones afectadas no necesariamente representarían a cuatro personas.

También importa el problema inverso. El conteo inicial de usuarios confirmados de una plataforma podría incluir únicamente los reportes que revisó. Eso no demuestra que cada dirección de una investigación externa pertenezca a un cliente adicional.

Un informe de incidente debidamente consolidado explicaría sus definiciones y metodología. Distinguiría entre direcciones únicas, cuentas de clientes, reportes confirmados y casos sin resolver.

Hasta entonces, dividir una cifra por otra para estimar «el porcentaje de víctimas que recibe un reembolso» daría un resultado engañoso. No se demostró que el numerador y el denominador describan a la misma población.

¿Se confirmó la causa del incidente de Bloom?

En esta revisión no se verificó una causa técnica definitiva.

La respuesta pública de Bloom describe una investigación en curso. Algunos informes mencionaron una posible participación de terceros, pero una explicación posible no debe presentarse como un mecanismo de ataque confirmado. (x.com)

Quedan varias preguntas por responder.

¿Se firmó una transacción no autorizada con una clave privada expuesta? ¿Se comprometió una aplicación o un servicio? ¿Un usuario aprobó una transacción dañina? ¿Varios usuarios fueron afectados por el mismo mecanismo?

La evidencia que respalda una posibilidad no descarta automáticamente las demás. Una transferencia sospechosa es el punto de partida para investigar la autorización, no una explicación completa.

¿Qué aporta la investigación de HashDit sobre BloomEVM?

Un análisis de seguridad publicado por HashDit describe pruebas de los flujos de billetera de BloomEVM. HashDit informó que las interacciones de generación e importación de billeteras implicaban que información de claves privadas pasara por la infraestructura de backend. Esos son los hallazgos de los investigadores; este artículo no reprodujo las pruebas de forma independiente.

Este material plantea una pregunta útil sobre qué significa controlar una billetera: ¿Puede un servicio o su infraestructura acceder a la información necesaria para autorizar transacciones?

Sin embargo, es importante dejar claro su alcance. La investigación sobre un flujo específico de un producto EVM no demuestra cómo se produjeron las transferencias de Solana reportadas recientemente. Tampoco prueba que todas las versiones implementadas o todas las billeteras hayan seguido el mismo proceso.

La documentación de Bloom sobre EVM describe cómo crear e importar billeteras, incluida la obtención de una clave privada y una dirección. Eso confirma que es relevante analizar la arquitectura de administración de billeteras, pero la documentación por sí sola no permite resolver el incidente.

La conclusión adecuada es que el manejo de claves merece atención. Una conclusión sin respaldo sería afirmar que esta investigación ya probó la causa raíz del incidente actual.

¿Por qué desconectar, revocar permisos y reemplazar claves son acciones distintas?

Estas acciones abordan formas de acceso diferentes. Tratarlas como si fueran intercambiables puede dejar un riesgo importante sin resolver.

Desconectar se refiere a la conexión de una aplicación con una billetera. Revocar permisos se refiere a la autoridad que se le otorgó previamente a una aplicación u otra parte. Reemplazar claves comprometidas significa pasar a una identidad de billetera realmente nueva.

Las recomendaciones de seguridad de Phantom distinguen explícitamente entre desconectar aplicaciones y revocar permisos de gasto. También aconsejan dejar de usar una billetera si es posible que se hayan comprometido su frase de recuperación, su clave privada o el dispositivo.

La forma más sencilla de comprobarlo es preguntarse: ¿Qué podría hacer la otra parte todavía sin mi próxima aprobación?

Si el problema es la conexión de una aplicación, desconectarla resuelve esa conexión. Si existe una autorización vigente, hay que revisarla por separado. Si una clave privada salió del límite de seguridad previsto, cambiar la configuración de la interfaz no elimina la copia que tiene la otra parte.

Este es un razonamiento general sobre la seguridad de las billeteras. No demuestra cuál de estas situaciones causó los reportes sobre Bloom.

¿Qué deberían revisar primero los usuarios de Bloom?

Empezá por determinar tu propia exposición, en vez de suponer que todas las personas que visitaron un sitio web enfrentan el mismo riesgo.

La exposición de un usuario que solo leyó una página pública es distinta de la de alguien que importó una clave privada. Quien firmó una transacción debe revisar qué autorizó.

La siguiente secuencia ayuda a organizar la investigación.

1. Identificá qué billeteras usaste

Anotá las direcciones públicas que usaste con el producto y las redes involucradas.

Diferenciá una billetera creada para trading automatizado de una billetera existente que importaste al servicio. También anotá si reutilizaste esa billetera en otros lugares.

No incluyas frases de recuperación, claves privadas, contraseñas ni códigos de autenticación en un ticket de soporte. Las direcciones públicas ayudan a identificar transacciones; las credenciales secretas permiten tomar el control.

2. Revisá el historial de transacciones, no solo el saldo que aparece

Un cambio en el saldo puede deberse a transferencias, operaciones de trading, comisiones o un problema de visualización en la aplicación. Revisá los registros de las transacciones correspondientes.

Anotá el identificador de la transacción, la hora, el activo, el monto y el destino. Guardá los enlaces originales junto con las capturas de pantalla.

El registro de un explorador no necesariamente identifica quién controla en la vida real una dirección de destino. Diferenciá entre «los activos se movieron a esta dirección» y «esta persona robó los activos».

3. Revisá las conexiones y los permisos vigentes

Usá las instrucciones oficiales de tu proveedor de billetera para revisar las aplicaciones conectadas y los permisos compatibles.

Las herramientas y los modelos de autorización varían según la red. No supongas que una instrucción para aprobar tokens en EVM sirve para todos los tipos de autoridad de cuentas de Solana.

Phantom ofrece instrucciones específicas para revisar permisos por red en sus recomendaciones sobre el drenaje de billeteras. Accedé a estas herramientas a través de documentación verificada, no desde un mensaje que no solicitaste.

4. Evaluá si necesitás una billetera nueva

Si es posible que se hayan comprometido las credenciales de firma o el dispositivo, la nueva billetera debe tener claves realmente nuevas.

Importar la frase de recuperación anterior en otra aplicación no crea una nueva identidad de seguridad. Las instrucciones de migración de Phantom explican que, para obtener una frase de recuperación nueva, hay que crear una billetera nueva y transferir los activos.

Antes de migrar, tené en cuenta tanto los activos en staking y las posiciones abiertas como los saldos que se pueden transferir libremente. Algunas tenencias requieren pasos adicionales.

5. Evitá volver a cargar fondos en una billetera de la que desaparecen enseguida

Si los nuevos depósitos desaparecen casi de inmediato, dejá de hacer depósitos de prueba.

Phantom señala que este patrón podría ser compatible con la actividad de un bot drenador y advierte que no hay que intentar ganarle con transferencias repetidas. Es una advertencia general, no una conclusión de que un bot drenador haya operado en todos los casos reportados de Bloom.

¿Qué hace falta para que un reembolso de Bloom sea genuino?

Un compromiso de reembolso debe evaluarse a través de un proceso de pago, no solo por las palabras de un anuncio.

Bloom se comprometió públicamente a reembolsar a los usuarios. Esta revisión no estableció un registro completo que demuestre que todos los usuarios afectados recibieron una compensación.

Al evaluar futuras actualizaciones, los lectores deberían buscar una progresión clara:

La tabla es un marco editorial de verificación, no una afirmación de que Bloom haya publicado este proceso exacto.

Usar una dirección nueva para recibir fondos puede tener sentido si la billetera anterior podría no ser segura. Sin embargo, también hay que autenticar el proceso utilizado para registrar esa dirección.

Una conversación de soporte genuina no debería requerir que le des a un agente la clave privada de la billetera nueva. Alguien puede enviar activos a una dirección pública receptora sin tener sus credenciales de firma.

Guardá el registro de la dirección que enviaste y de cómo la enviaste. Eso ayuda a distinguir un error real de pago de una suplantación o de un destino modificado.

¿Cómo se debería calcular el monto de un reembolso?

El monto de un reembolso necesita una unidad de cuenta definida.

El valor en dólares reportado para los activos robados es una valuación hecha en un momento determinado. No equivale automáticamente al monto que una plataforma aceptó pagar.

Considerá este ejemplo hipotético, que no está relacionado con un reclamo verificado de Bloom:

Un usuario pierde 20 unidades de un activo valuado en $100 cada una. La pérdida reportada al momento del incidente es de $2.000.

Si después el activo cotiza a $110, devolver 20 unidades y devolver $2.000 generan resultados distintos. No se puede suponer ninguno de los dos métodos sin conocer las condiciones de compensación.

Un acuerdo claro debería especificar si el reembolso se basa en la cantidad de activos, en una valuación en dólares acordada o en otro método. También debería indicar si se incluyen las comisiones del reclamo.

Por eso, los usuarios afectados deberían guardar tanto la cantidad transferida como la fecha y hora. Una captura de pantalla de un saldo en dólares redondeado podría no ser suficiente para conciliar un pago más adelante.

El mismo nivel de cuidado evita contar pérdidas dos veces. Varias transferencias salientes pueden corresponder a un solo evento de pérdida, mientras que una transferencia posterior podría ser un intento de recuperar fondos o de mover los activos restantes. Cada registro necesita contexto.

¿«Autocustodia» significa automáticamente que un bot de trading no puede acceder a los fondos?

No. La etiqueta de custodia dice menos que el mecanismo de autorización real.

El usuario necesita entender cómo se crea una billetera, dónde se realiza la firma, si se importan credenciales y qué autoridad vigente recibe el servicio.

Un producto de automatización necesita algún mecanismo para ejecutar las acciones que promete. Las preguntas importantes tienen que ver con el alcance, la duración y la seguridad de ese mecanismo.

Por ejemplo, un sistema que requiere aprobar cada transacción tiene controles distintos de uno que puede ejecutar una estrategia mientras el usuario está desconectado. Esa diferencia no convierte automáticamente a ninguno de los dos sistemas en fraudulento. Cambia lo que los usuarios deben verificar.

La documentación útil debería explicar a qué puede acceder el operador, a qué no puede acceder y cómo se respalda esa afirmación. Una frase tranquilizadora en una página de inicio no reemplaza una explicación técnica clara.

Esta es la enseñanza más amplia que surge de analizar la documentación de Bloom junto con las preguntas de seguridad. El control debe evaluarse a través de la autoridad de firma, no de la marca.

¿Cómo pueden los usuarios evitar mensajes falsos de reembolso y recuperación?

Un incidente en desarrollo crea una audiencia que busca ayuda con urgencia. Esa urgencia puede hacer que sea más difícil evaluar con calma los intentos de suplantación.

Considerá como una decisión de seguridad aparte cualquier mensaje inesperado que ofrezca una recuperación garantizada. No supongas que conocer la dirección pública de tu billetera demuestra que el remitente es legítimo.

Las instrucciones de soporte de Phantom indican que su equipo de soporte no pide frases de recuperación ni claves privadas. Su material de seguridad también identifica los chats falsos de soporte y las solicitudes fraudulentas de verificación como métodos para obtener acceso a billeteras.

Si alguien afirma comunicarse desde WEEX, usá el Verificador de contactos de WEEX. Permite comprobar sitios web, direcciones de correo electrónico, números de teléfono, ID de Telegram y cuentas de redes sociales. Verifica canales relacionados con WEEX; no valida el proceso de reembolso de Bloom. (Verificá contactos y evitá estafas)

El Centro de confianza de WEEX ofrece un punto de partida más amplio para consultar información de seguridad y recursos de verificación de WEEX.

Ninguno de estos recursos revierte una transacción externa de billetera ni determina si corresponde recibir una compensación de otro servicio.

¿Qué demostraría que el incidente de Bloom se está resolviendo?

Que se restablezca la interfaz o se reanude el trading no es suficiente para demostrar que el problema se resolvió.

Una actualización significativa debería vincular tres resultados: se identificó a la población afectada, se corrigió la falla de seguridad relevante y las pérdidas aceptadas se conciliaron con la compensación efectivamente pagada.

Una explicación técnica debería describir los productos o las versiones afectados y las condiciones en las que se produjo la exposición. También debería diferenciar los hallazgos confirmados de las hipótesis pendientes.

Una actualización sobre los reembolsos debería explicar qué se pagó y qué sigue en revisión. Cuando sea apropiado incluir registros públicos de transacciones, deberían ser comprensibles sin exponer información personal innecesaria.

Por último, los usuarios necesitan saber qué cambió. Que el servicio vuelva a estar disponible responde una pregunta operativa. Un cambio documentado en el proceso vulnerable responde una pregunta de seguridad.

Para quienes siguen la historia, estos hitos son más útiles que una sucesión de declaraciones cada vez más contundentes.

La perspectiva editorial de WEEX

El tema más importante en los reportes sobre el bot de criptomonedas de Bloom es la relación entre la comodidad y la autoridad de firma.

Una interfaz automatizada puede simplificar el trading y, al mismo tiempo, hacer más difícil entender el mecanismo de acceso subyacente. Los usuarios necesitan conocerlo con precisión antes de poder evaluar el riesgo.

El compromiso de reembolso de Bloom debería evaluarse según su ejecución documentada. La investigación técnica debería evaluarse según la claridad con que explique el alcance, la causa y las medidas correctivas. Los conteos externos de billeteras deberían seguir atribuyéndose a sus fuentes y definirse con cuidado.

Hasta que esos elementos se concilien, lo responsable es proteger los activos restantes, conservar la evidencia de las transacciones y no tratar una acusación inicial ni una primera señal tranquilizadora como respuesta definitiva.

Preguntas frecuentes

1. ¿Qué pasó con el bot de criptomonedas Bloom?

Usuarios reportaron transferencias no autorizadas desde billeteras vinculadas a BloomTrading. El monitoreo de blockchain describió salidas sospechosas, mientras que la respuesta de Bloom indexada reconoció a usuarios afectados y se comprometió a reembolsarlos mientras investigaba el incidente. En esta revisión no se verificó la causa técnica completa. (x.com)

2. ¿Las cifras de nueve usuarios y 49 billeteras se contradicen?

No necesariamente. Una persona puede controlar varias billeteras y distintos informes pueden usar criterios de confirmación diferentes. Para poder comparar las cifras directamente, hace falta una metodología consolidada.

3. ¿Bloom completó todos los reembolsos?

En esta revisión no se estableció de forma independiente que se haya completado el resultado de los reembolsos. Hay que distinguir el compromiso de pagar de los reclamos aceptados, los registros de pago y la conciliación final.

4. ¿Desconectar Bloom alcanza para proteger una billetera?

No, si se comprometieron las credenciales de firma. Desconectar una aplicación, eliminar permisos vigentes y transferir los activos a claves generadas recientemente abordan riesgos distintos. Seguí las instrucciones verificadas del proveedor de la billetera según la exposición relevante.

5. ¿Este incidente demuestra que hackearon la red Solana?

No. Los reportes de transferencias no autorizadas vinculadas a una herramienta de trading no demuestran, por sí solos, que haya fallado la blockchain subyacente. Para determinar la causa hace falta evidencia sobre cómo se autorizaron las transacciones.

Fuentes