В npm-экосистеме зафиксирована крупная цепочка компрометаций: самораспространяющийся вредонос Shai Hulud внедрялся в сотни пакетов и автоматизировано заражал другие, используя украденные токены публикации и бэкооры в CI/CD. Под удар попали и пакеты в криптосфере — в частности, набор библиотек, связанных с Ethereum Name Service (ENS), которые суммарно получают десятки тысяч скачиваний еженедельно. Это создаёт высокий риск утечек секретов разработчиков, внедрения вредоносного кода в сборки фронтендов DEX/DeFi и последующего supply-chain заражения пользовательских систем. Разбираем архитектуру атаки, что именно ворует вредонос, кому это критично и что делать прямо сейчас.

Что случилось: масштабы и подтверждения из первоисточников

Исследователи несколько недель фиксируют «червеподобную» кампанию: злоумышленники получают доступ к аккаунтам мейнтейнеров (фишинг/угон токенов), выпускают новые версии модулей с вредоносными скриптами, а затем используют украденные секреты для автоматического заражения других пакетов того же автора. По оценкам разных команд, речь идёт о сотнях компрометированных пакетов (диапазон 180–500+), причём активность шла волнами. Официальные предупреждения уже публиковали как отраслевые CERT/агентства, так и крупные вендоры безопасности.

Отдельно отмечается новая «вспышка» атаки с затрагиванием экосистемных аккаунтов и пакетов, связанных с ENS Domains (в этом же контексте упоминались другие популярные организации и инструменты разработчика). Для крипто-рынка это важный сигнал: на кону не только доступ к репозиториям, но и риск «залить» вредонос в сборки dApp/инфраструктурных сервисов.

Почему это критично именно для крипто-экосистемы

В отличие от «обычных» npm-инцидентов, в крипте любой supply-chain компромисс часто напрямую бьёт по ключам, кошелькам и frontend-логике взаимодействия с Web3: вредоносные зависимости способны внедрять дополнительный код в бандлы, подменять обработчики событий кошелька, встраивать трекинг seed/приватных ключей, красть токены API и переменные окружения (включая ключи RPC-провайдеров, GitHub/NPM-токены, облачные креды). Уже задокументировано: Shai Hulud ориентирован на массовый сбор секретов разработчика (AWS/GCP/Azure, GitHub, npm), а также на самораспространение за счёт публикации компрометированных версий других пакетов. Это превращает атаку в «снежный ком», затрагивающий CI/CD, локальные машины и органы управления проектами.

Для команд DeFi/ENS-инфраструктуры ключевой риск двойной: (1) утечка секретов (доступ к репозиториям, токены публикации, ключи провайдеров) с последующим захватом цепочки поставки; (2) внедрение вредоносной логики в продовый бандл dApp/сервиса, что потенциально позволяет перехватывать пользовательские действия (адреса, подписи, транзакции) и перенаправлять их. Даже если вы не «храните криптоключи на диске», компрометированный билд-процесс и доступы к инфраструктуре создают условия для дальнейших атак на ваших пользователей.

Как работает Shai Hulud: этапы атаки по цепочке поставки

На основе отчётов исследователей картинка выглядит так:

1. Первичный доступ: злоумышленники угоняют токены публикации npm/GitHub у мейнтейнеров (через фишинг, вредонос в зависимостях, утечки секретов). Получив доступ, они выпускают «обновления» пакетов с полезной нагрузкой.
2. Исполнение на стороне разработчика/CI: вредонос активируется на этапе установки/сборки (через postinstall/скрипты или вложенные зависимости), собирает секреты и телеметрию.
3. Эксфильтрация и бэкдор: данные отправляются на контролируемые эндпоинты; нередко в репозитории добавляются скрытые GitHub Actions для устойчивости и дальнейшей эксфильтрации.
4. Самораспространение: используя похищенные токены, вредонос автоматизирует «троянизирование» других пакетов того же автора — модифицирует package.json, встраивает jаvascript-бандл, перепаковывает архив и публикует новый релиз.
5. Побочные эффекты: у некоторых жертв приватные репозитории становились публичными, что увеличивало поверхность утечек.

Эти этапы подтверждаются техническими разборками нескольких независимых команд (Sysdig, Sonatype, Truesec и др.), а также отраслевыми предупреждениями (CISA).

Что именно ворует вредонос: от облачных ключей до токенов публикации

Основная цель — секреты: облачные креды (AWS/GCP/Azure), токены GitHub (PAT, OAuth), npm-токены, SSH-ключи, переменные окружения CI. Отдельные варианты использовали сканеры секретов (по типу TruffleHog) прямо в пайплайне, вычищая токены и ключи из истории/логов, а затем эксфильтровали их через скрытые Actions/вебхуки. В контексте крипто-разработки это означает и повышенный риск доступа к RPC-эндпоинтам, провайдерам кошельков, внутренним API и любым локально хранимым ключам, если они оставались в окружении/файловой системе разработчика.

ENS и сопутствующие пакеты: почему это особая зона риска

В свежих апдейтах указывается, что волна Shai Hulud затронула и пакеты, связанные с ENS-экосистемой. У многих из них стабильный спрос (десятки тысяч недельных скачиваний), а значит высока вероятность «прокладки» вредоноса в реальный продовый трафик фронтендов и бэкендов. Для разработчиков ENS-интеграций это критично: компромисс в таких зависимостях способен привести к «тихим» модификациям резолверов/обработчиков адресов, внедрению сбора данных о пользователях и изменению UX кошельковых действий.

Кого это касается сильнее всех: профили риска

• DeFi/DEX фронтенды (сборки SPA/SSR): риск внедрения «невидимой» логики в бандл, перехват событий кошелька, подмена RPC-вызовов и трекинг приватных данных пользователей. Справка по DEX-моделям см. в нашей вики.
• ENS-интеграции в биржевых/кошельковых продуктах: подмена поведения резолверов, сбор telemetries, отравление кэшей.
• Команды с self-hosted CI/CD: повышенный риск «закрепления» через GitHub Actions/Runner-бэкдоры.
• Пакетные мейнтейнеры: после компромисса ваши пакеты станут следующими точками заражения.

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

Технику автоматической перепаковки, модификации package.json и встраивания локального скрипта подробно описывали исследовательские команды, отслеживавшие волну Shai Hulud.

Проверки и «гигиена» прямо сейчас: быстрый чек-лист

• Отключите авто-скрипты на время аудита: npm ci --ignore-scripts или глобально npm config set ignore-scripts true.
• Переустановите зависимости: удалите node_modules и package-lock.json (или pnpm-lock.yaml/yarn.lock) и соберите окружение заново.
• Просканируйте lock-файлы на предмет известных IOC-пакетов и аномалий версий (сверяйте по «живым» спискам от вендоров).
• Проверьте GitHub Actions: новые/изменённые воркфлоу, незнакомые вебхуки, секреты, environment-rules, блокировки по бранчам.
• Ревокните токены: GitHub PAT/OAuth, npm-tokens (перевыпуск, ограничение по правам), ключи провайдеров (AWS/GCP/Azure) — затем пересоберите кэш секретов в CI.
• Включите обязательную 2FA и org-enforced SSO для публикации/доступов, запретите long-lived токены, используйте OIDC-федерацию для CI.
• Соберите инвентарь зависимостей: где ENS-связанные пакеты, что тянется транзитивно в продовый бандл, какие версии попали в релизы последней недели.

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

Углублённые меры: как закрыть класс атак на горизонте 3–6 месяцев

1. Trusted Publishing/Provenance для npm: переходите на доверенную публикацию через GitHub (granular-токены, attestations, ограничения по источнику сборки), чтобы минимизировать риск «ручной» публикации с украденных токенов.
2. Эфемерные раннеры CI: изолируйте джобы, запретите общий кэш секретов, включите «required reviewers» и «environment protection rules» на продовые пайплайны.
3. Политика зависимостей: pin-версии (SemVer-диапазоны — только для dev), запрет авто-миноров без ручной ревизии, зависимость от «подписанных» релизов.
4. SAST/SCA с фокусом на скрипты: отдельные правила на lifecycle-hooks и подозрительные сетевые вызовы в postinstall.
5. Сегментация секретов: ключи RPC/кошельков/провайдеров в «минимально достаточном» наборе; ротация раз в 30–90 дней; аварийные плейбуки ревока/миграции.
6. Политика локальных машин: запрет хранения приватных ключей/seed в открытом виде на Dev-ноутах; обязательные аппаратные ключи (FIDO2) и шифрование диска; контроль менеджеров секретов.

Если вы мейнтейнер пакетов: минимум действий сегодня

• Немедленно ротация npm-токенов (включая automation-токены), перевод репозиториев на «protected branches», включение 2FA/SSO-Enforcement для всех контрибьюторов.
• Проверьте последние релизы на наличие нетипичных diff (скрипты, вызовы сети, добавленные файлы в tarball) и unpublish/deprecate с пометками, если есть подозрения.
• Пройдитесь по «org-level» GitHub Actions: запрет self-hosted без изоляции, ревизия секретов, запрет «reuse-workflow» из внешних org без разрешений.

Если вы крипто-команда (DEX/DeFi/ENS): усиленный режим

Для публичных фронтов важно выпустить прозрачный отчёт об аудитах зависимостей и сборок за последние 1–2 недели (что проверили, какие версии, где ротация ключей и что ещё в работе). Это не только снижает риски для пользователей, но и защищает репутацию проекта: в supply-chain-инцидентах скорость и открытость коммуникации уменьшает вторичные потери.

• Включите баннер-уведомление в dApp на 24–48 часов с ссылкой на отчёт и хэши последних «чистых» билдов.
• Пересоберите production-бандлы на «замороженном» наборе зависимостей, с отключёнными hooks и полностью новым кэшем.
• Проведите внеплановый allow-list review внешних скриптов/доменов и CSP (Content Security Policy).

Как понять, что вы уже пострадали: типичные «сигналы»

• Неожиданные публикации/релизы из вашего имени, которые вы не инициировали.
• В журналах GitHub — появления/редакции Actions без тикетов/кода-ревью.
• В CI — сетевые вызовы на незнакомые домены из шагов сборки, особенно в нестандартные шаги.
• RPS-пики на RPC/инфраструктурных ключах без роста трафика, а также «странные» запросы к кошелёк-провайдерам.

Что дальше по кампании: новые волны и «второй сезон»

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

FAQ: коротко о главном

Полезные ссылки

• Supply chain-атаки: базовые принципы и защита
• DeFi: архитектура и риски фронтендов