TeamPCP атакует supply chain: компрометация GitHub и CI/CD
TeamPCP атакует supply chain-проекты на GitHub: в фокусе CI/CD, Docker Hub и Kubernetes-экосистема
В марте 2026 года группировка TeamPCP, которую исследователи относят к преступным хакерским объединениям, провела серию масштабных атак на проекты supply chain в GitHub. В число целей вошли облачные платформы и автоматизированные среды разработки, включая конвейеры CI/CD и Docker Hub.
По данным отчета, злоумышленники использовали несколько техник, характерных для сложных операций по компрометации цепочки поставок: self-hosted commits, tag poisoning и fileless payload execution. В результате были скомпрометированы многочисленные репозитории, включая Trivy Scanner, Checkmarx, LiteLLM и Telnyx.
Как действовала TeamPCP
Атака на Trivy отличалась особенно высокой степенью технической проработки. В ней использовались десять различных shells, каждая из которых была адаптирована под отдельные задачи. Одна из них занималась сканированием памяти запущенных процессов с целью извлечения конфиденциальных данных, прежде всего GitHub Personal Access Tokens (PATs).
Эта shell была намеренно облегченной, чтобы быстро выполняться в контексте CI/CD. Для вывода данных применялись прямые HTTP POST-запросы к домену, визуально напоминающему легитимный адрес Aqua Security.
Другая shell была ориентирована на подготовку сред Kubernetes. Она проверяла наличие kubectl, после чего извлекала и запускала удаленный Python-script контроллера. Такой подход облегчал сбор учетных данных в Kubernetes-экосистеме и усиливал использование облачных ресурсов в интересах атакующих.
Последующие shells выполняли Python-скрипты непосредственно в памяти, не оставляя следов на диске. Для скрытности злоумышленники активно использовали знакомые инструменты, включая curl и Python.
Компрометация Checkmarx и LiteLLM
В аналогичных атаках, направленных на Checkmarx и LiteLLM, TeamPCP использовала версии вредоносного кода, предназначенные для компрометации Python-пакета LiteLLM. Это приводило к сбору учетных данных и эксфильтрации информации с помощью вредоносных payloads под названием litellm_init.pth.
Механизм кражи данных включал поиск конфиденциальных токенов и последующее шифрование похищенной информации перед отправкой на конечные точки, контролируемые злоумышленниками. Такой подход повышал устойчивость операции и осложнял обнаружение активности.
Эволюция операций: от декабря 2025 года до мартовских атак
Отслеживание развития методов TeamPCP показывает, что активность группы заметно усилилась с декабря 2025 года и достигла пика к мартовским атакам. Одним из ключевых типов shells стал основной инструмент распространения, превращавший скомпрометированные облачные хосты в узлы более широкой botnet-сети.
Для поддержания постоянного доступа группировка использовала инструменты туннелирования, а также была готова к развертыванию дополнительных вредоносных скриптов. В отчетах подчеркивается, что TeamPCP делала ставку на:
- самораспространение с помощью npm worms;
- агрессивный сбор учетных данных из CI/CD-сред;
- сложные методы эксфильтрации данных;
- использование зашифрованных файлов, замаскированных под легитимные данные;
- применение advanced backdoor-методов для закрепления в скомпрометированных средах.
Почему эта кампания опасна
Особое внимание исследователей привлекло использование TruffleHog для проверки украденных учетных данных, а также регулярное сканирование memory spaces и интенсивная работа с Kubernetes на протяжении всей кампании. Это указывает на целенаправленную эксплуатацию доверенных инструментов разработчиков и инфраструктуры, которая обычно считается безопасной.
По сути, TeamPCP демонстрирует модель атаки, в которой supply chain-компрометация становится не разовой акцией, а полноценным механизмом закрепления, масштабирования и дальнейшего распространения внутри облачных и DevOps-сред.
Вывод отчета однозначен: организациям, использующим GitHub, CI/CD, Docker Hub и Kubernetes, необходимо уделять повышенное внимание мониторингу supply chain-рисков, контролю уязвимостей и механизмам оперативного реагирования.
Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.
Ознакомиться подробнее с отчетом можно по ссылке.
