Оно снова в npm: вредонос Shai-Hulud вернулся спустя 111 дней

7 сентября специалисты Aikido нашли в npm четыре новых пакета с полезной нагрузкой Shai-Hulud: feishu-docx-mcp@0.3.2 , bmc-i18n-extract-cli@1.1.1 , blueai-cli@0.7.0 и bmc-translate-utils@1.1.1 . Все версии опубликовала одна учетная запись в течение часа. Самое интересное, что вредоносный файл даже не пытались замаскировать заново: его SHA-256 полностью совпал с образцом из майской атаки на пакеты @AntV.

По истории обнаружений Aikido этот файл встречался в 319 версиях пакетов 19 мая, а затем исчез на 111 дней. Новая четверка стала первым повторным появлением того же хэша. Это не новая техника и даже не слегка измененный вариант червя, а уже известный образец, по которому достаточно обычного сопоставления контрольной суммы.

В корне пакетов находился index.js , который запускался установочным скриптом preinstall через команду bun run index.js . Полезная нагрузка искала доступные секреты и токены npm, внедрялась в другие пакеты, повышала их версии и публиковала зараженные архивы. Среди признаков закрепления Aikido также называет файлы .vscode/tasks.json и .claude/settings.json , способные запускать команды при дальнейшей работе с проектом.

Этот эпизод особенно неприятен из-за времени публикации. 28 июля npm включил автоматическое сканирование новых пакетов до того, как они становятся доступны для установки. Обычно проверка задерживает публикацию примерно на пять минут, а подозрительный пакет может отправить на ручной разбор или заблокировать. Тем не менее четыре версии с известным вредоносным хэшем появились в реестре.

Из этого не следует, что проверка npm бесполезна или обязана находить любое вредоносное поведение. Многоступенчатый загрузчик и код, срабатывающий только во время работы приложения, действительно трудно отличить от легитимного. Но точное совпадение с уже разобранным образцом – это базовый сценарий сигнатурного обнаружения. Реестр нельзя считать единственным инструментом для проверки доверия, даже когда он проверяет каждую публикацию.

CodeScoring подхватил информацию о новой четверке и начал блокировать эти компоненты в контурах, где модуль CodeScoring.OSA работают с активной политикой «Зависимость опасна» . Такой рубеж останавливает новый запрос до попадания пакета во внутренний репозиторий или сборку. Пример настройки есть в документации.

Сейчас командам стоит проверить манифесты, lock-файлы и SBOM на наличие четырех компонентов из списка, а также сами машины разработчиков и CI-раннеры, где они могли устанавливаться. Если установочный скрипт успел выполниться, среду нужно считать скомпрометированной: пересобрать ее из чистого образа и отозвать доступные ей секреты с другого устройства. npm 12 по умолчанию не запускает preinstall зависимостей без явного разрешения, но обновление пакетного менеджера не очищает уже зараженную машину и не возвращает украденные ключи.

• Блог компании CodeScoring
• Информационная безопасность