Miasma превращает npm-пакеты в червя для цепочки поставок

Новая атака на цепочку поставок, получившая название Miasma, затронула несколько npm-пакетов из пространства имён @redhat-cloud-services. В них был внедрён вредоносный код для кражи учётных данных, рассчитанный на распространение через среды разработки и инфраструктуру CI/CD.

Риск не ограничивается установкой заражённого пакета. Согласно публикациям и анализу, на которые ссылаются исследователи, вредоносное ПО пытается собирать секреты, использовать конвейеры доставки ПО, закрепляться на рабочих станциях разработчиков и применять похищенный доступ для дальнейшего заражения связанных систем.

Источник: https://thehackernews.com/2026/06/miasma-supply-chain-attack-compromises.html

Что известно об атаке#

Исследователи отмечают, что Miasma имеет ряд общих черт с более ранними атаками на цепочку поставок в стиле Mini Shai-Hulud. Вредоносный код запускается во время установки пакета через обфусцированный хук preinstall и сосредоточен на сборе наиболее ценных учётных данных с рабочих станций разработчиков и систем сборки.

Среди целей упоминаются секреты GitHub Actions, токены npm, облачные учётные данные, данные Kubernetes и Vault, SSH-ключи, Git-учётные данные и другие чувствительные файлы, которые часто встречаются в средах разработки.

Несколько затронутых пакетов были опубликованы под пространством имён @redhat-cloud-services. По данным, на которые ссылаются несколько компаний в сфере информационной безопасности, вредоносный код появился после компрометации GitHub-аккаунта сотрудника Red Hat. Следователи считают, что злоумышленники внесли вредоносные orphan-коммиты в репозитории таким образом, чтобы обойти стандартные механизмы проверки кода.

С атрибуцией пока сохраняется неопределённость. Исследователи напоминают, что инструменты, связанные с предыдущими кампаниями Shai-Hulud, как сообщается, были опубликованы в открытом доступе. Это создаёт условия для подражателей и снижает достоверность ранних выводов о конкретном исполнителе атаки.

Особенно важно другое: Miasma не выглядит как инструмент для простой кражи секретов. Поведение вредоносного кода указывает на попытку превращать украденные учётные данные в новые точки доступа к цепочке поставок, повышая вероятность дальнейшей компрометации связанных сред.

Почему это предупреждение важно#

Многие инциденты в цепочке поставок ограничиваются одним репозиторием, пакетом или набором учётных данных. Судя по наблюдениям исследователей, Miasma нацелена на более широкий уровень — отношения доверия между рабочими станциями разработчиков, облачными платформами, системами контроля версий и автоматизированными конвейерами сборки.

Это принципиальное отличие.

Украденная учётная запись разработчика уже представляет ценность. Но если этот доступ позволяет изменять репозитории, публиковать пакеты, корректировать workflow или влиять на артефакты релизов, последствия возрастают многократно.

Исследователи зафиксировали активность, направленную непосредственно на окружения GitHub. По имеющимся данным, вредоносное ПО перечисляет репозитории, доступные через скомпрометированные токены, и пытается вносить изменения, связанные с workflow, через GitHub API. Судя по поведению, цель заключается не только в краже данных, но и в закреплении и дальнейшем распространении.

Ещё одно заметное изменение — повышенное внимание к облачным идентичностям. В цитируемых исследованиях упоминаются новые механизмы сбора данных, нацеленные на облачный доступ и идентичности крупных облачных провайдеров.

Это может говорить о смене приоритетов злоумышленников.

Ранние атаки на цепочку поставок часто ограничивались извлечением секретов. Кампания, которая пытается выявлять и использовать облачные идентичности, потенциально нацелена на долгосрочный операционный доступ. Для команд безопасности это расширяет область расследования: проверять приходится не только исходный код и реестры пакетов, но и облачные панели управления вместе с системами управления идентичностями.

Кроме того, сообщается, что для каждого заражения формируется уникально зашифрованный полезный груз. Если это подтвердится для всех затронутых образцов, обнаружение, сигнатурный анализ и корреляция инцидентов в больших масштабах станут заметно сложнее.

Что стоит проверить командам безопасности#

Организациям, которые устанавливали затронутые версии пакетов, не стоит воспринимать инцидент как обычное удаление проблемной зависимости.

Исследователи рекомендуют изолировать затронутые узлы и заменить все потенциально раскрытые учётные данные. Речь идёт о токенах GitHub, учётных данных npm, облачных ключах доступа, секретах CI/CD, SSH-материалах и любых других чувствительных данных, доступных из заражённой среды.

Рекомендуется проверить:

• репозитории GitHub на наличие неожиданных коммитов, изменений workflow и модификаций автоматизации;
• системы CI/CD на предмет подозрительных запусков, артефактов и операций развёртывания;
• активность публикации пакетов npm от имени затронутых учётных записей;
• использование облачных идентичностей и изменения привилегий;
• результаты сборок, созданные в период возможного воздействия;
• механизмы закрепления, оставленные в инструментах разработки и конфигурационных файлах проектов.

Особое внимание стоит уделить рабочим станциям разработчиков. Исследователи сообщают о механизмах, рассчитанных на сохранение доступа через изменения конфигурации инструментов разработки и файлов проектов.

Из-за этого очистка может оказаться сложнее, чем кажется. Удаление пакета из node_modules способно устранить лишь один элемент цепочки заражения, не затрагивая последующие изменения, внесённые вредоносным кодом.

Организациям с развитыми процессами мониторинга безопасности имеет смысл отдельно проверить, можно ли по-прежнему доверять релизам, контейнерным образам, пакетам и артефактам развёртывания, выпущенным в период риска.

Во многих случаях пересборка и повторная валидация артефактов могут оказаться быстрее и безопаснее, чем попытка доказать отсутствие влияния атаки.

Чего пока нельзя утверждать#

Несмотря на серьёзность ситуации, ряд важных вопросов остаётся без ответа.

Личность злоумышленника достоверно не установлена.

Публичные отчёты также не доказывают, что каждая установка затронутых пакетов привела к успешной краже учётных данных или дальнейшей компрометации. Потенциальное воздействие и подтверждённый взлом — не одно и то же.

По той же причине наличие механизмов распространения не означает, что массовая активность червя действительно произошла во всех затронутых средах. Группам реагирования на инциденты не стоит автоматически исходить из наихудшего сценария без подтверждения собственными телеметрическими данными.

На данный момент наиболее обоснованный вывод выглядит так: в доверенные пакеты был внедрён вредоносный код, этот код был нацелен на среды разработчиков и CI/CD, а организации, использовавшие затронутые версии, должны провести соответствующее расследование.

Напоминание о безопасности open source#

История с Miasma вновь показывает знакомую проблему безопасности open source: одной только проверки кода недостаточно, если скомпрометированы системы идентификации и управления доступом.

Целостность пакетов, защита репозиториев, проверка артефактов, контроль учётных данных и мониторинг окружений CI/CD всё чаще определяют, останется ли компрометация локальным инцидентом или перерастёт в полноценную атаку на цепочку поставок.

Фокус кампании на учётных данных, облачных идентичностях, изменении workflow и механизмах закрепления отражает устройство современных экосистем разработки. Злоумышленники атакуют не отдельные системы, а связи между ними.

Для защитников это означает, что установка исправлений — лишь часть работы. Не менее важно понимать, кто может публиковать пакеты, подписывать артефакты, выполнять развёртывание и изменять автоматизацию. Именно там часто начинается реальное сдерживание подобных инцидентов.