DeFi часто подвергается кражам, как в эпоху ИИ предотвращать хакерские атаки?

Написано: systs

Обзор OpenBuild:

В апреле 2026 года DeFi пережил самый темный период, сумма украденных средств за месяц превысила 625 миллионов долларов, установив новый рекорд, только два атаки — Drift и KelpDAO — поглотили почти 580 миллионов долларов. Взрыв ИИ полностью изменил стратегию нападения и защиты: то, что раньше требовало недель ручной работы для поиска уязвимостей протоколов, теперь за несколько часов может сделать крупномасштабная модель, стоимость атак резко снизилась, а поверхность атаки значительно расширилась, всё больше протоколов становятся целями.

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

Разработка проекта @openforage и исследование множества исторических атак на DeFi-протоколы вызвали у меня бдительность к государственным уровням злоумышленников. Эти противники опытны, обладают большими ресурсами и умеют строить долгосрочные стратегии; как топовые антагонисты, они тщательно проверяют каждое отверстие в вашем протоколе и инфраструктуре, ищут уязвимости. Обычные команды часто рассеяны, совмещают бизнес и безопасность, не могут полностью сосредоточиться. Я не считаю себя экспертом по безопасности, но у меня есть опыт руководства в условиях высокого риска (военное прошлое и управление крупными финансами в крупных институтах), я обладаю практическим опытом разработки планов по управлению рисками и реагированию. Я твердо верю: только упорные выживают. Ни одна команда изначально не работает с мыслью «безопасность — формальность», но атаки случаются постоянно. Нам нужно делать лучше.

/ 01 Эпоха ИИ: всё уже иначе

Хакерские атаки — не редкость, но их частота резко возросла. В первом квартале 2026 года зафиксирован рекорд по количеству атак в истории DeFi, а во втором квартале, который только начался, есть все шансы побить этот рекорд.

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

/ 02 Размышления о поверхности атаки и многоуровневой защите

Практически, основные направления атак на DeFi — всего три:

• Команда оператора протокола
• Смарт-контракты и инфраструктура
• Границы доверия пользователей (домены, соцсети и т.п.)

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

Профилактика: стандартизация процессов, строгое выполнение — минимизация вероятности взлома.

Смягчение потерь: при сбое профилактики — быстрое ограничение ущерба.

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

Восстановление контроля: если злоумышленный модуль или компонент вышли из-под контроля — их отключение или замена.

Восстановление после инцидента: возврат украденных средств, сотрудничество с организациями для заморозки, отката транзакций, расследования.

/ 03 Основные принципы

Эти принципы руководят внедрением всей системы многоуровневой защиты.

Передовые AI-методы защиты

Использовать передовые крупные модели для сканирования кода и конфигураций на уязвимости, проводить красно-синие тесты: активное обнаружение фронтенд-уязвимостей, проверка возможности проникновения в бэкенд. Злоумышленники так делают; защита — тоже. Можно использовать инструменты pashov, nemesis, а также платформы AI-безопасности Cantina (Apex), Zellic (V12) для быстрого предварительного анализа кода перед аудитом.

Время и процессы — важнейшие элементы защиты

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

Дизайн неизменных правил

Смарт-контракты должны иметь определенные неотъемлемые свойства, нарушение которых делает весь протокол недействительным. @openforage строит защиту вокруг платежеспособности: активы в хранилище + уже развернутые активы ≥ непогашенные обязательства. Для этого достаточно задать несколько ключевых неотъемлемых правил; не стоит прописывать их в каждом функции — это усложняет код.

Баланс власти

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

• Гражданские права: контроль за ключевыми решениями протокола
• Аварийные полномочия: восстановление стабильности, без возможности отмены или замены госконтроля

Обязательно предусматривать неизбежность сбоев

Нужно заранее понимать: даже самые профессиональные команды рано или поздно столкнутся с атакой. Смарт-контракты или компоненты могут выйти из строя, команда — стать жертвой социальной инженерии, обновления — ввести новые уязвимости. Поэтому важно внедрять лимиты, автоматические отключения и контроль рисков: ограничивать потери 5–10%, замораживать активы и разрабатывать планы реагирования. В критической ситуации — избегать поспешных решений.

Раннее внедрение планов реагирования

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

Выживание — главный приоритет

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

/ 04 Система профилактики

Проектирование смарт-контрактов

После определения ключевых неотъемлемых свойств — включить их в логику выполнения, тщательно выбрать, какие правила обязательно проверять. Рекомендуется использовать модель FREI-PI (Функциональные требования — Влияние — Внешние взаимодействия — Неотъемлемые свойства): все функции, связанные с активами, должны проверять неотъемлемые свойства перед завершением. Многие атаки (арбитраж через флеш-лоны, злоумышленное очищение оракулов, межфункциональные потери платежеспособности) могут быть предотвращены проверками в конце функций.

Совершенствование тестовой системы

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

Оракулы и внешние зависимости

Чем сложнее система — тем больше поверхность атаки. Каждая внешняя зависимость увеличивает риск. При разработке базовых компонентов доверие должно быть делегировано пользователю; если зависимость не устранена — использовать мультиисточники и децентрализацию, чтобы избежать единой точки отказа. Аудит должен охватывать сценарии сбоев оракулов и внешних систем, а также предусматривать лимиты и контроль. Недавний пример — атака KelpDAO: проект использовал LayerZero с настройкой requiredDVNCount=1, которая не входила в аудит; в итоге уязвимость была найдена в сторонней инфраструктуре.

Полный анализ поверхности атаки

Известные векторы атак в DeFi — полная и актуальная карта. Нужно сопоставить их со своим протоколом и внедрить соответствующие меры. Создать внутренние красно-синие команды для поиска уязвимостей, использовать AI-агентов для активного поиска дыр. Это — базовая практика в индустрии.

Встроенные аварийные полномочия

В модели голосования права изначально сосредоточены в мультиподписных кошельках команды, затем постепенно распределяются. Даже при широком распространении токенов — права часто концентрируются в нескольких кошельках, иногда — в одном. В случае взлома — протокол может рухнуть. Рекомендуется использовать защитные кошельки с ограниченными правами: только для приостановки протокола; в крайних случаях — при наличии 4 из 7 подписей, можно перевести полномочия на заранее подготовленный резервный кошелек. Защитные кошельки не имеют права инициировать или проводить голосования.

Так создается независимый аварийный уровень: он может восстанавливать стабильность, но не заменяет госконтроль. Вероятность взлома 4 из 7 — низкая из-за распределенности адресов. После зрелости системы и децентрализации — этот уровень можно отключить.

Кошельки и ключи

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

Планирование баг-баунти

Поддерживаю мнение Nascent о баг-баунти. Проекты с достаточным финансированием должны устанавливать очень высокие вознаграждения, пропорциональные TVL — даже при небольшом объеме. Минимум — семь цифр. В случае атаки государственными уровнями — переговоры о вознаграждении вряд ли помогут; лучше — создать программу «белых хакеров», разрешая им защищать украденные средства и получать часть вознаграждения. Это — способ переложить часть затрат на хранителей.

Выбор аудиторов

Раньше я думал, что с ростом возможностей ИИ ценность традиционного аудита снижается, но сейчас — считаю иначе:

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

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

Обеспечение безопасности эксплуатации

Внедрять безопасность в ключевые показатели эффективности. Регулярно проводить фишинг-учения; привлекать внешние red team для тестирования социальной инженерии. Иметь запасные кошельки и оборудование, чтобы быстро заменить всю систему мультиподписей — избегая спешных решений при кризисе.

/ 05 Смягчение потерь

Лимит выхода средств — максимум ущерба

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

Белые и черные списки

Большинство протоколов имеют скрытые списки вызываемых интерфейсов, активов и разрешенных адресов, а также запрещают определенные действия. Даже если правила скрыты — их нужно формализовать. После определения белых и черных списков можно вводить двухэтапные изменения прав, усложняя атаки. Злоумышленник должен сначала изменить списки или убрать ограничения, а затем выполнить вредоносные действия. Такой двойной контроль усложняет атаки: сначала — проверка входа (интеграция/вывод), затем — обход ограничений (риски, проверки).

/ 06 Восстановление контроля

Автоматический мониторинг алгоритмами

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

Остановить — и потом анализировать

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

Создать оперативный штаб

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

• Руководитель решений: управляет всей ситуацией
• Операторы: выполняют скрипты защиты, отключения
• Аналитики: восстанавливают цепочку атаки, ищут причины
• Связь с внешними партнерами
• Ведущий документации: фиксирует все события и решения

Все — по четкому плану, тренированны, готовы к действиям.

Прогнозирование цепных рисков

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

Запланировать преемственность

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

Перед обновлением — тестировать

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

/ 07 Восстановление после инцидента

Быстрые действия

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

Переговоры и договоренности

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

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