Как злоумышленники спрятали командный сервер внутри блокчейна и почему его невозможно отключить

Исследователи Checkmarx обнаружили семь вредоносных npm-пакетов, нацеленных на экосистему Vite — популярного инструмента для сборки фронтенд-проектов. Кампанию назвали ViteVenom. По сути это продолжение более ранней атаки ChainVeil, только теперь злоумышленники переключились с библиотек вроде Tailwind, Sass и различных ORM-инструментов на подделку официального пространства имён @vitejs/.
Технически это классическая supply chain атака, но с одной деталью, которая выделяет её среди сотен подобных инцидентов за последние годы. Командная инфраструктура построена как четырёхуровневая система на базе трёх разных блокчейнов — Tron, Aptos и Binance Smart Chain. Раньше злоумышленники прятали C2-серверы за доменами, которые рано или поздно можно было изъять или заблокировать. Здесь домены вообще не используются как основной канал.
Механика работает так. Вредоносный код внутри пакета при импорте (не при установке — это важно) обращается к блокчейну Tron и запрашивает последнюю транзакцию с кошелька атакующего. Внутри данных транзакции зашит хэш другой транзакции — уже в сети BSC. Скрипт идёт туда, вытаскивает из поля input зашифрованную полезную нагрузку и расшифровывает её жёстко прописанным ключом. Если что-то на этапе Tron идёт не так, в дело вступает Aptos как резервный канал. А если и там не получается — есть третий вариант, прямой HTTP-запрос к серверу атакующих в обход всей блокчейн-цепочки.
Паван Гудималла из Checkmarx объясняет логику такой архитектуры прямо: «Эта тактика делает отключение или уничтожение C2-инфраструктуры крайне сложной задачей». И добавляет: «Атакующий хранит указатели на полезную нагрузку в виде транзакционных данных на публичных блокчейнах, а не на доменных именах, которые можно изъять, — это делает инфраструктуру практически неуязвимой для отключения».
Финальная нагрузка — троян удалённого доступа с довольно стандартным, но от этого не менее опасным набором функций: обратная оболочка, сбор учётных данных, кража файлов и установка постоянного бэкдора в системе.
Список заражённых пакетов выглядит так:
    []@uw010010/vite-tree — 1070 загрузок
    []@vite-tab/tab — 289 загрузок
    []@vite-ln/build-ts — 252 загрузки
    []@vite-mcp/vite-type — 239 загрузок
    []@vite-pro/vite-ui — 200 загрузок
    []@vitets/vite-ts — 194 загрузки
    []@vite-ts/vite-ui — 176 загрузок
Числа скромные по меркам крупных атак на npm, но счёт идёт не на миллионы, а на конкретных разработчиков, чьи машины теперь потенциально скомпрометированы.
Атрибуция кампании указывает на группировку с внутренним именем SuccessKey. Первая активность криптокошельков, привязанных к ViteVenom, зафиксирована 27 февраля 2026 года — то есть инфраструктура готовилась заранее, за месяцы до публикации самих пакетов. Сами пакеты появились на npm в узком окне с 29 июня по 3 июля 2026 года.
Связь с предыдущей кампанией ChainVeil установили не по совпадению стиля кода, а по инфраструктуре второго уровня — тот же кошелёк Tron, тот же аккаунт Aptos, та же транзакция BSC используются в обеих атаках. При этом имена пакетов разные, аккаунты сопровождающих разные, кошельки первого уровня и пути к вредоносным файлам тоже отличаются. В Checkmarx это объяснили не совпадением, а осознанной стратегией: «Поверхностные различия — разные имена пакетов, разные аккаунты сопровождающих, разные кошельки первого уровня, разные пути к вредоносным файлам — согласуются с тем, как один оператор распределяет несколько каналов дистрибуции, чтобы ограничить риск обнаружения».
Разница между ChainVeil и ViteVenom в основном в выборе цели: если в первой волне подделывали разрозненные, никак не связанные друг с другом библиотеки под видом опечаток в названиях (типосквоттинг вроде «rate-limit-flexible»), то во второй волне атакующие сосредоточились на одном скоуп-пространстве — @vitejs — и подделывали его целиком, рассчитывая на доверие разработчиков к официальному неймспейсу.
Для тех, кто уже установил один из перечисленных пакетов, действия стандартные, но откладывать их нельзя: удалить заражённые зависимости, провести аудит всего дерева пакетов проекта, сменить все учётные данные, которые могли быть скомпрометированы, и проверить файлы.bashrc,.zshrc и.profile на предмет несанкционированных изменений — именно туда RAT-трояны такого типа обычно прописывают механизмы持ойкости.


Новое на сайте

Ссылка