Оно снова в 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 зависимостей без явного разрешения, но обновление пакетного менеджера не очищает уже зараженную машину и не возвращает украденные ключи.