21 февраля 2026 года атакующий захватил мост ioTube в Ethereum. Из резервов моста ушло около $4,4 млн, и ещё сотни миллионов CIOTX были выпущены из ничего12. IoTeX обнаружила инцидент в 08:01 UTC, почти через семь часов после первого шага в сети1.
Этот пост не пересказывает разбор IoTeX. Он отвечает на три вопроса. Когда сеть впервые показала, что что-то не так? Сколько времени оставалось после этого? И что команда могла сделать за это время?
Как устроен ioTube
ioTube переносит токены между IoTeX и другими сетями. В Ethereum это несколько контрактов, и атака понятна, только если знать, кто кем владеет3.
- TokenSafe хранит настоящие токены, которые пользователи перенесли из Ethereum: USDT, USDC, WETH, WBTC и другие. Когда кто-то переносит их обратно, TokenSafe их выдаёт.
- MinterPool выпускает и сжигает обёрнутые токены моста в Ethereum. Самый известный — CIOTX, токен IOTX в Ethereum.
- Свидетели (witnesses) — независимые операторы. Они следят за обеими сетями и подписывают каждый перевод. Переводу нужны подписи более двух третей из них3.
- TransferValidator проверяет эти подписи. Если они верны, он велит TokenSafe выдать токены или MinterPool их выпустить. Для этого он — владелец и TokenSafe, и MinterPool.
То есть каждый перевод защищают свидетели, но последнее слово за Validator: TokenSafe и MinterPool делают то, что велит их владелец. А у самого Validator тоже был владелец — один обычный адрес 0x6dd3…148e, без мультисига и без таймлока45.
Это и было слабое место. Тому, кто управляет ключом владельца Validator, свидетели не нужны.
Атака по шагам
Время — UTC, время блоков Ethereum. Каждую транзакцию ниже мы прочитали в сети сами6.
01:07:35 — у Validator новый владелец
Ключ владельца 0x6dd3…148e вызвал transferOwnership на Validator (0xE7eB…59d5) и передал его адресу 0xE6A1…55d9, которым управлял атакующий. Транзакция 0xe9e7…c9f0.
По словам IoTeX, атакующий получил ключ владельца через взломанный компьютер сотрудника, скорее всего с помощью социальной инженерии, и находился внутри задолго до атаки1.
У Validator моста смена владельца — событие редкое и плановое. Эта не была ни тем, ни другим. Контракт выпустил OwnershipTransferred, и в одном этом событии вся атака в двух словах: с этого блока атакующий мог забрать всё, чем управлял Validator.
Через две минуты, в 01:09:23, другой адрес прислал атакующему 0,1 ETH на газ (0x561b…2fa6).
01:20:35 — TokenSafe и MinterPool получают нового владельца
Атакующий вызвал upgrade на Validator (0xc9c5…51b8). Несмотря на название, это не обновление кода. Функция нужна, чтобы перевести мост на новый Validator. Она передаёт владение всеми контрактами Validator адресу, который ей дали3.
Атакующий дал ей свой адрес. В одной транзакции TokenSafe (0xC2e0…0d7a) и MinterPool (0x964F…3B45) выпустили по OwnershipTransferred: от Validator к 0xE6A1…55d96.
Дальше атакующему не были нужны ни свидетели, ни Validator. Он мог вызывать TokenSafe и MinterPool напрямую как владелец.
В разборе IoTeX сказано, что атакующий «обновил Validator» в 01:511. В сети этот шаг случился в 01:20:35, через 13 минут после смены владельца, и нового кода развёрнуто не было.
С 01:25:47 до 02:02:47 — TokenSafe пустеет
Атакующий вызвал TokenSafe.mint двенадцать раз. Название снова обманывает: у TokenSafe mint выдаёт настоящие токены, которые он хранит. Всё ушло на один адрес, 0x6487…442f6.
| Время | Выдано | Транзакция |
|---|---|---|
| 01:25:47 | 1 363,55 USDT, проба | 0x1b57…7c3d |
| 01:27:47 | 1 142 737,05 USDT | 0x349a…222d |
| 01:30:59 | 1 363 550,54 USDC | 0x28a2…3e94 |
| 01:41:23 | 635,09 WETH | 0xb90a…85d7 |
| 01:44:47 | 6,12 WBTC | 0x9f80…1adc |
| 01:46:59 | 20 158,79 DAI | 0x559b…b0aa |
| 01:50:35 | 8,72 PAXG | 0x9333…cb0c |
| 01:51:59 | 13 850 069,63 IOTX (ERC-20) | 0x6ca9…43d2 |
| 02:00:47 | 45 825,42 BUSD | 0xebbf…3196 |
| 02:02:47 | 2 835,25 UNI | 0x16d8…4814 |
Ещё два вызова, в 01:33:23 и 01:38:35, ничего не перевели. IoTeX оценивает итог примерно в $4,4 млн2. Украденные токены затем обменяли примерно на 2 183 ETH, и большая часть ушла через THORChain в биткоин24.
С 02:39 до 02:44 — вывод CCS
Атакующий выпустил через MinterPool 9 298 560 CCCS двумя вызовами, в 02:39:11 и 02:43:23, и обменял их через withdrawTo на столько же базового токена CCS в 02:41:47 (0xe6c1…7aa5) и 02:44:11 (0x3ef1…ceb7)6. По данным Rekt, CCS так и не продали4.
С 04:05 до 07:43 — CIOTX из ничего
Затем атакующий использовал MinterPool по прямому назначению: выпускал CIOTX, за которыми не стояло заблокированных IOTX. Десять вызовов, сначала мелкие, потом крупные6:
| Время | Выпущено | Транзакция |
|---|---|---|
| 04:05:11–04:14:11 | три пробных выпуска, до 11 000 CIOTX | — |
| 04:21:47 | 1 100 000 CIOTX | 0x1211…af11 |
| 05:01:23 | 110 000 000 CIOTX | 0x02dd…251f |
| 06:01:47 | 110 000 000 CIOTX | 0x4b53…ec82 |
| 07:06:47 | 500 000 000 CIOTX | 0xa40a…7350 |
| 07:29:59 | 50 000 000 CIOTX | 0x0aa4…a8c1 |
| 07:43:47 | 50 000 000 CIOTX | 0xc9ce…5520 |
В сети эти выпуски дают в сумме около 821 млн CIOTX, так же считает и Rekt46. В постах IoTeX названо 410 млн2. Откуда расхождение, мы не знаем. Наш счёт — сумма транзакций выпуска из таблицы.
08:01 и дальше — ответ
IoTeX обнаружила инцидент в 08:01 и выпустила первое публичное предупреждение в 09:39. В 10:03 её валидаторы остановили сеть IoTeX. Сеть вернулась 24 февраля1. За следующие недели IoTeX внесла в чёрный список 29 кошельков атакующего, заморозила около 45 млн IOTX, предложила награду 10%, вывела CIOTX из оборота в других сетях, перевела контракты моста на мультисиг с аппаратными ключами и автоматической остановкой при аномалиях и пообещала пользователям 100% компенсации из казны18.
Почти весь ущерб случился между первым возможным алертом в 01:10 и обнаружением в 08:01.
Что не изменило бы ни одно правило
Как поставить такие правила в SmartAlert
- Добавьте контракты, которые владеют другими контрактами. Для моста вроде ioTube это Validator, TokenSafe и MinterPool. Если в ABI есть
OwnershipTransferred, SmartAlert сам предложит правило смены владельца. Оставьте его включённым на каждом. - Проверьте правило на истории. Вы увидите все прошлые смены владельца: плановая передача не станет сюрпризом, а внеплановая будет заметна.
- Следите за выводом из хранилища. Добавьте каждый токен, который хранит хранилище, и создайте правило перевод больше суммы в $ с
from= хранилище. Тариф Pro и выше. - Следите за выпуском своего обёрнутого токена. Добавьте токен и создайте правило крупный перевод с порогом выше обычного объёма моста. Выпуск виден как перевод с нулевого адреса.
- Следите за итогом. Правило «Общий баланс адреса в $ ниже порога» складывает в долларах все токены хранилища. Поставьте порог чуть ниже обычной суммы, и оно сработает на крупный вывод любого токена, включая нативный ETH.
- Выберите, куда идут алерты. Telegram бесплатный. Алерты о смене владельца отправляйте в канал, который кто-то читает в час ночи.
Так же работают обновления прокси (Upgraded) и смена владельцев Safe. Все рецепты алертов.
Источники
- 1.IoTeX, How IoTeX responded to the ioTube bridge incident: a full month in review: обнаружение в 08:01, первое публичное предупреждение в 09:39, остановка сети в 10:03, заморозки, компенсация, взломанный компьютер сотрудника. ↩
- 2.IoTeX, Security incident update: ioTube bridge exploit and recovery roadmap: около $4,4 млн резервов, 410 млн CIOTX, обмен в ETH и THORChain. ↩
- 3.IoTeX, исходный код ioTube: свидетели, TokenSafe, MinterPool, TransferValidator и его функция
upgrade. ↩ - 4.Rekt, IoTeX — Rekt: адреса, владение одним ключом, 821 млн CIOTX, непроданный CCS. ↩
- 5.BlockSec, Weekly Web3 security incident roundup, Feb 16–22, 2026. ↩
- 6.Проверено SmartAlert в сети через Blockscout API: все транзакции от
0xE6A1…55d9за 21 февраля 2026 года, время их блоков, логиOwnershipTransferredу Validator, TokenSafe и MinterPool и суммы токенов в таблицах выше. ↩ - 7.SmartAlert, задержка алерта в Ethereum: 12 подтверждений (около 144 с), опрос головы сети до 12 с, запись до 15 с (P95), проверка правила раз в 60 с на Pro. ↩
- 8.Whale Alert, IoTeX offers a 10% bounty. ↩
- 9.CertiK, Bybit incident technical analysis. ↩
- 10.KiloEx, Security incident root cause analysis. ↩