Что известно#
SANS ISC сообщает, что кампания TeamPCP в цепочке поставки оставалась активной до 2026-05-24 и за одну неделю расширилась сразу на несколько экосистем пакетов для разработчиков.
Зафиксированная активность затрагивает три разные поверхности доверия:
- вредоносная сборка расширения Nx Console для VS Code в Visual Studio Marketplace
- троянизированные версии официально опубликованного Microsoft пакета Azure Durable Functions Python SDK на PyPI
- крупная волна npm через экосистему @antv
Общая проблема — не одна уязвимая библиотека. Злоумышленники использовали легитимные каналы распространения. Учетные записи издателей, значки verified-publisher, экосистемы пакетов, автообновления и учетные данные CI/CD становились частью цепочки атаки.
SANS описывает это как три эскалации, уложившиеся в одну неделю. Самый серьезный заявленный результат — внутренний инцидент в GitHub: вредоносная сборка расширения названа корнем вторжения, после которого было эксфильтрировано около 3 800 внутренних репозиториев GitHub. В исходном материале сказано, что, по сообщениям, данные клиентских тенантов не пострадали.
Детали ниже основаны на дневнике SANS ISC и пересказанной там отчетности. Часть утверждений отнесена к независимым публикациям, но собранный текст не сохраняет все исходящие ссылки. Поэтому такие пункты стоит читать как опубликованные сообщения, а не как независимо проверенные здесь факты.
Взлом GitHub начался с отравленного расширения#
Первый крупный эпизод — расширение Nx Console для VS Code.
По данным источника, вредоносная сборка Nx Console v18.95.0 была опубликована в Visual Studio Marketplace 2026-05-18. Издателем был указан nrwl.angular-console. У расширения был значок verified-publisher и примерно 2,2 млн установок. По сообщениям, сборка оставалась доступной около 18 минут, после чего ее удалили.
Даже такого короткого окна хватило.
SANS пишет, что на рабочей станции сотрудника GitHub расширение автоматически обновилось именно в этот период. Вредоносная сборка эксфильтрировала секреты разработчика, а затем ее использовали для бокового перемещения во внутренней среде CI/CD GitHub. По данным источника, CISO GitHub Alexis Wales публично назвала расширение Nx Console корнем вторжения.
Сообщается, что до локализации инцидента было эксфильтрировано примерно 3 800 внутренних репозиториев GitHub. Среди последующих жертв, у разработчиков которых были включены автообновления, назывались OpenAI, Grafana Labs и Mistral AI.
Важен не только факт отравления популярного расширения. Важнее то, насколько мало барьеров оказалось между скомпрометированным каналом публикации и машинами разработчиков, которые доверяли потоку обновлений.
Значок verified-publisher не означал, что конкретный релиз безопасен. Он означал, что маркетплейс доверяет личности издателя. Похоже, TeamPCP использовала разрыв между этими двумя утверждениями.
Пакет Microsoft durabletask тоже был троянизирован#
Второй эпизод неприятнее, потому что речь шла об официально опубликованном Microsoft пакете.
Источник сообщает, что 2026-05-19 на PyPI были опубликованы три вредоносные версии Azure Durable Functions Python SDK от Microsoft — durabletask. Затронутые версии: 1.4.1, 1.4.2 и 1.4.3. У пакета, по описанию, было около 417 000 скачиваний в месяц.
Вредоносные версии, как сообщается, были yanked в течение нескольких часов. Но это не устраняет риск для команд, которые успели установить их в это окно.
По данным SANS, dropper был внедрен в исходные Python-файлы пакета. Это значит, что импорта SDK было достаточно для запуска вредоносного кода. В источнике не описаны ни особое поведение во время выполнения, ни отдельный ручной запуск как обязательное условие.
Сообщается, что второй этап нацеливался на учетные данные в основных разработческих и облачных средах, включая AWS, Azure, GCP, HashiCorp Vault, 1Password и Bitwarden. Источник также говорит, что независимая отчетность описывала payload второго этапа как содержащий Linux disk wiper.
Последний пункт важен, но с ним нужно быть аккуратным. В собранном источнике сказано, что payload, по сообщениям, содержал Linux disk wiper. Полного технического анализа в процитированном материале нет. Если это подтвердится, кампания выходит за пределы кражи учетных данных и распространения — в сторону более разрушительных действий.
Для защитников практический триггер достаточно ясен: если какая-либо среда установила durabletask 1.4.1, 1.4.2 или 1.4.3 2026-05-19, ее нужно считать затронутой. Это касается CI jobs, build containers, краткоживущих runners, ноутбуков разработчиков и тестовой инфраструктуры.
Эфемерность не делает среду безопасной. Краткоживущий runner все равно может утечь долгоживущий токен.
Волна @antv в npm показывает масштаб кампании#
Третий эпизод связан с экосистемой @antv в npm.
SANS сообщает, что 2026-05-19 скомпрометированная учетная запись maintainer, идентифицированная как atool, опубликовала третью волну Mini Shai-Hulud по пакетам @antv. Заявленное число — 639 вредоносных версий в 323 пакетах.
В затронутый набор входили echarts-for-react, у которого, по описанию, около 1,1 млн скачиваний в неделю, и size-sensor, у которого около 4,2 млн скачиваний в неделю.
Источник пишет, что это был крупнейший одночасовой всплеск Shai-Hulud по числу пакетов. Также отмечено, что 42 вредоносных пакета показывали поддельные значки Sigstore verification в UI npm.
Деталь со значками повторяет паттерн из случая с расширением VS Code. Сигналы безопасности и подлинности полезны, но это не то же самое, что целостность релиза. Интерфейс может выглядеть доверенно и при этом показывать вредоносный артефакт, если канал публикации скомпрометирован или сам сигнал доверия подделан.
В исходном материале сказано, что обфусцированный JavaScript payload запускался во время установки и собирал более 20 классов учетных данных, включая токены GitHub и npm, ключи AWS и облачные credentials. Вставленный текст обрывается до полного списка, поэтому здесь не стоит додумывать недостающие категории.
Защитный вывод прямой: install scripts в пакетах остаются каналом выполнения с высоким риском. Они запускаются ровно в тот момент, когда машины разработчиков и системы CI часто имеют доступ к секретам.
Почему это важно#
Эта кампания не только о вредоносных пакетах. Она о цепочке доверия.
Разработчик ставит пакет, потому что он приходит из знакомой экосистемы. Маркетплейс показывает verified publisher. CI runner импортирует официальный SDK. Расширение редактора автообновляется, потому что ему уже доверяли. Токен, украденный в одной волне, становится учетными данными для публикации в следующей.
Каждый шаг по отдельности выглядит правдоподобно. Вместе они дают путь атаки по цепочке поставки, который проходит через npm, PyPI, расширения VS Code, GitHub, облачные аккаунты и CI/CD.
Случай GitHub особенно важен, потому что описанная цепочка связывает ранее украденные учетные данные с последующей публикацией. Если это описание верно, TeamPCP не просто украла секреты. Она переиспользовала их, чтобы отравить новую точку распространения и добраться до более ценной среды.
Именно такую модель защитникам теперь стоит считать базовой: скомпрометированный токен — это не только риск доступа. Он может стать риском распространения ПО.
Что проверить прямо сейчас#
Начните с окон экспозиции и названий затронутых пакетов.
Для сред VS Code:
- проверьте, был ли Nx Console v18.95.0 установлен или автообновлен около 2026-05-18
- найдите рабочие станции разработчиков, на которых расширение было в заявленное 18-минутное окно
- ротируйте учетные данные, доступные этим машинам
- проверьте доступ CI/CD, связанный с этими пользователями или устройствами
Для Python-сред:
- проверьте, устанавливался ли
durabletask1.4.1, 1.4.2 или 1.4.3 2026-05-19 - считайте выполнение при импорте достаточным условием компрометации
- включите в поиск CI runners, containers, build images, caches и виртуальные окружения разработчиков
- ротируйте облачные, registry, vault и source-control credentials, которые могли присутствовать в среде
Для npm-сред:
- проверьте установки из экосистемы @antv около 2026-05-19
- изучите lockfiles и логи package manager на предмет заявленного всплеска вредоносных версий
- не полагайтесь только на UI badges как доказательство безопасности
- пересмотрите выполнение install-script в CI и рабочих процессах разработчиков
Во всех затронутых средах ротация учетных данных не должна ограничиваться самым очевидным токеном. По сообщениям, payloads нацеливались на developer identity, package publishing, cloud access, password managers и секреты CI/CD. Ротируйте все, до чего могла дотянуться среда, а не только то, что вредоносный пакет явно называл.
Чего не стоит утверждать сверх фактов#
Не считайте каждую установку этих проектов скомпрометированной. По исходному материалу проблема привязана к конкретным вредоносным версиям и узким окнам публикации.
Не утверждайте, что данные клиентов GitHub пострадали. Источник говорит, что, по сообщениям, данные customer-tenant не были затронуты.
Не делайте вывод, что программы verified-publisher бесполезны. Они решают часть задачи идентификации. Они не доказывают, что каждый будущий релиз безопасен.
Не думайте, что yanked packages закрывают инцидент. Они останавливают новые обычные установки. Но они не чистят старые build caches, среды разработчиков, CI images, private mirrors или артефакты, уже созданные во время окна экспозиции.
Практический урок уже и жестче: доверие во время установки должно проверяться на уровне релиза, а не только на уровне репутации издателя.