Сдвиг TeamPCP: от кампании к повторяемой атакующей инфраструктуре#
TeamPCP больше не выглядит как разрозненная серия инцидентов. Модель поведения смещается в сторону устойчивого supply-chain фреймворка, который можно переиспользовать и масштабировать. Основная цель — не единичная компрометация пакета, а внедрение механизма самораспространения через экосистему зависимостей.
Атака адаптируется под npm-экосистему и build pipelines, где код выполняется автоматически в процессе установки зависимостей. Это превращает стандартный workflow разработчика в канал доставки вредоносной логики.
Как wormable-логика реализуется в npm#
Ключевой механизм — install-time execution. При установке пакета активируются lifecycle hooks, включая preinstall и postinstall, а также скрипты сборки.
Leaked Mini Shai-Hulud framework используется как базовая логика автоматического распространения: он не ограничивается одним пакетом, а пытается внедряться в цепочку зависимостей. Strain Miasma был замечен в cloud-oriented пакетах и ориентирован на извлечение токенов и API-ключей. Phantom Gyp расширяет поверхность атаки через node-gyp, где вредоносный код уходит в фазу нативной сборки, обходя часть поверхностных проверок.
Общий паттерн: выполнение кода происходит внутри доверенной среды CI/CD, где доступ к секретам уже предоставлен pipeline-агенту.
Почему CI/CD становится точкой захвата доверия#
CI/CD системы изначально проектировались как автоматизированная среда, где код из репозитория считается допустимым к выполнению. Это создает фундаментальное предположение доверия к зависимостям.
Lifecycle scripts в npm нарушают границу между «данные» и «исполняемый код». Даже при использовании signed artifacts и SLSA-аттестаций остаётся окно, в котором вредоносная логика выполняется до или во время сборки.
Проблема смещается: важен не только контроль целостности пакета, но и контроль исполнения в pipeline runtime.
Цепочка заражения в типичном сценарии#
- Разработчик добавляет зависимость в package.json
- npm install активирует цепочку транзитивных зависимостей
- Один из пакетов содержит postinstall или node-gyp hook
- Код исполняется в CI runner или локальной среде
- Из runner извлекаются secrets: tokens, SSH keys, cloud credentials
- Данные отправляются на внешний endpoint через outbound connection
- Компрометация распространяется дальше через обновленные зависимости
Сигналы компрометации в CI/CD#
Аномальные install-time execution события в логах npm и yarn
Неожиданные процессы node-gyp или compilation steps в проектах без native modules
Outbound network connections из build runners в неразрешенные домены
Появление новых скриптов в node_modules после установки зависимостей
Утечки environment variables в логах CI
Практическая проверка и контроль#
Аудит package-lock.json и yarn.lock на неожиданные транзитивные зависимости
Жесткое ограничение lifecycle scripts через npm config ignore-scripts или аналогичные политики
Изоляция CI runners без прямого доступа к production secrets
Сегментация токенов: минимальные права для build environment
Мониторинг egress traffic из CI/CD сетей с блокировкой неизвестных endpoint’ов
Регулярный анализ node-gyp usage и native build triggers в зависимостях
Смещение модели угроз#
Атака перестает зависеть от конкретного оператора или кампании. Она становится воспроизводимой техникой внутри экосистемы npm, где сама структура доверия к pipeline используется как канал доставки.
Attribution теряет практическую ценность. Ключевой объект защиты — не пакет, а процесс его исполнения внутри CI/CD.