Microsoft опубликовала отчет о кампании Red Hat npm Miasma: проверка происхождения пакета (provenance) может подтвердить источник, но не гарантирует чистоту сборки.
Атака затронула 32 модифицированных пакета с более чем 90 версиями в пространстве @redhat-cloud-services npm. Компрометация произошла через CI/CD-пайплайн RedHatInsights/javascript-clients, что позволило злоумышленнику публиковать троянские пакеты через легитимный GitHub Actions OIDC workflow.
Главная угроза не только в зараженных пакетах. Проблема в том, что они имели подлинные подписи provenance. Атакующему не пришлось подделывать доверие снаружи — использовался внутренний доверенный путь.
Изменения в механизме#
Кампания использовала поведение npm preinstall как точку первого запуска. При установке зараженного пакета автоматически срабатывал вредоносный preinstall-хук. Скрипт запускался как при прямых, так и при транзитивных зависимостях, включая места, где пакет никто вручную не запускал.
Microsoft отмечает, что хук запускал сильно обфусцированный JavaScript-дроппер размером 4.29 МБ. Дроппер распаковывал несколько уровней обфускации, расшифровывал полезную нагрузку AES-128-GCM, скачивал JavaScript-рантайм Bun и использовал его для запуска второго этапа атаки.
Цепочка node → shell → bun → payload критична для операций: многие команды мониторят Node-пакеты, npm-скрипты и подозрительные shell-вызовы, но редко отслеживают альтернативный JS-рантайм, скачанный на лету.
Полезная нагрузка нацелена на учетные данные GitHub, npm, AWS, Azure, GCP, HashiCorp Vault, Kubernetes и локальных разработчиков. На машинах разработчиков атакующие искали SSH-ключи, CLI-креденшлы, данные браузеров и кошельков. В CI/CD — сканировали память runner’ов GitHub Actions, пытались эскалировать привилегии без пароля и перепубликовать зараженные пакеты с поддельным SLSA provenance.
Идентификатор кампании — “Miasma: The Spreading Blight”. Название эффектное, тактика реальна: preinstall persistence использовалась как точка входа в supply chain.
Почему preinstall persistence опасен#
Preinstall persistence выполняется до основной логики пакета. Для атаки пакет не нужно импортировать — достаточно установки в уязвимое место.
Это меняет модель рисков для разработчиков и CI/CD: уязвимый граф зависимостей может раскрыть креденшлы на этапе установки, восстановления, сборки или теста.
Главный урок — границы доверия. Метаданные provenance полезны, но не гарантируют безопасность. Если злоумышленник контролирует workflow публикации, подписанный пакет описывает скомпрометированную реальность.
Provenance эффективен только вместе с операционными проверками: кто может публиковать, какие workflow могут создавать идентичность, какие jobs получают секреты, и могут ли install-скрипты выполняться там, где есть облачные или registry-креденшлы.
Microsoft также отмечает «червеподобное» распространение: вредоносное ПО пыталось заражать другие пакеты и публиковать их версии. Один украденный токен может превратиться в путь публикации и множество downstream-инсталляций.
Что проверить#
Проверка начинается с экспозиции. Определите, устанавливались ли затронутые пакеты @redhat-cloud-services и версии в соответствующий период, затем исследуйте CI/CD и машины разработчиков, которые их устанавливали.
Для безопасности проверяйте не только имена пакетов. Анализируйте скрипты установки, особенно npm preinstall hooks в пайплайнах с доступом к GitHub, npm, облаку, Vault, Kubernetes или SSH.
Отслеживайте необычные загрузки рантаймов при установке. В этом случае Bun скачивался и использовался для выполнения payload. Это важная детекция: npm install → shell → runtime download → вторичная JS-полезная нагрузка.
Проверяйте логи runner’ов GitHub Actions и возможное раскрытие секретов в памяти. Зараженные runner’ы следует рассматривать как инциденты компрометации креденшлов.
Ротация токенов обязательна, если были установки: registry-токены, GitHub, облачные креденшлы, Vault, Kubernetes и SSH-ключи. Обычная пересборка недостаточна, если атакующий уже скопировал креденшлы.
Для workflow публикации проверьте, какие репозитории используют доверенную публикацию через GitHub Actions OIDC. Подтвердите, что только назначенные workflow могут публиковать, соблюдены branch и tag-контролы, release jobs не доступны из ненадежного кода.
Сравните внутренние меры безопасности OSS с фактическим поведением пакетов: пакет может быть подписан, популярный и scoped, но содержать вредоносный install-скрипт при компрометации пайплайна.
Ограничения выводов#
Не всякая загрузка Bun автоматически вредоносна. Bun использовался для запуска payload и обхода Node-мониторинга. Сигналы зависят от контекста: npm install script, обфусцированный дроппер, runtime download, targeting credentials.
Это не означает, что provenance как система провалилась. Вывод точный: provenance подтверждает путь, но не делает его безопасным.
Тот же принцип — для атрибуции и оценки ущерба. Microsoft описывает цепочку атаки, затронутые пакеты, цели и шаги смягчения с npm. Не придумывайте количество жертв, юридические последствия или downstream-компрометации без доказательств.
Практический вывод#
Кампания Red Hat npm Miasma важна для playbook безопасности: она атакует тихие участки цепочки поставок — установку.
Preinstall persistence дает malware свободу до запуска приложения, CI/CD — секреты, доверенная публикация — легитимность, provenance — контекст для защиты.
Действия: ограничить выполнение install-скриптов, уменьшить доступные при установке секреты, усилить workflow публикации, рассматривать подозрительные установки пакетов в CI как возможную компрометацию креденшлов.
Главный урок: пакет — средство доставки, цель — доверие в операциях.