Анализ отравления NPM — Воссоздание атаки Shai-Hulud

Автор: Joker & Ccj

Фон

Недавно в сообществе NPM снова произошел крупномасштабный инцидент с отравлением пакетов NPM. Этот инцидент имеет высокую степень связи с атакой Shai-Hulud в сентябре 2025 года. Зловредный код в этом пакете NPM крадет ключи разработчиков, API-ключи и другие конфиденциальные данные, используя эти ключи для создания публичных репозиториев и загрузки украденной конфиденциальной информации.

慢雾(SlowMist) самостоятельно разработанный инструмент веб3 разведки угроз и динамического мониторинга безопасности MistEye в первую очередь реагирует, быстро отправляя соответствующую информацию об угрозах, обеспечивая клиентов ключевой безопасностью.

!

!

В то же время, бэкэнд сразу сохранит вредоносные образцы и вычислит их соответствующие значения характеристик, такие как SHA-256.

!

Анализ процесса

В качестве примера пакета @asyncapi/php-template@0.1.1, при сравнении со старой версией @asyncapi/php-template@0.1.0 можно заметить, что версия 0.1.1 добавила два js файла: setup_bun.js и запутанный bun_environment.js.

!

В package.json добавлен скрипт preinstall, который автоматически выполняет setup_bun.js перед установкой зависимостей.

!

В файле setup_bun.js сначала проверяется, установлен ли Bun в системе. Если он не установлен, Bun будет автоматически загружен и установлен с официального сайта, и переменные окружения будут правильно настроены, чтобы найти исполняемый файл Bun.

В конечном итоге используйте bun для выполнения файла bun_environment.js, который является сильно замаскированным вредоносным файлом.

!

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

Кража учетных данных

AWS: Этот вредоносный скрипт реализует методы runSecrets() и listAndRetrieveAllSecrets(). Метод runSecrets() будет просматривать все доступные облачные учетные данные и все возможные регионы, максимизируя диапазон сканирования; в то время как listAndRetrieveAllSecrets() проводит “глубокую разведку” в рамках заданных учетных данных и региона, перебирая все Secrets и получая их последние открытые содержимое. В сочетании они позволяют злоумышленнику экспортировать все доступные SecretString и SecretBinary из учетной записи жертвы AWS за один раз.

!

Метод enumerateValidCredentials() в основном используется для полного сбора всех доступных ключей облачного сервиса. Он пробует поочередно различные источники, такие как переменные окружения, конфигурационные файлы, авторизация через CLI и т.д. Все учетные данные, которые успешно проходят проверку, будут зафиксированы для последующего использования при кражах облачных конфиденциальных данных.

!

GCP: Другой метод listAndRetrieveAllSecrets(), реализованный в этом вредоносном скрипте, в основном направлен на модуль GCP. Сначала он перечисляет все секреты в указанном проекте GCP по заданному идентификатору проекта, затем напрямую находит последнюю версию каждого секрета и вызывает accessSecretVersion для чтения его открытого содержимого. В конечном итоге все полученные секреты (такие как API Key, пароли к базам данных и т.д.) собираются по одному.

!

Azure: Другой метод listAndRetrieveAllSecrets(), реализованный в этом вредоносном скрипте, в основном нацелен на модуль Azure. Сначала он сканирует всю подписку через Azure Resource Manager, чтобы найти все Key Vault; затем, используя полученные учетные данные, поочередно подключается к каждому Vault; наконец, перечисляет все Secrets и вызывает getSecret для получения открытого значения каждого секрета.

!

В реализации кражи конфиденциальной информации также используются законные инструменты безопасности для атаки на жертву. В методе extractAndInstall() происходит распаковка и извлечение бинарных файлов TruffleHog, который изначально предназначен для обнаружения и проверки утечек конфиденциальной информации, таких как API-ключи и учетные данные, но использовался злоумышленниками для сканирования всей файловой системы жертвы.

!

НПМ цепочка поставок

Этот вредоносный скрипт реализует функцию updatePackage() для распространения через цепочку поставок NPM. Сначала с помощью украденного NPM Token загружается исходный код легального NPM пакета, на который у жертвы есть права на публикацию, затем модифицируется файл package.json, в поле scripts вставляется вредоносная команда скрипта preinstall. Одновременно вредоносный скрипт помещается в пакет, автоматически увеличивается номер версии пакета на 1, чтобы инициировать автоматическое обновление пользователя, а NPM пакет с вредоносным скриптом отправляется в официальный репозиторий NPM.

!

Задняя дверь и C2

После кражи информации злоумышленник использует украденный токен GitHub для создания репозитория с произвольным именем под своим аккаунтом и получает токен регистрации, маскируя компьютер жертвы под самоуправляемый GitHub Actions Runner этого репозитория. Затем злоумышленник внедряет вредоносный рабочий процесс в репозиторий, что приводит к тому, что любые запущенные действия будут выполняться на машине жертвы, что позволяет осуществлять удаленное выполнение кода.

!

И загрузить эту украденную информацию, дважды закодированную в base64, в созданный репозиторий, описания которого все “Sha1-Hulud: The Second Coming.”.

!

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

!

!

!

Итог

Недавняя атака на репозиторий NPM сочетала в себе червя и долгосрочную устойчивость самоуправляемых программ, используя TruffleHog для атаки. Команда безопасности Slow Fog рекомендует разработчикам применять стратегию блокировки версий зависимостей при создании и выпуске новых итераций. Если у зависимостей есть необходимые обновления безопасности или функционала, их следует обновлять через строгий внутренний процесс аудита безопасности и синхронно обновлять зафиксированные версии, чтобы избежать слепого обновления, которое может привести к новым рискам.