Компрометация npm: вредоносные пакеты крали учётные данные в CI
Скрытая угроза в цепочке поставок: как вредоносные npm-пакеты маскировались под легитимные обновления
Расследование команды Socket вскрыло продуманную атаку на экосистему npm, в которой злоумышленники использовали скомпрометированную учётную запись доверенного разработчика для распространения вредоносных сборок. Под видом обычных обновлений популярных библиотек кэширования распространялся код, нацеленный на кражу учётных данных из сред разработки и CI (Continuous Integration). Особую опасность представляет то, что заражение происходило непосредственно в момент установки пакета, без всякого взаимодействия с его функциональным кодом.
Механика атаки: preinstall-ловушка и среда исполнения Bun
Ключевым элементом атакующих пакетов стал хук preinstall, определённый в файле setup.mjs. При установке любого из скомпрометированных модулей npm автоматически запускал этот скрипт. Действия вредоносного хука выходили далеко за рамки типового конфигурирования:
- Загружалось и запускалось автономное рантайм-окружение Bun, не требующее предустановки на машине жертвы.
- Используя Bun, скрипт дешифровал и выполнял полезную нагрузку второй стадии — ещё до того, как установка пакета формально завершалась.
- Вредоносный код фокусировался на сборе учётных данных, хранящихся в переменных окружения, конфигурационных файлах и токенах, характерных для сред разработки и CI/CD-пайплайнов.
Таким образом, сам факт извлечения (pull) скомпрометированного пакета в окружение, где разрешено выполнение скриптов жизненного цикла, становился триггером компрометации. Атакующим не требовалось, чтобы жертва импортировала или вызывала уязвимый код библиотеки.
Масштаб, распространение и туманная атрибуция
Вскоре после первоначальной компрометации вредоносные артефакты были зафиксированы в сотнях пакетов npm. Злоумышленники использовали украденные токены публикации, чтобы выпускать троянизированные версии других, изначально безобидных модулей, лавинообразно расширяя охват атаки. Точное количество поражённых систем остаётся неопределённым.
Исследователи отметили тактическое сходство с известным вариантом вредоносного ПО Shai-Hulud, связываемым с группировкой TeamPCP. Среди параллелей — целенаправленный сбор учётных записей и повторная публикация пакетов через скомпрометированные учётные данные. Однако окончательные идентифицирующие маркеры, которые позволили бы привязать текущую кампанию конкретно к Shai-Hulud, отсутствуют. Атрибуция остаётся предположительной, несмотря на заметные совпадения в инструментарии.
Руководство по реагированию: ключевые шаги для защиты
При обнаружении признаков компрометации критически важно действовать немедленно, не допуская дальнейших установок пакетов. Первоочередная задача — изоляция и криминалистическое сохранение состояния затронутых систем:
- Зафиксируйте и сохраните файлы блокировки (lockfiles), разрешённые версии зависимостей, журналы CI-пайплайнов, историю релизов и любые артефакты на хосте (логи процессов, сетевые дампы).
- Установите характер компрометации: была ли опасная версия всего лишь разрешена в дереве зависимостей или хук preinstall реально выполнился в вашей среде. От этого зависит глубина инцидента.
После фиксации доказательств выполните следующие восстановительные мероприятия:
- Немедленно отзовите все потенциально скомпрометированные учётные данные, токены доступа и ключи на всех затронутых платформах (npm, GitHub, облачные провайдеры, CI-сервисы).
- Проверьте историю коммитов и активность в репозиториях на предмет несанкционированных изменений, особенно в релизных ветках и конфигурациях CI.
- Восстановите системы из заведомо чистого, доверенного состояния. Используйте исключительно проверенные, безопасные версии пакетов.
- Заново сгенерируйте файлы блокировки на основе восстановленного чистого кода и убедитесь в целостности всего пути сборки и релиза, исключив точки внедрения в процесс публикации.
Бдительность на этапе разрешения зависимостей и строгая верификация скриптов жизненного цикла — сегодня не рекомендация, а обязательное условие безопасности конвейеров разработки.
Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.
Ознакомиться подробнее с отчетом можно по ссылке.
