ChainDrop: подтверждённое происхождение в 400+ npm-пакетах и хуки Claude Code, не требующие npm install

В день 4 августа 2026 года злоумышленники захватили учетную запись GitHub, за которой стоит keyv — библиотека кэширования, которая, по данным Elastic Security Labs, в предыдущем месяце была скачана более 600 миллионов раз. Wiz Research и Orca Security обе сообщают, что вредоносные файлы были отправлены напрямую в основную ветку keyv и что собственный рабочий процесс GitHub Actions проекта затем собрал и опубликовал отравленный релиз, поэтому он попал в npm с валидным подтверждением происхождения, которое инструментарий аттестации цепочек поставок использует, чтобы определить, заслуживает ли пакет доверия. Самораспространяющийся червь, которого исследователи называют ChainDrop, затем использовал украденные npm-токены, чтобы повторить этот трюк с пакетами других мейнтейнеров: Elastic насчитала более 400 уникальных пакетов к 6 августа, Microsoft Threat Intelligence описала ту же кампанию 4 августа, а Агентство кибербезопасности Сингапура насчитало более 1300 скомпрометированных версий пакетов с совокупным объемом скачиваний 2 миллиарда в месяц. Elastic и Microsoft обе описывают хуки, которые повторно запускаются, когда репозиторий открывается в Claude Code или Visual Studio Code. Полный список источников записи, оценка серьезности и оценка уверенности находятся в архиве инцидентов ИИ, рядом с другими записями о цепочках поставок npm и инструментов разработки, зарегистрированными вокруг нее.

Как легитимный конвейер выпуска подписал собственную компрометацию

Wiz Research восстанавливает первые минуты: с 09:00 UTC 4 августа злоумышленник использовал скомпрометированную учётную запись, чтобы внедрить полезные нагрузки для закрепления в IDE в репозиторий keyv, а затем вскоре опубликовал новую версию keyv, содержащую эту полезную нагрузку. Wiz называет скомпрометированную сторону учётной записью мейнтейнера GitHub и говорит, что за этим последовали несколько пакетов в экосистеме keyv и cacheable.

Оперативный разбор Orca Security подробнее описывает процесс подписания. По его словам, злоумышленник отправил два вредоносных файла — setup.mjs и Math_Symbol.js — напрямую в основную ветку и сразу выпустил новые релизы. Поскольку эти релизы собирались через рабочие процессы GitHub Actions скомпрометированной учётной записи, отравленные версии были опубликованы в npm с действительными подписями происхождения, обойдя стандартные проверки целостности цепочки поставок. Zscaler ThreatLabz — независимая исследовательская группа, не входящая в число источников, цитируемых в материале, — приходит к тому же выводу и даже указывает уровень: вредоносный keyv 6.0.0 имел действительное SLSA Build Level 3 происхождение, поскольку злоумышленник контролировал исходный репозиторий. BleepingComputer, сообщивший о кампании в тот же день, фиксирует тот же механизм — вредоносные файлы отправлены напрямую в основные ветки проектов, новые релизы сгенерированы, действительное подтверждение происхождения, поскольку сборки выполнялись через легитимные рабочие процессы GitHub Actions.

Анализ Microsoft добавляет деталь, которая выглядит как противоречие, но таковой не является. На этапе распространения червя Microsoft Threat Intelligence обнаружила, что у многих вредоносных версий не было соответствующего коммита в исходном коде, пул-реквеста, тега или легитимного релиза, что указывало на то, что злоумышленники изменяли и публиковали tar-архивы пакетов напрямую, а не компрометировали каждый публичный репозиторий исходного кода. В совокупности источники описывают два режима подписи в рамках одной кампании: первые релизы keyv прошли через настоящий CI-конвейер жертвы и несут аттестации, подтверждающие их подлинность, тогда как более поздние релизы червя в основном собирались и публиковались с использованием украденных токенов реестра, не оставляя вообще никаких следов в исходном коде. Собственное наблюдение Microsoft состоит в том, что схема прямой публикации tarball объясняет, почему вредоносные релизы часто выглядели как обычное увеличение номера патч-версии без соответствующих коммитов в исходном коде или пул-реквестов.

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

Что запускается при npm install: preinstall, Bun 1.3.13 и коллектор с 300 паттернами

Elastic Security Labs описывает триггер как preinstall-хук в package.json, который злоупотребляет легитимной функцией npm, выполняющей произвольные команды до завершения установки пакета и не требующей какого-либо дальнейшего взаимодействия со стороны жертвы. Хук запускает setup.mjs, который проверяет, присутствует ли уже среда выполнения JavaScript Bun. Если её нет, дроппер определяет платформу и архитектуру машины, скачивает Bun v1.3.13 с официальной страницы релизов, распаковывает его, использует для выполнения полезной нагрузки, а затем удаляет временный каталог, чтобы замести следы. Wiz независимо выявила юзер-агент Bun/1.3.13, совершающий вредоносные вызовы. Дроппер является кроссплатформенным и ориентирован на Linux, macOS и Windows.

Полезная нагрузка сильно обфусцирована, а источники немного расходятся в оценке её размера: Elastic оценивает её в 711 килобайт, а Orca Security — в 728 КБ. В ней используется уплощение потока управления и схема кодирования строк Base91, а также строки в тематике «Дюны» — laza, kanly, ghola, mentat, lasgun, sietch, fedaykin, tleilaxu, sandworm, sardaukar, ornithopter, navigator — которые, как отмечает Elastic, имеют сходство с более ранними кампаниями Shai-Hulud.

Описание поведения от Microsoft добавляет две детали, которые стоит учитывать. Полезная нагрузка сначала проверяет своё окружение и завершает работу в русскоязычных системах, избегает дублирующихся экземпляров и запускает отдельную фоновую копию на рабочих станциях разработчиков; в среде CI она остаётся привязанной к активному заданию, чтобы получить доступ к секретам рабочего процесса, учётным данным runner и разрешениям на публикацию через OpenID Connect.

Именно благодаря сборщику этот инцидент становится историей об инструментах ИИ, а не типовой историей об учётных данных. Elastic сообщает, что он сканирует более 300 уникальных шаблонов в хранилищах учётных данных на машине разработчика и что примечательный таргетинг нацелен на учётные данные инструментов ИИ: Anthropic, Claude, Codex, Cursor, OpenAI и Gemini. Он также собирает учётные данные AWS, GCP, Azure и Alibaba Cloud, персональные токены доступа GitHub, токены JWT и токены сеансов, токены HashiCorp Vault, приватные ключи SSH, токены сервисных учётных записей Kubernetes и токены npm. Wiz сообщает, что список целей был расширен почти на 70% по сравнению с более ранним кодом Mini Shai-Hulud, на котором он основан; среди новых добавлений — хранилища учётных данных ИИ-агентов для Claude, OpenAI, Codex, Cursor и Gemini, криптовалютные хранилища ключей для Foundry, Solana и Monero, master.key Jenkins, секреты Argo CD и Harbor, конфигурации CLI Alibaba и Tencent, а также /etc/shadow.

И Microsoft, и Elastic описывают одну и ту же схему эксфильтрации. Результаты сериализуются в JSON, сжимаются gzip и шифруются случайно сгенерированным ключом AES-256-GCM, а этот ключ оборачивается открытым ключом RSA атакующего. Полезная нагрузка не содержит жёстко зашитый домен командного управления: по данным Elastic, она обращается к смарт-контракту Ethereum по адресу 0xE1f2395ee43e45A1556EC6438a88c31B83493103 чтобы получить текущий эндпоинт во время выполнения, так что инфраструктуру можно менять, не затрагивая вредоносное ПО. Если это не сработает, она ищет криптографически подписанный маркер — thebeautifulmarchoftime — в истории коммитов GitHub и проверяет домен по встроенному ключу RSA. Если оба способа не срабатывают, она эксфильтрирует данные через публичный репозиторий GitHub, который создаёт собственный аккаунт жертвы, с описанием "Shai-Hulud: Here We Go Again". Microsoft отмечает, что один из резервных путей кодирует украденный GitHub-токен с помощью двойного Base64, а не шифрует его.

Распространение зависит от качества токена. Elastic сообщает, что червь активируется, только когда сканирование учётных данных находит npm-токен с правом на запись пакетов и возможностью публиковать без двухфакторной аутентификации; затем он скачивает последний tarball каждого пакета, доступного для записи, внедряет себя, повышает патч-версию и публикует заново. BleepingComputer добавляет, что каждый токен проверяется в реальном времени через эндпоинт whoami реестра, прежде чем его похитят. Именно эта процедура превратила одну скомпрометированную учётную запись в сотни релизов, и поэтому вредоносные версии выглядят как обычные обновления патч-версии.

Путь заражения, для которого не требуется npm install

Вывод, который отличает эту кампанию от более ранних npm-червей, состоит в том, что установка больше не является единственным способом проникновения. Elastic описывает два дополнительных пути выполнения, ориентированных на пользователей инструментов для AI-кодинга.SessionStart — хук в .claude/settings.json, который запускает node .claude/setup.mjs, когда начинается новая сессия Claude. Для VS Code задача folderOpen в .vscode/tasks.json запускает node .vscode/setup.mjs, когда открывается зараженный репозиторий. Анализ Microsoft перечисляет те же четыре артефакта — .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json и .vscode/setup.mjs — и описывает их как вторичный путь заражения, который может перезапустить полезную нагрузку после завершения первоначальной установки через npm.

Условие, которое резко расширяет эту проблему, кроется в похищенных учётных данных. Когда среди них оказывается токен GitHub App, Elastic сообщает, что червь коммитит вредоносные хуки в до 50 веток в каждом доступном репозитории, внедряя .claude/settings.json и .vscode/tasks.json в каждую из них. Вывод Elastic таков: разработчик, который клонирует одну из этих веток и открывает её, может заразиться уже при открытии проекта — на этом пути нет ни установки пакетов, ни, следовательно, какой-либо защиты на уровне скриптов установки.

Оценка Zscaler такова, что хуки персистентности переживают удаление пакета и повторно выполняются просто при открытии проекта в VS Code или Claude Code, что обходит меру защиты --ignore-scripts, которую многие команды приняли после более ранних npm-червей. Отсюда прямо следует рекомендация: рассматривать файлы конфигурации IDE и AI-агентов — .claude/, .cursor/, .vscode/, .gemini/ — как исполняемый код, проверяемый с той же строгостью, что и исходный код.

Есть отпечаток для части атаки, связанной с репозиторием. Elastic сообщает, что коммиты, созданные червём, можно опознать по имени автора claude и сообщению коммита chore: update config, а Wiz фиксирует ту же строку сообщения. Elastic добавляет, что сообщение коммита также содержало украденный токен GitHub вместе с устрашающей строкой — IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients — которую она интерпретирует как попытку запугать разработчиков, чтобы те не отозвали токен. Wiz фиксирует ту же строку в исходных коммитах, при этом более короткое сообщение подставляется в коммитах, которые вводят хуки IDE.

Подсчёты не совпадают, и это не противоречие.

Каждая опубликованная цифра радиуса поражения привязана к отдельной единице измерения, и эти единицы не взаимозаменяемы. Elastic Security Labs в публикации от 6 августа насчитала более 400 уникальных npm-пакетов заражёнными. Microsoft Threat Intelligence описала более 400 пакетов у множества не связанных между собой издателей. Aikido, по данным BleepingComputer, оценила этот показатель в как минимум 868 пакетов в 1 381 версии. Orca Security сообщает о 10 непосредственно заражённых пакетах keyv и cacheable с более чем 619 млн ежемесячных загрузок, а затем 868 дополнительных пакетов и 1 381 версию, до которых добрался червь, что в совокупности составляет более 2 млрд ежемесячных установок. Консультативный документ CSA Сингапура AD-2026-009, датированный 6 августа, фиксирует более 1 300 заражённых версий пакетов представляющих в совокупности 2 млрд ежемесячных загрузок.

Это три разных знаменателя — пакеты, версии пакетов и месячный объём загрузок, — взятые в три разных момента времени кампании, которая всё ещё продолжалась. Описание Zscaler, касающееся скорости, объясняет, почему они расходятся: в нём говорится, что червь самораспространился на более чем 400 пакетов менее чем за четыре часа и в пиковый момент выпускал примерно один заражённый пакет в секунду. Считать более позднее число исправлением более раннего было бы неверно; каждое из них — это снимок на определённый момент, и ни один из цитируемых источников не заявляет об итоговом числе.

Показатели распространённости Elastic на уровне библиотек — это те данные, которые цитируют чаще всего и которые наименее неоднозначны. По сообщению Elastic, только keyv за предыдущий месяц скачали более 600 миллионов раз, flat-cache — почти 580 миллионов, cacheable-request — более 137 миллионов, cacheable — более 30 миллионов, cache-manager — более 16 миллионов. В рекомендациях CSA перечислены конкретные скомпрометированные версии, среди них keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cacheable 2.5.1, cache-manager 7.2.10, @cacheable/utils 2.5.1 и ecto 5.0.1.

Ловушка аннулирования

Специалисты по реагированию, установившие затронутую версию, после первой проблемы сталкиваются со второй. Elastic сообщает, что в условном резервном пути GitHub полезная нагрузка пытается установить компонент мониторинга токена, который поддерживает доступ к учетным данным и содержит деструктивный обработчик, срабатывающий при отзыве отслеживаемого токена. Zscaler подробно описывает механизм работы и называет его ловушкой отзыва токена: червь устанавливает фоновый процесс, который каждые 60 секунд опрашивает API GitHub с украденным токеном, и если токен возвращает ошибку 4xx — то есть жертва отозвала его — срабатывает вторичная деструктивная полезная нагрузка, которая в зависимости от варианта может включать удаленное выполнение кода или удаление домашнего каталога пользователя.

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

Практическое следствие фиксируют BleepingComputer и цитируемые им рекомендации Aikido: рабочую станцию разработчика или CI/CD-раннер, на которых была установлена затронутая версия, следует считать скомпрометированными даже если пакет был впоследствии удалён, потому что выполнение второй стадии могло привести к раскрытию токенов и подрыву целостности сборки. Рекомендации Microsoft приходят к тому же выводу со стороны сборки, предупреждая, что организациям, которые установили затронутый пакет с включёнными скриптами жизненного цикла, следует считать рабочую станцию или раннер сборки потенциально скомпрометированными и пересобрать затронутые системы и нижестоящие артефакты из доверенных источников.

Что установлено, что оценивается и что никто не показал

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

• Аккаунт GitHub мейнтейнера keyv был скомпрометирован, и вредоносные файлы были помещены напрямую в main до публикации релиза, 4 августа 2026 года — об этом согласованно сообщили Wiz, Orca Security, BleepingComputer и CSA Singapore.

• По меньшей мере keyv 6.0.0 попал в npm через собственный CI-конвейер жертвы с действительными данными о происхождении, при этом Zscaler указывает на аттестацию SLSA Build Level 3. Это утверждение и делает инцидент примечательным, и оно подтверждается тремя организациями, которые не были соавторами работ друг друга.

Хук предустановки выполнил setup.mjs, который скачал Bun v1.3.13 и запустил обфусцированную полезную нагрузку, сканировавшую более 300 шаблонов учётных данных, включая учётные данные инструментов ИИ для программирования — Elastic и Wiz согласны как в отношении версии среды выполнения, так и в отношении списка целевых учётных данных ИИ.

Хуки, записанные в .claude/settings.json и .vscode/tasks.json, выполняются при запуске сессии и при открытии папки, а токен GitHub App расширил это до 50 веток в каждом доступном репозитории — находка Elastic и основание для её заявления о том, что разработчик может быть заражён при открытии репозитория.

• Более 400 уникальных пакетов были скомпрометированы в течение нескольких дней, а CSA Singapore, национальный регулятор, 6 августа 2026 года опубликовал advisory AD-2026-009 с перечнем затронутых версий и индикаторов.

Что источники рассматривают как оценку, а не как факт, следует обозначать. Wiz описывает полезную нагрузку как потомка семейства вредоносного ПО «Mini» Shai-Hulud, созданного на основе публичных репозиториев Shai-Hulud-Open-Source, опубликованных TeamPCP, с несколькими ключевыми изменениями; Orca Security приписывает атаку TeamPCP; Zscaler связывает ChainDrop с TeamPCP и относит его к линии происхождения, ведущей начало с сентября 2025 года. Это консенсус вендоров по атрибуции, а не то, что цитируемый первичный документ доказывает в отношении названного лица или группы.

Три вещи, которых не устанавливает ни один из цитируемых источников и которые этот материал не восполняет. Во-первых, какбыла захвачена учётная запись мейнтейнера: Zscaler прямо заявляет, что точный механизм на момент его анализа был неизвестен. Во-вторых, единого итогового числа: цифры 400, 868 и 1 300 подсчитывают пакеты, «пакеты и версии» и версии в разные моменты времени, и ни один источник не утверждает, что кампания завершена. В-третьих, и это самое важное для утверждения об ИИ в этой записи, ни один цитируемый источник не сообщает о подтверждённом случае, когда украденные учётные данные Anthropic, Codex, Cursor, Gemini или OpenAI были воспроизведены при обращении к учётной записи провайдера. Документированы намерение и возможности — явный список целей и сборщик, созданный для того, чтобы до них добраться, — а не подтверждённый последующий взлом систем ИИ-провайдера.

Что изменилось после — и что должен делать реагирующий

Наиболее конкретное средство в записи — изменение платформы. Elastic рекомендует обновиться до npm 12 или более поздней версии, которая по умолчанию блокирует хуки preinstall; руководство Microsoft независимо рекомендует npm CLI v12 и функцию min-release-age, которая задерживает новые версии достаточно долго, чтобы сообщество успело обнаружить компрометацию до того, как она попадёт в сборку.

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

• Elastic: отозвать все токены GitHub, включая сессионные токены, на затронутых машинах; отозвать и перегенерировать токены npm, особенно токены автоматизации с правами записи и обходом двухфакторной аутентификации; проверить репозитории на наличие несанкционированных коммитов с сообщением `chore: update config from claude@users.noreply.github.com`; сменить секреты cloud, Kubernetes, Vault, AI-tooling и CI/CD; включить двухфакторную аутентификацию для аккаунтов npm.

• Microsoft: очистите кэши npm и yarn на затронутых конечных точках и сборочных хостах, закрепите известные безопасные версии, проверьте файлы блокировки и артефакты на наличие скомпрометированных версий, включая транзитивные ссылки, пересоберите общие базовые образы и эталонные сборочные раннеры, а также проверьте области действия токенов, утверждения рабочих процессов и происхождение релизов, поскольку инцидент согласуется со злоупотреблением конвейером CI/CD посредством публикации через OIDC.

• CSA Singapore: удалить затронутые версии из сред разработки, сборки и CI/CD, рассматривать затронутые системы как скомпрометированные и пересобрать их, сменить учётные данные, проверить облачные среды и среды исходного кода на предмет несанкционированного доступа, отслеживать опубликованные индикаторы, а также усилить механизмы белых списков, проверки целостности и контроля происхождения.

• Zscaler: относитесь к .claude/, .cursor/, .vscode/ и .gemini/ как к исполняемому коду и перестаньте считать происхождение SLSA или Sigstore доказательством безопасности — вместо этого дополняйте его обнаружением аномалий в поведении при публикации, таких как публикация в нерабочее время, массовая публикация версий и публикация авторами, делающими это впервые.

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

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