Опустошение кошельков криптобота Блум: что произошло и что проверить пользователям

Пользователи криптобота Bloom сообщили о несанкционированных переводах с кошельков; Блум публично обязался возместить убытки пострадавшим и выяснить причину. Onchain Lens сообщил примерно о 9,408 Solana (SOL) на сумму около 954 000 $, связанных с 49 предполагаемыми пострадавшими. Отдельно в публично индексируемом ответе Блума были упомянуты девять пострадавших пользователей. Эти цифры относятся к разным охватам сообщений; их не следует считать согласованным итогом инцидента.

Мы считаем, что сейчас в первую очередь нужно защитить оставшиеся активы и задокументировать убытки, а не принимать раннее объяснение за окончательную причину. Обязательство возместить убытки имеет значение, но это не то же самое, что уже выплаченная компенсация. Аналогично, отключение торгового бота не является полноценным решением, если кто-то ещё может авторизовать транзакции с кошелька.

В этом обзоре отражена информация, доступная на 26.10.2026. Расследование продолжается, а техническая причина и полный итог возмещения не были независимо установлены в ходе подготовки материала.

Что такое Bloom Crypto и какой продукт затронут?

В контексте этого инцидента под «Bloom crypto» подразумевается экосистема торгового бота BloomTrading, а не любая криптовалюта или кошелёк с названием Bloom.

На сайте Bloom представлены три связанных продукта: расширение для браузера, веб-приложение Bloom Manager и торговые инструменты в Telegram. В документации описаны автоматизированные торговые функции и управление кошельками в нескольких поддерживаемых сетях. (Самая продвинутая автоматизация кроссчейн-торговли)

Структура продуктов важна при расследовании возможной утечки. История пользователя расширения может отличаться от истории того, кто создал кошелёк через бота или импортировал существующий кошелёк.

Поэтому важно задать конкретные вопросы: каким продуктом вы пользовались? Какой кошелёк был задействован? Какие данные или полномочия вы предоставили? Какие транзакции действительно произошли?

Совпадение названий не доказывает, что два продукта связаны. Читателям также не следует путать BloomTrading с отдельно названной уязвимостью генерации кошельков «Ill Bloom». Сходство названий не свидетельствует об общей причине, операторе или группе затронутых кошельков.

Что известно об опустошении кошельков Bloom?

Доступные сведения поступают из разных источников, преследующих разные цели. Жалобы пользователей описывают отдельные случаи, аккаунты мониторинга выявляют закономерности транзакций, а платформа сообщает о собственных действиях.

Эти категории могут пересекаться, но не являются взаимозаменяемыми.

Данные мониторинга следует по-прежнему приписывать Onchain Lens. В этой статье мы не реконструировали независимо каждую транзакцию и не установили владельцев всех адресов в опубликованной группе.

Это различие важно на практике. Транзакция может показать, что активы перемещались между адресами. Чтобы установить, был ли перевод несанкционированным, кто контролировал адреса и какой продукт или учётные данные позволили его совершить, нужны дополнительные доказательства.

Аналогично, заявление платформы может подтвердить, что она дала определённое обещание. Само по себе оно не доказывает, что обещание выполнено.

Почему в сообщениях фигурируют девять пользователей и 49 кошельков?

Пользователи, кошельки и адреса — разные единицы подсчёта.

В индексируемом заявлении Блума говорится о девяти пострадавших пользователях. Внешний мониторинг указывает на более широкую предполагаемую группу. Представлять эти данные как два напрямую сопоставимых числа пострадавших клиентов преждевременно.

Один человек может контролировать несколько кошельков. В наборе данных мониторинга также могут быть адреса, связь которых с платформой ещё не подтверждена.

Рассмотрим условный пример: у одного трейдера могут быть основной кошелёк, два торговых кошелька и отдельный кошелёк для автоматизированных стратегий. Четыре затронутых адреса не обязательно означают, что пострадали четыре человека.

Важна и обратная сторона проблемы. Первоначальное подтверждённое платформой число пользователей может включать только те обращения, которые она уже рассмотрела. Это не доказывает, что каждый адрес во внешнем расследовании принадлежит ещё одному клиенту.

В корректном сводном отчёте об инциденте должны быть описаны определения и методология. В нём следует отдельно указать уникальные адреса, клиентские аккаунты, подтверждённые обращения и нерешённые случаи.

Пока этого нет, делить одно число на другое, чтобы оценить «долю пострадавших, которым возместят убытки», означало бы получить вводящий в заблуждение результат. Не показано, что числитель и знаменатель относятся к одной и той же группе.

Подтверждена ли причина инцидента с Bloom?

Окончательная техническая причина не была подтверждена в ходе этой проверки.

В публичном ответе Блума говорится, что расследование продолжается. В публикациях обсуждалась возможная причастность третьей стороны, но возможное объяснение нельзя представлять как установленный механизм атаки. (x.com)

Несколько вопросов пока остаются открытыми.

Была ли несанкционированная транзакция подписана с помощью раскрытого приватного ключа? Была ли скомпрометирована программа или сервис? Одобрил ли пользователь вредоносную транзакцию? Пострадали ли разные пользователи из-за одного и того же механизма?

Доказательства в пользу одного варианта автоматически не исключают остальные. Подозрительный перевод — отправная точка для расследования авторизации, а не полное объяснение произошедшего.

Что добавляет исследование BloomEVM от HashDit?

В опубликованном HashDit анализе описано тестирование сценариев работы кошелька BloomEVM. HashDit сообщил, что при создании и импорте кошелька сведения о приватных ключах проходили через серверную инфраструктуру. Это выводы исследователей, а не результаты независимого тестирования, проведённого для этой статьи.

Эти сведения поднимают важный вопрос о контроле над кошельком: может ли сервис или его инфраструктура получить доступ к данным, необходимым для авторизации транзакций?

Однако необходимо чётко обозначить рамки исследования. Анализ конкретного процесса работы с продуктом EVM не устанавливает, как произошли упомянутые сейчас переводы Solana. Он также не доказывает, что все версии продукта и все кошельки работали одинаково.

В собственной документации Bloom по EVM описаны создание и импорт кошельков, в том числе получение приватного ключа и адреса. Это подтверждает важность изучения архитектуры управления кошельками, но одной документации недостаточно, чтобы установить причину инцидента.

Обоснованный вывод состоит в том, что обработку ключей необходимо тщательно проверить. Необоснованный вывод — утверждать, что это исследование уже доказало первопричину нынешнего инцидента.

Чем отличаются отключение, отзыв разрешений и замена ключей?

Эти действия направлены на разные виды доступа. Если считать их взаимозаменяемыми, можно оставить без внимания важный риск.

Отключение касается соединения приложения с кошельком. Отзыв разрешений — ранее предоставленных приложению или другой стороне полномочий. Замена скомпрометированных ключей означает переход к действительно новой идентичности кошелька.

В рекомендациях Phantom по безопасности отдельно различаются отключение приложений и отзыв разрешений на расходование средств. Также рекомендуется перестать пользоваться кошельком, если могла быть скомпрометирована фраза восстановления, приватный ключ или устройство.

Самая простая проверка — спросить себя: что другая сторона всё ещё может сделать без моего следующего подтверждения?

Если проблема связана с подключением приложения, отключение устраняет именно это соединение. Если сохраняются действующие полномочия, их нужно проверить отдельно. Если приватный ключ вышел за пределы предусмотренной защищённой среды, изменение настроек интерфейса не удалит копию ключа у другой стороны.

Это общие принципы безопасности кошельков. Они не устанавливают, какой именно сценарий привёл к сообщениям о Bloom.

Что пользователям Bloom следует проверить в первую очередь?

Начните с оценки собственного риска, а не с предположения, что у каждого посетителя сайта была одинаковая степень воздействия.

История риска пользователя, который только читал открытую страницу, отличается от истории того, кто импортировал приватный ключ. Если человек подписывал транзакцию, ему нужно проверить, какие действия она разрешила.

Следующий порядок действий поможет организовать проверку.

1. Определите, какими кошельками вы пользовались

Запишите публичные адреса, которые вы использовали с продуктом, и соответствующие сети.

Отличайте кошелёк, созданный для автоматизированной торговли, от существующего кошелька, импортированного в сервис. Также отметьте, использовали ли вы этот кошелёк где-либо ещё.

Не отправляйте фразы восстановления, приватные ключи, пароли или коды аутентификации в обращении в службу поддержки. Публичные адреса помогают идентифицировать транзакции; секретные учётные данные позволяют получить контроль.

2. Проверьте историю транзакций, а не только отображаемый баланс

Изменение баланса может быть связано с переводами, сделками, комиссиями или ошибкой отображения в приложении. Проверьте записи соответствующих транзакций.

Запишите идентификатор и время транзакции, актив, сумму и адрес назначения. Сохраните исходные ссылки вместе со снимками экрана.

Запись в обозревателе блокчейна не обязательно указывает, кто в реальном мире контролирует адрес назначения. Разделяйте утверждения «активы переведены на этот адрес» и «этот человек украл активы».

3. Проверьте подключения и действующие разрешения

Используйте официальные инструкции провайдера кошелька, чтобы проверить подключённые приложения и поддерживаемые разрешения.

Инструменты для разных сетей и модели авторизации отличаются. Не следует считать, что инструкция по разрешению на расходование токенов EVM описывает все типы полномочий аккаунтов Solana.

В рекомендациях Phantom по опустошению кошельков отдельно приведены инструкции для проверки разрешений в разных сетях. Переходите к таким инструментам через проверенную документацию, а не через нежелательное сообщение.

4. Оцените, нужно ли создать новый кошелёк

Если могли быть скомпрометированы учётные данные для подписи или само устройство, для нового кошелька нужны действительно новые ключи.

Импорт старой фразы восстановления в другое приложение не создаёт новую защищённую идентичность. В инструкции Phantom по переносу объясняется, что для получения новой фразы восстановления нужно создать новый кошелёк и перевести активы.

Перед переносом учтите застейканные активы и открытые позиции, а также свободно переводимые балансы. Для некоторых активов нужны дополнительные действия.

5. Не пополняйте снова кошелёк, с которого сразу исчезают депозиты

Если новые депозиты почти сразу пропадают, прекратите тестовые пополнения.

Phantom указывает, что такая закономерность может соответствовать работе бота-сборщика, и предостерегает от попыток опередить его повторными переводами. Это общее предупреждение, а не вывод о том, что бот-сборщик действовал во всех описанных случаях с Bloom.

Что нужно для настоящего возмещения от Bloom?

Обещание возместить убытки следует оценивать по процессу выплат, а не только по формулировкам объявления.

Блум публично обязался возместить убытки. В ходе этой проверки не удалось установить, что все пострадавшие пользователи получили компенсацию.

Оценивая будущие обновления, обращайте внимание на последовательность этапов:

Таблица представляет собой редакционную систему проверки, а не утверждение, что Bloom опубликовал именно такой процесс.

Если старый кошелёк может быть небезопасен, использование нового адреса для получения средств может быть оправданным. Однако необходимо также удостовериться в подлинности процесса регистрации этого адреса.

При настоящем обращении в поддержку у вас не должны запрашивать приватный ключ нового кошелька для получения средств. Чтобы отправить активы на публичный адрес, никому не нужны учётные данные для подписи транзакций.

Сохраните запись адреса, который вы указали, и способа его отправки. Это поможет отличить настоящую ошибку при выплате от выдачи себя за другое лицо или подмены адреса назначения.

Как следует рассчитывать сумму возмещения?

Для расчёта суммы возмещения необходимо определить единицу измерения.

Указанная долларовая стоимость украденных активов — это оценка на определённый момент времени. Она не становится автоматически суммой, которую платформа согласилась выплатить.

Рассмотрим этот гипотетический пример, не связанный с подтверждённым требованием к Bloom:

Пользователь теряет 20 единиц актива стоимостью 100 $ за единицу. Убыток, оценённый на момент инцидента, составляет 2000 $.

Если позже актив будет торговаться по 110 $, возврат 20 единиц и выплата 2000 $ приведут к разным результатам. Нельзя предполагать, какой из этих способов будет применён, не зная условий компенсации.

В чётко описанных условиях расчёта должно быть указано, рассчитывается ли возмещение исходя из количества активов, согласованной долларовой оценки или другого способа. Также следует уточнить, включены ли в требование комиссии.

Именно поэтому пострадавшим пользователям нужно сохранить и количество переведённых активов, и временную отметку. Снимка экрана с округлённым балансом в долларах может быть недостаточно для последующей сверки выплаты.

Такая же точность помогает избежать двойного подсчёта. Несколько исходящих переводов могут относиться к одному случаю убытка, а более поздний перевод может быть попыткой вернуть средства или переместить оставшиеся активы. Для каждой записи нужен контекст.

Означает ли «самостоятельное хранение», что торговый бот не может получить доступ к средствам?

Нет. Маркировка способа хранения менее информативна, чем фактическая схема авторизации.

Пользователю нужно понимать, как создаётся кошелёк, где выполняется подписание транзакций, импортируются ли учётные данные и какие действующие полномочия получает сервис.

Продукту для автоматизации нужен какой-либо механизм выполнения обещанных действий. Важно выяснить объём, срок действия и уровень безопасности этого механизма.

Например, система, которая требует подтверждения каждой транзакции, предусматривает иные меры контроля, чем система, способная выполнять стратегию, пока пользователь не в сети. Это различие само по себе не означает, что одна из систем мошенническая. Но оно меняет то, что пользователям необходимо проверить.

В полезной документации должно быть объяснено, к чему оператор может получить доступ, к чему не может и чем подтверждаются эти утверждения. Обнадёживающая фраза на главной странице не заменяет ясного технического объяснения.

Это более общий вывод из сопоставления документации Bloom с вопросами безопасности. Контроль следует оценивать по полномочиям на подпись, а не по брендингу.

Как пользователям избежать фальшивых сообщений о возврате средств и восстановлении доступа?

Во время развивающегося инцидента появляется множество людей, которым срочно нужна помощь. Из-за этой срочности сложнее спокойно оценить попытки выдать себя за службу поддержки.

Рассматривайте неожиданное сообщение с гарантией возврата средств как отдельный вопрос безопасности. Не считайте, что знание вашего публичного адреса кошелька подтверждает подлинность отправителя.

В рекомендациях Phantom по поддержке говорится, что сотрудники службы поддержки не запрашивают фразы восстановления или приватные ключи. В материалах по безопасности также указаны поддельные чаты поддержки и мошеннические запросы на верификацию как способы получить доступ к кошельку.

Если сообщение якобы отправлено от имени WEEX, воспользуйтесь сервисом проверки контактов WEEX. С его помощью можно проверять сайты, адреса электронной почты, номера телефонов, идентификаторы Telegram и аккаунты в социальных сетях. Он проверяет каналы, связанные с WEEX, но не подтверждает подлинность процесса возврата средств Bloom. (Проверяйте контакты и избегайте мошенничества)

Центр доверия WEEX — более общий ресурс для ознакомления с информацией о безопасности WEEX и инструментами проверки.

Ни один из этих ресурсов не отменяет внешнюю транзакцию с кошелька и не подтверждает право на компенсацию от другого сервиса.

Что покажет, что ситуация с Bloom разрешается?

Восстановление интерфейса или возобновление торговли недостаточно, чтобы считать инцидент урегулированным.

Содержательное обновление должно связывать три результата: пострадавшие выявлены, соответствующая уязвимость устранена, а подтверждённые убытки сверены с фактически выплаченной компенсацией.

В техническом объяснении следует указать затронутые продукты или версии, а также условия, при которых возникла уязвимость. Подтверждённые выводы нужно отделить от остающихся гипотез.

В обновлении о возмещении следует объяснить, какие суммы выплачены, а какие требования ещё рассматриваются. Если уместно публиковать сведения о транзакциях, они должны быть понятны и не раскрывать лишние персональные данные.

Наконец, пользователям нужно знать, что именно изменилось. Возобновление работы сервиса отвечает на операционный вопрос. Документированное изменение уязвимого процесса отвечает на вопрос безопасности.

Для читателей, следящих за этой историей, такие этапы важнее череды всё более уверенных заявлений.

Редакционный взгляд WEEX

Самый важный вопрос в сообщениях о криптоботе Bloom — соотношение удобства и полномочий на подпись.

Автоматизированный интерфейс может упростить торговлю, одновременно затруднив понимание того, как устроен доступ к средствам. Прежде чем оценивать риск, пользователям нужно получить точное описание этой схемы.

Обязательство Блума возместить убытки следует оценивать по документально подтверждённому выполнению. Техническое расследование следует оценивать по ясному описанию масштаба, причины и мер по устранению проблемы. Данные о внешнем числе кошельков необходимо атрибутировать и определять аккуратно.

Пока эти сведения не согласованы, ответственный подход — защитить оставшиеся активы, сохранить доказательства транзакций и не считать ни раннее обвинение, ни раннее заверение окончательным ответом.

FAQ

1. Что произошло с криптоботом Bloom?

Пользователи сообщили о несанкционированных переводах с кошельков, связанных с BloomTrading. Мониторинг блокчейна выявил подозрительные исходящие переводы, а в индексируемом ответе Блума были признаны пострадавшие пользователи и дано обещание возместить убытки на время расследования. Полная техническая причина не была подтверждена в ходе этой проверки. (x.com)

2. Противоречат ли друг другу цифры: девять пользователей и 49 кошельков?

Не обязательно. Один человек может контролировать несколько кошельков, а в разных сообщениях могут применяться разные критерии подтверждения. Прежде чем напрямую сопоставлять цифры, необходимо сверить методологию.

3. Завершил ли Bloom все выплаты?

Полный итог возмещения не был независимо установлен в ходе этой проверки. Обещание выплатить компенсацию следует отличать от принятых требований, записей о выплатах и окончательной сверки.

4. Достаточно ли отключить Bloom, чтобы защитить кошелёк?

Нет, если учётные данные для подписи скомпрометированы. Отключение приложения, отзыв действующих разрешений и перевод средств на кошелёк с новыми ключами направлены на разные риски. Следуйте проверенным инструкциям провайдера кошелька с учётом конкретного риска.

5. Доказывает ли этот инцидент, что сеть Solana была взломана?

Нет. Сообщения о несанкционированных переводах с помощью торгового инструмента сами по себе не доказывают сбой в работе базового блокчейна. Для установления причины нужны доказательства того, как были авторизованы транзакции.

Источники