4 августа 2026 года червь ChainDrop распространил вредоносный код как минимум через 444 npm-пакета и 2212 версий, включая Keyv, flat-cache и file-entry-cache. Атака похищала токены npm, GitHub и облачных сервисов, а затем автоматически выпускала новые заражённые версии от имени легитимных разработчиков. Самая тревожная деталь связана с происхождением сборок: часть релизов получила действительные подтверждения SLSA provenance через штатные GitHub Actions.
ChainDrop превратил обычное обновление зависимости в точку входа
Установка небольшой JavaScript-зависимости обычно выглядит рутинно: менеджер пакетов загружает архив, выполняет служебные сценарии и добавляет библиотеку в проект. В случае ChainDrop эта привычная цепочка запускала setup.mjs ещё до завершения команды npm install.
Microsoft Security Research описывает кампанию как крупную атаку на цепочку поставок npm. Вредоносные релизы содержали вариант Mini Shai-Hulud — самораспространяющийся червь для кражи учётных данных. Его крупный обфусцированный модуль работал через среду Bun и искал секреты на компьютерах разработчиков и в системах непрерывной сборки CI/CD.
По данным StepSecurity, всплеск публикаций пришёлся на период с 09:40 до 13:20 UTC 4 августа. К 18:10 UTC исследователи насчитали 444 затронутых пакета и 2212 заражённых версий. Цифры отражают конкретный момент активного расследования, поэтому поздние оценки могут различаться.
Среди первых подтверждённых носителей оказались пакеты с огромной аудиторией:
| Пакет | Заражённая версия | Еженедельные загрузки по оценке StepSecurity |
keyv | 6.0.0 | более 153 млн |
flat-cache | 6.1.24 | около 149,9 млн |
file-entry-cache | 11.1.6 | около 147,6 млн |
cacheable-request | 13.0.20 | около 34 млн |
cache-manager | 7.2.10 | около 4,3 млн |
Эти библиотеки редко видны конечному пользователю. Они работают глубоко внутри инструментов сборки, кэширующих модулей и других пакетов. Проект мог получить заражённую версию через косвенную зависимость, даже когда разработчик никогда не добавлял Keyv или flat-cache вручную.
Украденный токен запускал новую волну публикаций
ChainDrop распространялся по принципу цифровой цепной реакции. После запуска вредоносный модуль собирал переменные окружения, файлы конфигурации, историю командной оболочки, SSH-ключи и данные из памяти GitHub Actions Runner.
Затем червь проверял найденные учётные данные через API сервисов. В отчёте Microsoft перечислены npm, GitHub, Amazon Web Services, Kubernetes и HashiCorp Vault. Получив рабочий npm-токен с правом публикации, ChainDrop просматривал доступные пакеты, загружал их последние архивы, внедрял свои файлы, увеличивал номер патч-версии и публиковал результат.
Так один скомпрометированный аккаунт сопровождающего открывал путь к нескольким библиотекам. Каждый новый заражённый пакет попадал на рабочие станции и сборочные серверы следующей группы разработчиков, где цикл повторялся.
StepSecurity разделяет обнаруженные релизы на две группы. Первая включала 11 полных носителей червя из экосистемы сопровождающего Keyv. Вторая охватывала ещё 433 пакета и 2201 версию, перепубликованные автоматикой после кражи учётных данных.
Почему распространение заняло считаные часы? npm-пакеты часто обновляются автоматически в рамках допустимого диапазона версий. Патч-релиз с новым последним числом выглядит привычно, а CI/CD загружает его сразу после публикации.
Действительная provenance не гарантировала чистоту релиза
В этой кампании сработал парадокс доверенной сборки. Некоторые заражённые версии прошли через штатные GitHub Actions и получили действительные сведения о происхождении — provenance. Такая запись подтверждает, какой репозиторий и какой процесс создали пакет.
ChainDrop показал границу этого механизма. Когда злоумышленник контролирует GitHub-аккаунт, ветку, тег или сам рабочий процесс публикации, инфраструктура честно подтверждает происхождение созданного ею файла. Криптографическая отметка сохраняет достоверность процесса, хотя исходный процесс уже оказался захвачен.
StepSecurity связывает первые релизы с npm OIDC Trusted Publishing и подтверждениями уровня SLSA. Microsoft отдельно указывает, что публикации через доверенный GitHub Actions OIDC могли сохранять валидную provenance.
Для команд, которые считали наличие provenance достаточным фильтром, картина изменилась. Проверка происхождения по-прежнему показывает подмену архива вне официальной сборки, однако она не распознаёт вредоносное изменение внутри захваченного репозитория или workflow.
Ethereum помогал червю менять адрес управляющего сервера
Название ChainDrop связано с применением блокчейна в инфраструктуре управления. Вредоносный модуль обращался к смарт-контракту Ethereum и получал актуальный адрес сервера для передачи данных. Исследователи называют такую технику EtherHiding.
Жёстко прописанный домен легко заблокировать после обнаружения. Запись в блокчейне позволяет оператору менять конечный адрес через транзакцию, сохраняя первоначальную логику внутри вредоносного файла. На момент анализа Microsoft контракт возвращал домен npm-cache[.]com; среди предыдущих значений фигурировали pypi-get[.]com и js-mirror[.]com.
Собранные данные упаковывались в JSON, сжимались и шифровались алгоритмом AES-256-GCM. Ключ AES защищался открытым RSA-ключом злоумышленника. Основным каналом служил HTTPS-сервер, резервным — публичный репозиторий GitHub со специальным описанием.
Блокчейн в этой схеме не хранил похищенные секреты. Он работал как устойчивый указатель на текущий сервер, усложняя быстрое отключение инфраструктуры одной блокировкой домена.
Claude Code и VS Code стали дополнительным маршрутом закрепления
ChainDrop выходил за пределы каталога node_modules. Microsoft обнаружила код, который мог добавлять файлы в каталоги .claude и .vscode внутри доступных репозиториев, включая settings.json, tasks.json и дополнительные сценарии запуска.
Такой механизм создавал второй маршрут исполнения. Вредоносная программа могла снова активироваться во время работы с Claude Code или Visual Studio Code после завершения исходной установки npm-пакета.
В отчёте упомянуты и попытки закрепления через конфигурации GitHub Copilot. Разработческие ИИ-инструменты здесь выступали частью среды выполнения: автоматические задачи, настройки проекта и сценарии инициализации давали червю новые точки запуска.
Исследователи зафиксировали ещё одну особенность: вредоносный код завершал работу в системах с русской локалью. Подобные проверки встречаются в кампаниях, где оператор снижает риск внимания со стороны правоохранительных органов определённых стран. Публичной атрибуции ChainDrop конкретной группе на момент публикации отчётов нет.
Установка затронутой версии приравнивается к возможной компрометации среды
Microsoft рассматривает рабочую станцию или CI/CD runner, где выполнился заражённый пакет с разрешёнными lifecycle-скриптами, как потенциально скомпрометированную систему. Причина связана с широтой доступа: червь собирал секреты из файлов, окружения, памяти runner и внешних хранилищ.
В опубликованном разборе Microsoft перечисляет действия для реагирования на инцидент: проверку lock-файлов и кэшей, отзыв токенов, смену секретов с чистого устройства, пересборку систем и артефактов из доверенной основы. Отдельно рассматриваются общие образы CI, поскольку заражённый кэш мог переходить между заданиями.
Список индикаторов включает файлы setup.mjs, Math_Symbol.js, Math_init.js, домены управляющей инфраструктуры и SHA-256-хэши обнаруженных образцов. Одного удаления пакета из package.json недостаточно для оценки последствий уже выполненного кода: к моменту завершения установки секреты могли покинуть систему, а конфигурации репозитория — измениться.
Для бизнеса человеческий угол выглядит довольно приземлённо. Одна зависимость способна затронуть ноутбук разработчика, автоматическую сборку, реестр пакетов, облачный аккаунт и выпущенные компанией артефакты. Расследование поэтому охватывает одновременно конечные устройства, CI/CD, GitHub, npm и облачные журналы.
Масштаб ChainDrop остаётся движущейся величиной
К 18:10 UTC 4 августа StepSecurity подтверждала 444 пакета и 2212 версий, а Microsoft говорила о более чем 400 пакетах у разных издателей. Разница в последующих публикациях связана со временем снимка, способом подсчёта пакетов и версий, а также продолжающимся выявлением новых релизов.
Точно известно, что ChainDrop использовал популярные зависимости, автоматическую публикацию и украденные учётные данные для быстрого расширения охвата. Подтверждён и механизм кражи секретов из npm, GitHub, облачных платформ, Kubernetes и Vault.
Пока остаются открытыми несколько вопросов. До сих пор не известен полный перечень систем, в которых успел сработать вредоносный код. Публично не озвучен точный метод первоначального захвата аккаунта сопровождающего Keyv. Также неясен объём дальнейшего применения украденных облачных ключей после их передачи оператору.
История ChainDrop перевернула представления о доверенной цепочке выпуска. Даже если в заражённом релизе есть подписанная сборка, привычный патч-номер и известное имя пакета, это не гарантирует его безопасность. Пока неизвестно, как быстро npm, GitHub и создатели инструментов provenance обновят защитные механизмы после этой кампании.
