TeamPCP и операторы BreachForums начали продвигать конкурс для атак на open source-пакеты. Участникам предлагают использовать инструмент Shai-Hulud, компрометировать пакеты и присылать доказательства доступа вместе с форумным ником. Победителя обещают выбрать по охвату скомпрометированных пакетов: учитываются недельные и месячные загрузки, а несколько мелких компромиссов можно сложить в общий результат. Приз — $1 000 в Monero и форумная репутация.
На первый взгляд сумма выглядит почти смешной для такого уровня риска. Но суть не в деньгах. Конкурс работает как рекрутинг и публичная геймификация supply chain-атак: участникам дают инструмент, правила, таблицу очков и социальное одобрение в криминальной среде. Socket пишет, что такой формат снижает порог входа для менее опытных акторов и стимулирует не точечные атаки, а широкий «ковровый» поиск слабых пакетов.
Анонс конкурса появился на BreachForums от аккаунта, который связывают с владельцем форума. CyberPress пишет, что кампания была впервые подсвечена Dark Web Informer, а участникам предлагают использовать Shai-Hulud для компрометации open source-пакетов и предоставлять «разумные доказательства» доступа.
Скоринговая модель делает историю особенно опасной. Очки дают за популярность пакетов — по недельным и месячным скачиваниям. Чем чаще пакет используют разработчики, внедряют в CI/CD-пайплайны и контейнерные сборки, тем ценнее он для конкурса. Мелкие пакеты тоже не списываются: несколько можно объединить и нарастить общий счёт.
Поэтому теперь под риск попадают и небольшие библиотеки, если они входят в цепочки зависимостей, используются в DevOps-инструментах или имеют доступ к токенам сборки. Для атакующего не нужно сразу ломать гиганта экосистемы: можно собрать эффект из десятков небольших пакетов.
Shai-Hulud в этом контексте — инструмент и бренд для атак на цепочку поставок open source. CyberPress пишет, что TeamPCP выпустила его как open source-вредоносный инструмент на инфраструктуре BreachForums. Socket уточняет, что копия успела появиться на GitHub, но затем ее удалили.
Опасность таких инструментов не только в готовом коде. Они обкатывают методику: как искать пакеты, красть секреты, доказывать доступ, передавать результат.
TeamPCP не появилась из ниоткуда. Wiz отслеживала кампанию группы в марте 2026 года: под удар попали Trivy, KICS, LiteLLM и Telnyx. Во всех четырёх случаях вредоносный код был нацелен на кражу cloud credentials, SSH-ключей, Kubernetes-конфигов и CI/CD-секретов. Украденные данные шифровались и уходили на домены под контролем атакующих.
Unit 42 описывает ту же волну как многоступенчатую supply chain-операцию против инструментов, которым разработчики и команды безопасности уже доверяют. Среди целей были Trivy от Aqua Security, KICS от Checkmarx, LiteLLM и официальный Python SDK Telnyx. Эти инструменты часто работают внутри CI/CD и получают доступ к репозиториям, контейнерам, cloud-аккаунтам и секретам.
ReversingLabs писала о компрометации Telnyx PyPI-пакета: вредоносные версии 4.87.1 и 4.87.2 были нацелены на эксфильтрацию cloud-секретов, а пакет имел миллионы загрузок. В случае LiteLLM затронутые версии 1.82.7 и 1.82.8 доставляли payload, похожий на предыдущие атаки TeamPCP: инфостилер искал секреты в жёстко заданных путях и памяти процессов.
BreachForums выступает не просто витриной для очередной утечки. В этой истории форум становится площадкой для координации и мотивации. Участникам дают правила конкурса, требуют доказательства доступа и привязывают результат к профилю на форуме. Это создаёт социальный слой атаки: репутация, статус, обсуждение, повторение чужих техник.
Главный риск — кража секретов из CI/CD. Это GitHub tokens, npm/PyPI tokens, cloud access keys, SSH-ключи, Kubernetes kubeconfig, Docker credentials, Terraform state, переменные окружения, секреты деплоймент-пайплайнов. Wiz отмечала, что украденные credentials быстро проверялись и использовались для разведки окружения и дополнительной эксфильтрации данных.
Второй риск — каскадный эффект. Один пакет заражает разработчика или пайплайн. Из пайплайна уходят токены. Через токены атакующий получает доступ к репозиториям, облачным ресурсам или реестрам пакетов. Затем появляются новые заражённые пакеты, контейнеры или GitHub Actions. Именно поэтому supply chain-инциденты редко заканчиваются на первом проекте.
Третий риск — ложная уверенность в «непопулярности». Небольшой пакет может быть транзитивной зависимостью в сотнях проектов. Расширение для OpenVSX может использоваться разработчиками с доступом к внутренним репозиториям. GitHub Action может запускаться в приватном CI с продакшн-секретами. Docker-образ может быть базой для десятков сервисов.
Мэйнтейнерам open source-проектов стоит исходить из того, что их аккаунты и пайплайны стали целью. Нужны аппаратные ключи или устойчивые к фишингу MFA для GitHub, npm, PyPI и других реестров. Пароль и обычный TOTP уже слабая защита для аккаунта, через который можно пропустить вредоносную версию пакета.
Нужно проверить publish-пайплайны: кто может публиковать релиз, какие GitHub Actions имеют id-token: write, где лежат npm/PyPI-токены, есть ли доверенная публикация, кто может менять воркфлоу, какие secrets доступны pull request-сценариям, не работают ли релизы из личного аккаунта одного мейнтейнера.
Отдельная проверка — preinstall/postinstall-скрипты, бинарники, obfuscated-код, новые зависимости и неожиданные изменения в релизных артефактах. В TeamPCP-кампаниях вредоносная логика часто жила там, где её не читает обычный пользователь пакета: в сборочных шагах, GitHub Actions, опубликованных артефактах и пакетах реестра.
Компаниям нужно быстро составить список зависимостей и инструментов, которые запускаются в CI/CD: Trivy, KICS, LiteLLM, Telnyx SDK и другие пакеты из недавних кампаний TeamPCP. Проверка должна идти не только по package.json или requirements.txt, но и по GitHub Actions, Dockerfile, Helm charts, devcontainers, CI templates, базовым образам и локальным инструментам разработчиков.
Дальше — ротация секретов там, где есть риск запуска заражённых версий. Ротировать нужно не «главный пароль», а конкретные токены: ключи облака, GitHub PAT, npm/PyPI credentials, SSH keys, kubeconfig, Docker registry tokens, service account keys.
Ещё один обязательный шаг — задержка и контроль свежих пакетов. Для production CI опасно автоматически тянуть только что опубликованные версии популярных зависимостей. Нужны lock-файлы, internal mirrors, allowlist, quarantine новых версий, проверка diff, SCA-инструменты и политика «релиз пакета должен отлежаться», если бизнес-процесс это позволяет.
Для CI/CD и облаков в логах важны странные обращения к secret stores, массовые чтения переменных окружения, запуск TruffleHog или похожих secret scanners, новые исходящие соединения из runner’ов, публикация неожиданных package versions, изменение GitHub Actions workflow, дефейсы репозиториев, новые ключи деплоя, PAT с необычными скупами, скачивание приватных репозиториев и обращения к неизвестным C2-доменам.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
