Человек, запросивший платёж, прошёл проверку личности. Платёж одобрен, а подпись транзакции действительна. Значит ли это, что средства в безопасности?
Не обязательно.
В 2025 году BigONE потеряла около 27 млн USD, а Bybit подверглась атаке с ущербом в 1,5 млрд USD. В октябре 2026 года Binance сообщила об инциденте безопасности, затронувшем цифровые активы на сумму около 6,34 млрд USD. Эти инциденты показывают, почему одно лишь безопасное хранение закрытых ключей не может гарантировать сохранность средств.
Поэтому организациям нужно уделять внимание не только безопасному хранению закрытых ключей. На каком основании проводится платёж? Что именно подписывается? Кто определяет, можно ли подписать транзакцию? И как после исполнения система определяет, что платёж завершён?
В этой статье BlockSec на примере инцидентов, о которых сообщалось публично, рассматривает риски авторизации, которым часто не уделяют должного внимания, на всех этапах платежа — от инициирования до окончательного расчёта.
В нашей готовящейся серии технических материалов «За пределами безопасного хранения» мы подробно рассмотрим два пути атаки:
-
Использование возможностей системы по подписанию транзакций без получения её закрытых ключей.
-
Использование недостатков криптографических реализаций для восстановления этих ключей.
На каком этапе злоумышленник может перехватить криптоплатёж?
Платёж, проводимый через кошелёк, обычно проходит четыре этапа:
-
Основание для платежа и его авторизация.
-
Формирование и проверка транзакции.
-
Авторизация подписания и использование ключа.
-
Исполнение и окончательный расчёт.
1. Основание для платежа и его авторизация
Прежде чем подписывать транзакцию, организация должна убедиться, что платёж, который за ней стоит, правомерен:
• При выводе средств клиентом платформа должна проверить его личность, подтвердить наличие достаточных средств и убедиться, что запрос соответствует её бизнес-правилам.
• Внутренний перевод также требует надлежащего одобрения со стороны казначейства.
Но злоумышленник может изменить записи по счетам или логику контроля рисков. Тогда система может в обычном порядке одобрить платёж, который вообще не должен был состояться.
Например, 16.07.2025 BigONE сообщила об инциденте безопасности, затронувшем горячий кошелёк, с предполагаемыми потерями в 27 млн USD. По заявлению BigONE, её закрытые ключи оставались в безопасности. Расследование SlowMist показало, что злоумышленник изменил серверную логику, связанную со счетами и контролем рисков, что позволило проводить несанкционированные переводы.
Главное здесь то, что информация и правила, на основании которых одобрялся платёж, были изменены ещё до подписания.
Поэтому платёжным организациям недостаточно проверять, что запрос поступил от внутреннего сервиса. Для каждого платежа должна быть возможность установить его связь с независимо проверяемым распоряжением клиента или решением казначейства. Организациям также нужно выяснить, может ли злоумышленник, получив контроль над одной учётной записью, подделывать запросы, изменять записи и правила одобрения.
2. Формирование и проверка транзакции
Действительно ли вы собираетесь подписать то, что видите?
После одобрения платежа система должна преобразовать его параметры, в том числе адрес получателя и сумму, в данные транзакции, которые может подписать кошелёк.
Если этот процесс скомпрометирован, интерфейс может показывать перевод, хотя отправляемая на подписание транзакция на самом деле меняет того, кто контролирует кошелёк.
В таком случае ваша подпись может дать злоумышленнику контроль над кошельком, хотя вы считаете, что одобряете перевод.
Эту опасность иллюстрирует атака на Bybit в 2025 году с ущербом около 1,5 млрд USD. Bybit намеревалась перевести ETH с холодного кошелька на тёплый. Злоумышленник скомпрометировал интерфейс Safe и сделал так, чтобы вредоносная транзакция выглядела как обычный перевод. Подписанты одобрили её, не зная, что тем самым разрешают изменить логику управления кошельком.
Используя действительные подписи, злоумышленник заменил логику управления кошельком, а затем с помощью новой логики перемещал активы, не получая отдельного одобрения первоначальных владельцев на каждый последующий вывод средств. Подробный анализ ончейн-данных приведён в разборе взлома Bybit на 1,5 млрд USD, подготовленном BlockSec.
Вывод очевиден:
Проверка перед подписанием должна охватывать всю подписываемую транзакцию и последствия её исполнения. Нельзя полагаться только на то, что показывает интерфейс. Даже несколько подписантов могут не заметить проблему, если все они опираются на одно и то же скомпрометированное представление транзакции.
Для переводов, обновлений кошелька и изменений прав на вывод средств также должны действовать разные требования к авторизации. Одобрение обычного перевода не должно позволять изменить контроль над кошельком.
3. Авторизация подписания и использование ключа
Кто может подписывать транзакции и кто может менять правила подписания?
Даже если злоумышленники не могут подписывать транзакции напрямую, они могут получить сопоставимый уровень контроля, изменив правила или заменив код, работающий в системе.
Поэтому административные права, определяющие доступ к ключам подписи, требуют столь же тщательной проверки, как и сами права на подписание.
Согласно официальному разбору инцидента безопасности Resolv, произошедшего в марте 2026 года, первоначальные попытки злоумышленника получить доступ к подписанию не удались. Затем он использовал привилегированную роль, чтобы изменить политику доступа к ключу и предоставить себе право подписи. Получив это право, злоумышленник выпустил 80 million USR посредством двух несанкционированных транзакций.
Другой путь к доступу к подписанию описан в первоначальном отчёте Binance об инциденте. Злоумышленник использовал скомпрометированное устройство сотрудника и внутренний ИИ-инструмент, чтобы получить доступ к устройствам инженеров, работавших с кошельками. С помощью похищенного токена для развёртывания контейнеров он развернул контейнер и запустил вредоносный скрипт. Полученный затем несанкционированный доступ к внутреннему сервису подписания транзакций кошелька позволил проводить транзакции в обход обычного процесса вывода средств.
Точки входа различались, но оба инцидента выявляют одну и ту же основную проблему:
Защита ключей также требует контроля над тем, кто может менять политики доступа к ключам, изменять среду подписания или предоставлять права на подписание.
Поэтому платёжным организациям необходимо ответить на все три вопроса:
-
Кто может вызывать API подписания?
-
Кто может предоставлять право вызывать этот API?
-
Кто может развёртывать или изменять сервис подписания?
Разделение обязанностей при одобрении платежей, использовании ключей и внесении административных изменений должно оставаться действенным и в случае компрометации привилегированной учётной записи.
4. Исполнение и окончательный расчёт
Исчезает ли риск после подписания транзакции?
Не обязательно. Организациям также нужно учитывать, когда подписанная транзакция может быть исполнена и каким образом её можно сделать недействительной.
Риск 1: подписанная транзакция может оставаться доступной для исполнения
Транзакция подписана, но ещё не исполнена. Можно ли отправить её позднее?
При некоторых механизмах — да. Отмена исходного платежного запроса не делает подписанную транзакцию автоматически недействительной.
Во время инцидента Drift Protocol 01.04.2026 злоумышленник использовал механизм долговременного nonce в Solana, чтобы заранее подписанные транзакции оставались действительными дольше короткого срока действия обычных транзакций. Пока соответствующий nonce не был использован или обновлён, транзакции можно было отправить на исполнение позднее.
На случай отмены платежного запроса или обнаружения подозрительной активности организациям нужен установленный способ делать подписанные, но неисполненные транзакции недействительными. Они также должны определить, кто уполномочен это делать.
Риск 2: внутренний перевод может быть неверно истолкован и повлечь дополнительный возврат средств
12.09.2026 Chainflip подверглась атаке, связанной с USDT в сети Tron. Злоумышленник добавил специально подготовленное примечание к транзакции, которую валидаторы уже подписали. Система Chainflip ошибочно распознала примечание как отдельную операцию обмена, сочла её неуспешной и произвела возврат средств. По сообщению Chainflip, произошло шесть несанкционированных выплат на общую сумму около 736,4 тыс. USDT.
Ончейн-перевод не обязательно представляет собой новый платёж клиента или служит основанием для возврата средств. Прежде чем совершить платёж или вернуть средства, система должна также проверить происхождение средств, тип бизнес-операции и то, не было ли соответствующее платежное обязательство уже исполнено.
Насколько устойчива ваша платёжная система?
Эти случаи показывают, что средства можно потерять как до подписания, так и после него. Одна лишь действительная подпись не подтверждает, что:
• У платежа есть правомерное основание.
• Подписанная операция соответствует той, которая была одобрена.
• Платежное обязательство ещё не исполнено.
Поэтому содержательная оценка безопасности платёжной организации должна давать ответы на конкретные вопросы:
• Можно ли для каждого платежа установить независимо проверяемое основание?
• Соответствует ли вся подписываемая операция тому, что было одобрено, включая любые изменения прав или дополнительные транзакции?
• Если учётная запись с операционными или административными правами скомпрометирована, остаются ли независимые меры контроля, способные заблокировать или ограничить несанкционированный перевод средств?
• Можно ли после приостановки вывода средств по-прежнему использовать существующие подписи и ончейн-разрешения для перемещения средств? Как организация может убедиться, что меры по сдерживанию инцидента действенны?
Однако разовая проверка настроек не может дать ответы на эти вопросы на длительный срок.
Обновления программного обеспечения, изменения прав доступа и бизнес-операций могут изменить существующие границы защиты. После таких изменений организациям нужно заново оценивать, остаются ли их меры контроля действенными.
ИИ-инструменты тоже могут создавать новые возможности для атак. Постоянный мониторинг помогает командам выявлять подозрительную активность. Учения по реагированию на инциденты позволяют проверить, смогут ли команды ограничить дальнейший отток средств в случае компрометации критически важной учётной записи или рабочей среды.
Подробнее об оценке этих рисков читайте в материале о том, как решение Payment Security Solution от BlockSec помогает организациям защищаться в эпоху ИИ.
Присоединяйтесь к нашему вебинару: защита средств в эпоху ИИ
Чтобы подробнее рассмотреть эти вопросы, BlockSec проведёт онлайн-вебинар «Защита средств в эпоху ИИ». На примере недавних инцидентов безопасности, затронувших биржи и платёжные компании, участники обсудят, как злоумышленники через людей, инструменты и рабочие среды получают доступ к системам, обрабатывающим средства, а также как организации могут улучшить обнаружение угроз, проверки авторизации и реагирование на инциденты.
Приглашённые докладчики:
• Yajin Zhou: доцент Китайского университета Гонконга; соучредитель и CEO BlockSec
• Lei Wu: доцент Чжэцзянского университета; соучредитель и CTO BlockSec
• Muhui Jiang: CSO BlockSec
Дата и время: среда, 11.11.2026, 7:00 вечера по сингапурскому времени (SGT, UTC+8)
Формат: онлайн-вебинар
Преимущество для участников: во время вебинара будут выбраны две участвующие организации, которые получат бесплатную предварительную оценку безопасности.
Раннее выявление рисков необходимо для защиты каждого платежа.
Мы приглашаем руководителей, специалистов по безопасности и технические команды платёжных организаций присоединиться к нам, чтобы изучить слепые зоны в защите на всех этапах платежа.
Свяжитесь с нашим отделом продаж, чтобы узнать больше о вебинаре.
Посетите официальный сайт BlockSec>>>
Подписывайтесь на нас в X (Twitter)>>>
Присоединяйтесь к нам в Telegram>>>
Подписывайтесь на нас в LinkedIn>>>
