TRON, Aptos и BSC в одной цепочке заражения: разбор JavaScript‑загрузчика, связанного с ChainVeil
16 июня 2026 года команда Checkmarx описала кампанию ChainVeil: атакующие задействовали вредоносные npm пакеты JavaScript и распространяли через них многоступенчатые JavaScript‑загрузчики. Почти одновременно с этим кейсом в руки моего знакомого попал ранее не встречавшийся образец - ирония в том, что отправной точкой стала рекомендация от AI‑помощника. Ему посоветовали репозиторий с "AI‑агентом", он клонировал проект, запустил локально - и антивирус прервал выполнение, пометив объект как вредоносный. При этом конкретного семейства (по крайней мере на уровне понятной "этикетки") выявлено не было, что только подогрело интерес к разбору.
Снаружи всё выглядело буднично: очередной обфусцированный однострочник, случайно попавший в дерево проекта, либо артефакт сборки. Но быстрый взгляд на репозиторий показал, что владелец аккаунта не похож на новичка: сотни (около 320) репозиториев, порядка 50 подписчиков, заполненный профиль. Поэтому ключевой вопрос был не "опасно ли", а "как именно это оказалось в коде и на кого рассчитано".
Сопоставление с описанной кампанией началось с мелочей, но совпадения быстро стали системными. Вредоносный блок содержал узнаваемый для ChainVeil приём с объявлением глобального идентификатора в начале обфусцированного фрагмента. После частичной деобфускации выяснилось, что у меня встретился вариант с префиксом A9, тогда как в ранее опубликованных индикаторах кампании фигурировал блок A6. Важная деталь: в данном случае "контейнером" выступал не npm‑пакет - это был самостоятельный Python‑инструмент с Web‑частью на JavaScript, то есть поверхность атаки шире, чем только экосистема Node.js.
Дальнейший анализ подтвердил: техники один в один укладываются в модель ChainVeil. Здесь и многоступенчатая обфускация JS‑кода, и получение полезной нагрузки из данных блокчейн‑транзакций, и совпадение адресов C2‑инфраструктуры с теми, что ранее уже светились у исследователей. В этом контексте особенно уместно упомянуть подробности, изложенные в материале ChainVeil расследование: общий "почерк" loader'а слишком узнаваем, чтобы списывать его на случайность.
Архитектура загрузчика выглядит нетривиально: он использует несколько блокчейн‑сервисов как резервируемые каналы доставки. Сначала через TRON вытягивается последняя исходящая транзакция контролируемого злоумышленником аккаунта. Если по TRON не удаётся получить нужные данные, включается ветка Aptos: извлечённое значение UTF‑8‑декодируется, затем строка разворачивается и используется как идентификатор транзакции в BSC. Уже из BSC берётся поле `input`, где спрятана закодированная строка, и запускается следующая "мясорубка" преобразований: выдёргивание фрагментов по разделителю `??`, XOR‑декодирование ключом, зашитым в код, а также восстановление строк через функцию перестановки `_$af163278` с фиксированным seed. Благодаря постоянному seed строки удалось вернуть в читаемый вид.
Финалом этой цепочки оказывается код с RAT‑функционалом. Поскольку структура загрузчика, механизм получения полезной нагрузки и конечная стадия совпадают с уже описанными ранее артефактами, повторять детальную разборку последнего слоя нет смысла - куда важнее было понять путь проникновения в конкретный репозиторий.
Чтобы восстановить картину, пришлось поднять историю Git‑коммитов проекта `inbox-ai` и внимательно пройтись по изменениям ключевого файла `navigation.js`. Первое появление файла датируется коммитом a3940ca (ноябрь 2025): тогда `navigation.js` был обычным легитимным скриптом. Заражение проявилось намного позже - 29 марта 2026 года, во время слияния веток в коммите a40301a: в "хвост" файла добавили обфусцированный JS‑однострочник. Причём вставка была замаскирована не только обфускацией: вредоносный фрагмент прятался за большим количеством пробелов, поэтому при беглом просмотре можно было решить, что файл заканчивается раньше.
Этот кейс полезен тем, что показывает: атака не обязана начинаться строго с npm. Да, ChainVeil активно эксплуатировала вредоносные npm пакеты JavaScript, но на практике достаточно компрометации репозитория, шаблона, демо‑проекта или "рекомендованного" AI‑агентом инструмента - и заражение становится частью обычного developer‑workflow. Поэтому одна лишь привычка "не ставить подозрительные пакеты" проблему не закрывает.
Что делать командам на практике - особенно тем, кто пишет Web‑часть для криптопродуктов? Во‑первых, нужна регулярная проверка безопасности npm пакетов и зависимостей в целом: фиксирование lock‑файлов, контроль транзитивных зависимостей, отслеживание неожиданных постинсталл‑скриптов, а также обязательная проверка диффов при обновлениях (включая минимальные патчи). Во‑вторых, стоит внедрять CI‑проверки на подозрительные шаблоны (обфусцированные "однострочники", аномально длинные строки, вставки в конец файлов, странные энтропийные участки кода).
Отдельного внимания требует защита от supply chain атак в JavaScript: подписи релизов, строгие права на публикацию пакетов, 2FA для аккаунтов в npm/Git‑хостингах, раздельные роли для мейнтейнеров и релиз‑менеджеров, а также обязательный code review именно на уровне изменений, а не только на уровне "сборка зелёная". Кейс с прячущимися пробелами хорошо иллюстрирует, почему "просмотрел глазами" без дисциплины ревью легко пропускает внедрения.
Наконец, Web3‑командам имеет смысл смотреть шире, чем смарт‑контракты. Аудит безопасности Web3 проектов TRON Aptos BSC должен включать не только ончейн‑логику, но и клиентский код, сборочные цепочки, CI/CD и инфраструктуру доставки. Атака, которая использует транзакции TRON/Aptos/BSC как транспорт для полезной нагрузки, - это напоминание: блокчейн может быть не только предметом разработки, но и каналом управления вредоносной инфраструктурой.
Для тех, кто хочет сопоставить признаки и цепочку стадий, полезно держать под рукой разбор проверки безопасности npm пакетов и артефактов ChainVeil: сходство по C2, приёмам обфускации и "блокчейн‑доставке" здесь слишком характерное, чтобы игнорировать.