После атаки на популярный сканер уязвимостей Trivy злоумышленники переключились на экосистему Jav * aScript: исследователи обнаружили цепочку заражения, которая превращает установку npm‑пакета в точку входа для дальнейшего распространения. Главная «фишка» — управляющая инфраструктура на блокчейне, которую сложно быстро «выключить».
Атака на цепочку поставок вокруг Trivy получила продолжение: исследователи связывают инцидент с компрометацией 47 npm‑пакетов, внутри которых обнаружили ранее не описанного самораспространяющегося «червя», получившего имя CanisterWorm.
История важна не только из-за масштаба, но и из-за подхода к управлению: часть инфраструктуры вынесена в децентрализованный «dead drop» на базе ICP canister (смарт‑контракты в сети Internet Computer). Это делает схему более устойчивой к блокировкам и быстрым «тэкдаунам».
Какие пакеты оказались затронуты
По данным расследования, в список попали:
- 28 пакетов в scope @EmilGroup
- 16 пакетов в scope @opengov
- @teale.io/eslint-config
- @airtm/uuid-base32
- @pypestream/floating-ui-dom
Как устроена цепочка заражения
Сценарий построен так, чтобы запуск происходил максимально «естественно» для разработчика — во время обычной установки зависимостей:
- в пакете используется postinstall-хук, который запускает первичный загрузчик;
- затем на машину попадает Python‑бэкдор;
- бэкдор обращается к ICP canister, который выступает «почтовым ящиком»: оттуда возвращается URL следующего этапа;
- после получения ссылки система скачивает и запускает исполняемый файл.
Ключевой момент: контроллер canister может менять URL в любой момент. В результате «оператор» способен переключать полезную нагрузку для всех заражённых хостов без переустановки пакетов и без изменения уже внедрённого кода на стороне жертвы.
Почему защититься сложнее обычного
В классических цепочках supply chain инфраструктуру управления можно попытаться заблокировать — домены, IP, хостинг. Здесь же «точка правды» частично находится в децентрализованной среде, а значит, отключить её быстро намного труднее.
В этой кампании, по описанию исследователей, имплант периодически обращается к canister с подменённым User-Agent примерно раз в 50 минут и получает URL в открытом виде (plaintext). Есть и режим «спячки»: если URL содержит youtube.com, скрипт пропускает загрузку — это используется как способ «разоружить» имплант. На момент публикации возвращаемая ссылка вела на ролик‑«рикролл».
Закрепление в системе: маскировка под PostgreSQL
Чтобы не пропасть после перезагрузки и переживать попытки «прибить процесс», вредонос закрепляется через systemd user service:
- служба настроена так, чтобы перезапускаться при завершении (директива Restart=always);
- старт откладывается на 5 секунд, что помогает выглядеть менее подозрительно;
- для маскировки используется имя, похожее на утилиту из мира PostgreSQL — pgmon.
От «вредоносного пакета» к эпидемии: как работает самораспространение
Отдельного внимания заслуживает файл deploy.js. По данным Aikido, это не то, что срабатывает у жертвы автоматически при установке. Это инструмент атакующего, который он запускает вручную, имея на руках украденный npm‑токен, чтобы программно «раскатать» заражение на все пакеты, к которым этот токен даёт доступ.
По оценке исследователей, код написан в стиле «vibe‑coding» с использованием ИИ‑инструмента и почти не пытается скрывать назначение — из-за этого механизм распространения выглядит грубо, но эффективно.
Контекст: что было «днём раньше»
Развитие событий укладывается в логичную схему эскалации. В материале отмечается, что незадолго до волны с npm злоумышленники использовали скомпрометированные учётные данные, чтобы опубликовать вредоносные релизы trivy, trivy-action и setup-trivy, содержавшие похититель учётных данных. За кампанией подозревают облачно-ориентированную кибергруппу TeamPCP.
Что делать командам разработки прямо сейчас
Этот кейс — напоминание, что «безопасность зависимостей» уже давно не ограничивается одним npm‑audit. Практические шаги, которые имеют смысл внедрить сразу:
- Пересмотреть доверие к postinstall: где возможно — запрещать/ограничивать скрипты установки, особенно в CI.
- Проверить доступность npm‑токенов в окружениях разработчиков и пайплайнах: токен, «лежащий рядом», превращается в топливо для самораспространения.
- Зафиксировать зависимости и источники (lock‑файлы, контроль целостности, зеркала/прокси‑репозитории) и не тянуть неожиданные обновления автоматически.
- Проверить Linux‑хосты на подозрительные user‑services systemd и нестандартные автозапуски под похожими на системные именами (вроде «pgmon»).
- Развести права в CI: минимизировать секреты, ограничить токены по scope, времени жизни и репозиториям, применять принцип наименьших привилегий.
Материал в источнике помечен как развивающаяся история: детали могут дополняться по мере расследования.
