Взлом rsETH от Kelp DAO. Часть I. Позиция Layer Zero: перевод и комментарий

Перевод

Это вольный перевод: x.com/LayerZero_Core/status/2046081551574983137, который снабжён (в основном - в конце) моими комментариями.

Заявление об инциденте KelpDAO

18 апреля 2026 года KelpDAO подвергся эксплоиту примерно на $290 млн.

Предварительный анализ указывает на высокотехнологичного государственного атакующего, вероятно группу Lazarus Group (конкретно - TraderTraitor).

Инцидент был локализован исключительно в конфигурации rsETH, и его причиной стала архитектура с одним DVN (single-DVN setup).

Никакого заражения (contagion) других активов или приложений нет.

Механика атаки

Целью атаки стало:

• отравление (poisoning) downstream RPC-инфраструктуры
• используемой DVN от LayerZero Labs

В результате:

• DVN начал принимать поддельные cross-chain сообщения
• атакующий смог минтить фейковые rsETH

После инцидента:

• все скомпрометированные RPC-ноды (были) отключены
• инфраструктура заменена
• DVN снова работает в нормальном режиме

Контекст: архитектура безопасности LayerZero

LayerZero использует модульную безопасность:

• DVN (Decentralized Verifier Networks) - независимые валидаторы сообщений;
• Каждое приложение само выбирает конфигурацию безопасности.

Важно! Нет "дефолтной" безопасности и всё зависит от настройки интегратора!

Что LayerZero рекомендует?

• использовать multi-DVN setup
• обеспечивать:
• diversity (разные провайдеры)
• redundancy (избыточность)

Нельзя при этом полагаться на один DVN → это single point of failure!

Почему произошёл эксплойт?

Конкретно у KelpDAO:

• конфигурация: 1-of-1 DVN
• единственный валидатор: LayerZero Labs

Последствия:

• не было второго валидатора
• никто не проверил поддельное сообщение
• система доверяла одному источнику → он был скомпрометирован

Итог: поддельные cross-chain сообщения прошли как валидные

Почему нет contagion?

Во-первых, проблема была не в протоколе LayerZero, а в конкретной настройке rsETH!

Другие приложения:

• используют multi-DVN;
• имеют redundancy;
• защищены от такого сценария.

[Прим. Menaskop: резонный вопрос о том, почему вообще позволили выставить 1-к-1, конечно же, не задан].

Так что произошло именно?

18 апреля 2026 года DVN от LayerZero Labs стал целью высокотехнологичной атаки, вероятно связанной с Lazarus Group (конкретно — TraderTraitor).

Атака была специально разработана для: манипуляции / отравления downstream RPC-инфраструктуры, которую DVN использует для проверки транзакций.

Важно:

• это не был эксплойт протокола
• не был взлом DVN
• не было компрометацией ключей

Как именно прошла атака?

Атакующий:

1. Получил доступ к списку RPC-нód, используемых DVN
2. Скомпрометировал 2 RPC-ноды
• они были независимыми
• работали в разных кластерах
• не были напрямую связаны
3. Подменил бинарники на нодах (op-geth)

Почему DVN не взломали напрямую?

Из-за принципа least privilege: атакующий не смог получить доступ к самим DVN-инстансам, (зато) использовал RPC как точку входа (pivot).

Ключевая техника: RPC spoofing

Атакующий запустил вредоносную ноду, которая:

• отправляла поддельные данные DVN
• но при этом:
• всем другим IP (включая мониторинг)
• возвращала реальные (честные) данные

То есть: DVN → получает фейк: все остальные → видят “правду”. Это позволило:

• обойти системы мониторинга
• скрыть аномалии

Payload атаки

Использовался кастомный payload, который:

• формировал поддельное сообщение
• минимизировал сигналы тревоги
• был специально заточен под DVN

Анти-детекция

Атака была очень продуманной:

• скрытие от observability-инфраструктуры
• избирательная подмена данных
• самоуничтожение:
• отключение RPC
• удаление бинарников
• очистка логов и конфигов

Но (и) этого было недостаточно! DVN использует:

• trust-minimized модель
• несколько RPC (внутренние + внешние)

Поэтому просто подмены RPC было недостаточно!

Финальный шаг: DDoS

Атакующий провёл DDoS на не-скомпрометированные RPC

В результате:

• система переключилась (failover)
• на скомпрометированные RPC

И только после этого поддельное сообщение прошло!

Коротко (суть атаки)

1. Компрометация части RPC
2. RPC spoofing (фейк только для DVN)
3. DDoS остальных RPC
4. Failover → poisoned RPC
5. DVN принимает фейковое сообщение

DDoS-атака на внешние RPC-ноды.

Попытка обращения к внешним RPC во время атаки

Внутренняя попытка обращения к внешним RPC в момент атаки

В результате этой манипуляции DVN, управляемый LayerZero Labs, подтвердил транзакции, которые на самом деле не происходили.

Проверка через RPC - фундаментальное ограничение всех оффчейн-сервисов, включая:

• мосты (bridges)
• биржи
• и другие инфраструктурные решения

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

Безопасность LayerZero Labs

Мы хотим подчеркнуть, через какую среду пришлось пройти атаке:

• полная система Endpoint Detection and Response (EDR) на каждом устройстве
• контроль доступа на уровне приложений
• полностью изолированные среды
• полное логирование систем
• выделенная внутренняя команда безопасности
• внешние security-подрядчики
• финальная стадия аудита/сертификации SOC2

Инфраструктура DVN:

• использует комбинацию:
• собственных RPC-нód
• внешних RPC-провайдеров
• чтобы ни один провайдер не был точкой отказа

Дополнительно:

• строгий контроль устройств
• политики доступа по принципу least privilege
• многоуровневая аутентификация
• регулярные проверки доступа

Дальнейшие действия (Path Forward)

• DVN от LayerZero Labs уже работает в штатном режиме
• приложения с multi-DVN конфигурацией могут безопасно продолжать работу

Важно:

• все проекты с конфигурацией 1/1 DVN получают рекомендации:
• перейти на multi-DVN с избыточностью
• DVN LayerZero Labs:
• не будет подписывать или подтверждать сообщения
• для приложений с конфигурацией 1/1

Расследование и меры

• LayerZero Labs взаимодействует с правоохранительными органами по всему миру и помогает:
• отслеживать средства
• совместно с партнёрами и Seal911

Ключевая позиция

Протокол LayerZero:

• работал корректно
• уязвимостей не обнаружено

Главный архитектурный вывод

Если бы система была:

• единым (монолитным) решением
  или
• системой с общей безопасностью

Заражение (contagion) могло бы быть масштабным, но благодаря: модульной безопасности LayerZero получилось:

• атака изолирована на одно приложение
• 0 заражения всей системы
• ни один другой OFT или OApp не пострадал

Итог

LayerZero подтверждает приверженность:

• безопасности
• целостности экосистемы

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

Доп. комментарии Menaskop

Конечно, разгильдяйство на $200M++ невозможно, но... оно случилось. И случилось оно потому, что одна сторона позволила,а другая - приняла безумные условия.

Т.е. мы не можем сказать, что Layer Zero не виновны, как и Kelp DAO. Но это лишь 1-я часть - итоги полные будут в конце, а пока всё и

До!