Перевод

Это вольный перевод: https://thorchain.org/blog/thorchain-exploit-report-1.

Суть

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

Краткое резюме

15 мая 2026 года THORChain стала жертвой целенаправленного (векторного) эксплойта, в результате которого из одного (из 6 существующих) хранилищ было выведено около $10.7 млн.

Атакующим оказался недавно добавленный оператор ноды, присоединившийся к сети за два дня до инцидента и использовавший уязвимость в Threshold Signature Scheme GG20.

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

Затем операторы нод быстро скоординировались через Discord, наложив дополнительные ручные паузы и проведя формальные governance-голосования Mimir, которые примерно за два часа после обнаружения проблемы привели всю сеть к контролируемой остановке (торговля, подпись транзакций, наблюдение за цепями и churn-процессы были остановлены).

Оставшиеся пять хранилищ (vaults) не пострадали.

Было отдельно подтверждено, что пул SOL безопасен, поскольку сети на базе EdDSA не подвержены данному классу атак. Расследование продолжается совместно со специализированными организациями.

В качестве немедленной меры предосторожности был выпущен патч v3.18.1 для защиты оставшихся vault-хранилищ на время расследования. Решение о возмещении утраченных средств будет принято сообществом через ADR-028 (Architecture Decision Record #028).

Архитектура и безопасность

Прежде чем рассматривать события 15 мая 2026 года, важно понять защитные механизмы, на которые опирается THORChain для обеспечения безопасности активов.

В этом разделе описаны три взаимосвязанных уровня защиты:

• Threshold Signature Scheme GG20, используемая для коллективного контроля ключей vault-хранилищ;
• автоматическая система Solvency Checker, отслеживающая балансы vault’ов в реальном времени;
• система Halt & Emergency governance, через которую операторы нод могут вручную замораживать активность сети при обнаружении угрозы.

Почему это важно?

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

Threshold Signature Scheme - GG20

Vaults (хранилища) THORChain не контролируются одним приватным ключом.

Вместо этого используется GG20 (Gennaro-Goldfeder 2020) - Threshold Signature Scheme (TSS), распределяющая контроль над ключом между несколькими независимыми операторами нод. Ни одна отдельная нода никогда не хранит и не имеет доступа к полному приватному ключу.

Как это работает?

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

Процесс проходит через несколько раундов коммуникации:

• Каждая участвующая нода хранит secret key share - фрагмент приватного ключа вольта.
• Ноды обмениваются небольшими фрагментами зашифрованной информации на протяжении нескольких раундов протокола.
• В конце церемонии переданные значения объединяются для создания валидной подписи.
• Полный приватный ключ никогда и нигде не собирается целиком на протяжении процесса.

Почему GG20 использовался?

THORChain давно рассматривала DKLS (Doerner-Kondi-Lee-Shelat) как своё долгосрочное криптографическое решение - более современную и устойчивую TSS-схему.

Однако у сети были уникальные требования, которым стандартные реализации DKLS не соответствовали, например механизм identifiable aborts (возможность точно определить сторону).

Для решения этой задачи в ноябре 2025 года THORChain привлекла Silence Laboratories для разработки кастомной реализации DKLS с поддержкой identifiable aborts, адаптированной под требования сети.

Ориентировочным сроком поставки назывался Q1/Q2 2026 года.

Поэтому GG20 продолжал использоваться в production-среде как временное решение до завершения этой работы.

Автоматическая система проверки платёжеспособности (Automatic Solvency Checker)

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

Реактивный режим (Reactive mode)

В реактивном режиме каждая нода независимо и непрерывно сравнивает:

• что сеть считает находящимся в vault-е;
• и что фактически присутствует в onchain-кошельках для каждой подключённой сети.

Если ожидаемый баланс vault-а превышает фактический onchain-баланс более чем на 1%, нода сообщает о событии неплатёжеспособности (insolvency event) для соответствующей сети.

Если более 66% нод сообщают о неплатёжеспособности в одной и той же сети, торговля для этой сети автоматически останавливается (Halt{Chain}Trading).

Этот процесс полностью автоматизирован.

Одновременно остановка генерирует событие безопасности в канале мониторинга THORSec (THORChain Security).

Почему используется допуск в 1%? THORChain рассчитывает ожидаемые балансы, агрегируя входящие и исходящие транзакции. Для gas-активов (используемых для оплаты комиссий) естественным образом могут возникать небольшие расхождения до ±1% из-за округления и временных задержек. Любое отклонение выше этого порога рассматривается как аномалия.

Проактивный режим (Proactive mode)

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

Когда нода собирается подписать исходящую транзакцию (txOut), она сначала моделирует влияние этой транзакции на балансы vault-а.

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

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

Во время инцидента 15 мая система проверки платёжеспособности сработала так, как и была задумана: она обнаружила дисбаланс vault’а в течение нескольких минут и автоматически инициировала chain-level остановки.

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

Реактивный режим обнаружил дисбаланс уже постфактум, но средства к этому моменту уже покинули воль.

Halt & Emergency Governance

THORChain включает многоуровневую систему остановки (halt system), позволяющую сети замораживать определённые операции с различной степенью детализации - от остановки подписи транзакций в одной сети до полной паузы всей активности сети.

Эти механизмы управляются через Mimir - onchain-систему параметров THORChain.

Остановки, инициируемые операторами нод

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

Этот механизм специально спроектирован так, чтобы одновременно:

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

Как это работает?

• Одна нода может остановить торговлю максимум на 720 блоков (примерно 1 час).
• Каждая дополнительная нода, требующая остановки, добавляет ещё 720 блоков к активному таймеру паузы.
• Любая нода, голосующая за возобновление торговли, уменьшает таймер на 720 блоков.
• Каждая нода может воспользоваться этой функцией только один раз за churn-цикл (примерно 3 дня), что предотвращает повторные злоупотребления.

Принцип дизайна

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

15 мая примерно 18–20 нод наслаивали паузы друг на друга, создав окно остановки продолжительностью в несколько часов.

Mimir Governance и порог в 3 голоса

Сетевые параметры THORChain управляются через Mimir - набор on-chain-параметров, определяющих поведение протокола. Существует два разных типа Mimir.

Economic Mimirs

Economic Mimirs требуют согласия супербольшинства в ⅔ (67%) активных нод.

Примеры таких параметров:

• минимальный размер bond;
• минимальная комиссия за своп;
• интервал churn-процессов.

Operational Mimirs

Operational Mimirs требуют всего 3 голосов нод для активации.

• 4 ноды могут отменить параметр;
• затем 5 нод могут снова активировать его;
• и так далее.

Примеры:

• остановка торговли (halt trading);
• остановка подписи транзакций (halt signing);
• глобальная остановка сети (halt chain global).

Почему используется минимум в 3 голоса?

Минимальный порог в 3 голоса для operational-параметров - осознанный компромисс между безопасностью и скоростью реакции.

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

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

Поэтому требуется согласие трёх независимых нод:

• достаточно быстрое для чрезвычайных ситуаций;
• и достаточно устойчивое к попыткам единоличной манипуляции.

Подробная хронология

Этот раздел содержит реконструкцию эксплойта 15 мая 2026 года, начиная с событий за два дня до атаки. Все временные отметки указаны в UTC. Номера блоков относятся к mainnet-реестру THORChain.

Подготовка атаки

1 мая 2026 - предполагаемый атакующий присоединяется к Discord

Свежесозданный Discord-аккаунт Dinosauruss присоединяется к Developer Discord-серверу THORChain.

Dinosauruss начинает задавать множество вопросов о том, как добиться включения своей ноды в churn-процесс сети.

Обычный 3-дневный churn-интервал был задержан по несвязанным причинам, из-за чего Dinosauruss пришлось ждать несколько недель для попадания в активный набор валидаторов.

При этом Dinosauruss, судя по всему, проявлял сильную заинтересованность в том, чтобы его нода была включена как можно скорее.

13 мая 2026 - вредоносная нода входит в сеть

Совершенно новый оператор ноды (n84q) с новым node-адресом (n84q), имеющий около 635,000 RUNE, распределённых между двумя bond-адресами, включается в активный набор валидаторов.

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

В течение следующих двух дней эта нода участвует в обычных GG20 signing ceremonies, подготавливаясь к проведению эксплойта.

15 мая 2026 - опустошение вольта (ок. $10.7M несанкционированных исходящих транзакций)

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

Из целевого вольта выводится около $10 млн (первоначально оценка составляла $7.4 млн).

Оставшиеся пять vault-хранилищ не пострадали.

Автоматическая реакция - Solvency Checker

Через несколько минут после опустошения vault-а система проверки платёжеспособности (reactive mode) обнаруживает расхождение более чем на 1% между ожидаемыми и фактическими балансами vault-а в нескольких сетях.

Автоматически запускаются изменения протокола - без какого-либо участия человека.

Нижеописанные действия были автоматически выполнены протоколом для защиты сети и остановки дальнейшей исходящей активности:

В течение примерно 52 минут после несанкционированных транзакций система проверки платёжеспособности автоматически остановила подпись транзакций и торговлю в сетях ETH, AVAX, BSC, BASE, DOGE и GAIA - без какого-либо вмешательства человека.

Реакция сообщества и ручное вмешательство

15 мая 2026 года, с 09:08 до 09:41 - сообщество поднимает тревогу

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

Один из участников сообщества замечает необычную активность - множественные исходящие транзакции (send transactions) от THORChain Router на Ethereum-адрес без memo - и призывает к немедленной глобальной экстренно (emergency) остановке сети.

Это становится первым инициированным человеком сигналом тревоги в рамках данного инцидента.

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

Параллельно операторы нод начинают отправлять формальные governance-голоса через Mimir. Порог в 3 голоса активирует официальные изменения параметров сети на глобальном уровне.

Торговля, подпись транзакций, наблюдение за сетями и churn-процессы последовательно останавливаются через скоординированное взаимодействие в Discord и on-chain-governance - всё это произошло примерно в течение одного часа после сигнала тревоги от сообщества.

HALTTRADING был активирован в блоке 26183438

HALTTRADING activated at block 26183439

HALTTRADING активирован в block 26183590

HALTCHURNING activated at block 26183849

Churning приостановлен, чтобы не позволить вредоносной ноде покинуть сеть и предотвратить вход в неё дополнительных вредоносных нод.

Официальные сообщения

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

15 мая 2026, 11:01 - первое официальное публичное заявление

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

Первопричина на тот момент ещё не определена. Рассматриваются три возможных вектора атаки:

1. уязвимость в GG20;
2. компрометация инфраструктуры;
3. иные векторы атаки.

Операторов нод просят провести аудит своей инфраструктуры и отправить логи Bifrost через make relay.

15 мая 2026, 19:10 - второе обновление: атакующий идентифицирован, основная теория подтверждена

После полного дня расследования команда публикует развёрнутое обновление. Основные выводы:

1. вредоносная нода
   thor16ucjv3v695mq283me7esh0wdhajjalengcn84q
   через on-chain-форензику связана с Ethereum-адресами, получившими украденные средства;
2. основной рабочей теорией подтверждается эксплойт в реализации GG20 TSS, позволяющий постепенно извлекать key material;
3. объём потерь пересмотрен до примерно $10.7 млн;
4. ведётся координация с Outrider Analytics и правоохранительными органами.

Среди обсуждаемых вариантов восстановления:

• slashing bond-ов;
• использование POL (Protocol Owned Liquidity);
• и другие предложения сообщества.

16 мая 2026, 10:26 - предупреждение о мошенничестве

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

Через крупные медиа распространяются многочисленные мошеннические схемы с airdrop и refund.

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

18 мая 2026, 15:49 - патч и дорожная карта восстановления

Команды разработчиков и THORSec подтверждают, что уже хорошо понимают механику атаки, однако намеренно не раскрывают технические детали до того, как смогут предупредить другие проекты, использующие ту же криптографию GG20, чтобы те успели защитить свои системы.

Патч v3.18.1 находится на финальной стадии подготовки, и всех операторов нод просят немедленно обновиться после релиза.

Восстановление утраченных средств будет определяться через governance-процесс сообщества посредством ADR-028. Выбранный вариант планируется реализовать в v3.19.

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

18 мая 2026, 20:49 - подготовка патча и запрос на масштабирование Bifrost вниз

Всех активных валидаторов просят временно уменьшить масштаб своих Bifrost pods в качестве меры предосторожности до завершения подготовки патча.

Команды:

• make pull
• затем make scale-down (с выбором bifrost)

Это уменьшает поверхность атаки сети во время remediation-периода перед выпуском v3.18.1.

Выводы и дальнейшие шаги

Эксплойт 15 мая выявил уязвимость в реализации GG20 у THORChain.

Автоматические и ручные механизмы реагирования сети сработали согласно дизайну и ограничили ущерб одним хранилищем.

Сейчас предпринимаются следующие шаги:

• выпуск v3.18.1 является приоритетом номер один, и все операторы нод должны обновиться в ближайшие дни;
• расследование продолжается; полный технический отчёт будет опубликован после сбора всех релевантных деталей;
• governance сообщества определит путь восстановления через ADR-028;
• после достижения предполагаемого консенсуса ноды проголосуют, а выбранный подход будет реализован в v3.19.

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

[Продолжение следует...]

До!