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

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

Как выглядит первый час со стороны команды

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

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

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

Признаки, по которым инцидент отличается от сбоя

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

Проверка за 60 секунд: что открыть и на что смотреть

Дежурный проходит шесть пунктов без согласований. Право на это даёт ранбук.

  1. Откройте балансы контрактов, где лежат пользовательские средства, и сравните с ожидаемыми.
  2. Посмотрите последние вызовы: структура, адреса отправителей, наличие истории у этих адресов.
  3. Проверьте историю смены реализации по адресам прокси за последние сутки.
  4. Прочитайте очередь таймлока: нет ли поставленного в неё изменения прав.
  5. Сверьте значение оракула с внешними источниками цены.
  6. Проверьте, кто сейчас владеет административными ключами и не менялся ли состав подписантов.
Схема из пяти шагов: дежурный фиксирует отклонение, назначается руководитель разбора, снимается состояние до любых правок, принимается решение о паузе, уходят уведомления и публичное сообщение
Схема из пяти шагов: дежурный фиксирует отклонение, назначается руководитель разбора, снимается состояние до любых правок, принимается решение о паузе, уходят уведомления и публичное сообщение

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

Пять решений первого часа и кто их принимает

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

Решение Кто принимает Срок Цена промедления
Признать событие инцидентом Дежурный инженер, единолично и без согласований До 5 минут от первого сигнала Каждая минута ожидания — продолжающийся вывод средств
Назначить руководителя разбора Первый доступный из списка по заранее записанной очереди До 10 минут от признания инцидента Без роли дублируется работа и не принимаются решения
Снять состояние системы Дежурный инженер до передачи задачи кому-либо До первого развёртывания исправления Правка перезаписывает данные, по которым восстанавливают картину
Остановить операции в контракте Держатели административных ключей по порогу мультиподписи До 20 минут от признания инцидента Остаток в контракте выводится полностью, пока идёт обсуждение
Выпустить публичное сообщение Руководитель разбора, текст без оценок и обещаний До 60 минут от признания инцидента Пустоту заполняют поддельные объявления от имени проекта
На 14 октября 2026 года, по данным отчёта Chainalysis за 2026 год, за 2025 год из сервисов и кошельков похищено 3,4 млрд долларов, причём три крупнейших эпизода дали 69% потерь сервисов. На группу, связываемую отчётом с КНДР, пришлось 2,02 млрд долларов — рост на 51% за год и 76% всех компрометаций сервисов.

Доля в 76% говорит о характере противника больше, чем сумма. Компрометация сервиса — обычно не дефект контракта, а доступ к ключам и к инфраструктуре подписи. Ранбук обязан предусматривать именно этот сценарий и исходить из того, что административный ключ, возможно, уже находится в чужих руках. Отсюда и порядок: состав подписантов проверяется прежде, чем кто-либо нажмёт паузу.

Пошаговые действия в первые часы

Порядок рассчитан на команду из нескольких человек. Возврат средств не гарантирован никем. Семь пунктов.

  1. Зафиксируйте состояние: снимок хранилища, трассировки подозрительных вызовов, журналы узла и балансы с отметкой времени по UTC.
  2. Остановите операции в контрактах, где это предусмотрено, и закройте внешние интеграции.
  3. Выведите остатки из связанных контрактов на заранее подготовленный резервный адрес.
  4. Уведомьте площадки, через которые средства могут выводиться, передав адреса получателей и хеши операций.
  5. Опубликуйте короткое сообщение: что известно, что остановлено, когда следующее обновление. Без оценок ущерба.
  6. Направьте заявление через интернет-приёмную МВД или в территориальный орган, приложив перечень операций и расчёт суммы в рублях на дату события.
  7. Соберите отчёт о разборе в течение недели: причина, сроки, что изменено в процессе выпуска.
Публичных обещаний компенсации в первый час не делают. Размер ущерба в этот момент неизвестен, и заявленная цифра потом расходится с итоговой. Сообщение первого часа содержит факты и время следующего обновления, а не оценки.

Как закрыть дыру, чтобы не повторилось

  1. Опишите ранбук письменно и укажите в нём пороги числом, а не словами «при существенном отклонении».
  2. Проведите учебный инцидент и замерьте время до постановки паузы.
  3. Разделите права: остановка операций и обновление реализации не должны требовать одних и тех же подписей.
  4. Поставьте таймлок на изменение прав и публикуйте очередь изменений.
  5. Настройте оповещение об изменении баланса контрактов и состава подписантов.
  6. Проверяйте инвариант безопасности автоматическим тестом после каждого обновления реализации.
  7. Держите резервный адрес для вывода остатков подготовленным заранее, а не создавайте его в ходе инцидента.

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

Чек-лист

  • Ранбук записан, роли и пороги указаны числом.
  • Очередь назначения руководителя разбора составлена и известна команде.
  • Право признать инцидент и снять состояние закреплено за дежурным единолично.
  • Порог мультиподписи для остановки операций отделён от порога для обновления кода.
  • Резервный адрес для вывода остатков подготовлен и проверен переводом.
  • Оповещения об изменении балансов и состава подписантов настроены.
  • Учебный инцидент проведён, время до постановки паузы замерено.
  • Шаблон публичного сообщения первого часа написан заранее.

Частые вопросы

Кто должен иметь право ставить паузу?

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

Что фиксировать до правок?

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

Нужно ли сообщать публично до выяснения причины?

Да, коротко и по фактам. Сообщение первого часа содержит три вещи: что замечено, что остановлено, когда будет следующее обновление. Причину и размер ущерба не называют. Молчание проекта быстро заполняется поддельными объявлениями от его же имени, и для пользователей это обходится дороже, чем признание неполноты сведений.

Как проверить ранбук, не дожидаясь инцидента?

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

Вердикт

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

Разборы инцидентов и предупреждения публикуем в Telegram-канале Cryptium.