Многоступенчатая атака на разработчиков Alibaba через npm-пакеты оставалась незамеченной три месяца

Всё началось с пакета lib-mtop, опубликованного три года назад, но в конце марта 2026 года получившего три новых версии. Это указывает на возможный взлом учётной записи сопровождающего, хотя нельзя исключать и его собственных недобросовестных действий. Пакет имитировал название частного модуля из пространства @ali, которое недоступно для регистрации на npm и, вероятно, зарезервировано самой Alibaba. Подобные имена используются для внутренних проектов и инструментов компании.

Сам по себе lib-mtop содержал классический вредоносный загрузчик: он скачивал удалённый JavaScript-код через curl и запускал его. Однако куда более интересным оказался другой пакет, local-config-parser, опубликованный с той же учётной записи. Он описывался как "парсер JSON-конфигураций со встроенным механизмом оценки правил" и действительно реализовывал заявленную логику, используя изолированную среду Node.js vm для безопасного выполнения кода. На первый взгляд он был совершенно безобидным, но анализ контекста и дерева зависимостей вскрыл, что безобидные на вид пакеты, опубликованные разными учётными записями, в совокупности образуют вредоносный загрузчик.

Кампания была развёрнута 27-28 апреля 2026 года. Сначала злоумышленники опубликовали два пробных пакета, а затем, 28 апреля, через несколько новых аккаунтов выложили остальную цепочку зависимостей. Всего было создано 10 пакетов-приманок, которые не содержали никакого функционала, а только объявляли зависимость от пакетов из пространства @ali. В момент установки такие пакеты, попав в среду с доступом к внутренним репозиториям Alibaba, активировали дополнительную цепочку, включающую пакет smart-config-manager и его зависимости: cloud-config-fetcher и local-config-parser.

Именно эти три пакета вместе реализуют скачивание и выполнение вредоносного кода. Пакет cloud-config-fetcher при инициализации скачивал файл конфигурации из репозитория GitHub, подконтрольного атакующим. Пакет local-config-parser считывал эту конфигурацию и выполнял содержащиеся в ней правила. При этом вредоносный код прятался внутри одного из правил, внешне похожего на обычное вычисление множителей. Для обхода изоляции, предоставляемой модулем vm, злоумышленники использовали классическую технику побега из песочницы: через конструктор объекта items они получали доступ к глобальному конструктору Function, а затем и к объекту process Node.js за пределами изолированной среды. Далее код пытался получить доступ к системе загрузки модулей Node.js шестью разными способами и при успехе загружал следующий этап полезной нагрузки с сервера, также расположенного в инфраструктуре Alibaba Cloud, чтобы маскироваться под легитимный трафик.

Второй этап выполнял разведку и сбор информации об устройстве жертвы. В зависимости от платформы применялись разные методы закрепления:

• на macOS в файл ~/.zshrc добавлялся вредоносный фоновый скрипт и создавался Launch Agent с интервалом в 10 минут;
• на Windows останавливался официальный защитный процесс Alilang и подменялся его основной файл (app.asar) на троянскую копию;
• на Linux загружался бинарный файл в /tmp, запускался в фоне, а затем удалялся с диска после загрузки в память.

Финальная полезная нагрузка, названная aone-cli (по аналогии с внутренней R&D-инфраструктурой Alibaba), представляла собой кроссплатформенный RAT с широким спектром возможностей: выполнение команд, загрузка и выгрузка файлов, разведка, создание зашифрованного обратного TCP-прокси, а также боковое перемещение через DingTalk - корпоративный мессенджер, популярный в китайской среде. Вредонос автоматически регистрировался на командно-контрольном сервере и ожидал команд. Среди них были не только типовые (сбор информации, скриншоты, работа с файлами), но и специализированные: "aipoison", "aipoison_inject", "aipoison_deploy" и "dws_lateral", предназначенные для внедрения вредоносного кода в инструменты разработки и управления, такие как DingTalk, Wukong и Qoder.

Механизм закрепления включал отравление AI-инструментов: в Python-скрипты внутри каталогов .skills этих приложений вставлялся код, который при каждом запуске инструмента запускал ранее скачанный скрипт. Код был тщательно замаскирован - например, сетевые запросы к C2-серверу снабжались поддельными HTTP-заголовками Origin и Referer, указывающими на страницы DingTalk, чтобы трафик выглядел естественным. Код на поздних стадиях содержал комментарии на китайском языке, а временные метки коммитов в GitHub соответствовали часовому поясу UTC+8 (стандартное китайское время). Хотя эти данные могут быть сфабрикованы, они указывают на возможную принадлежность атакующих к китайской языковой среде.

Цель кампании, судя по всему - промышленный шпионаж. Количество загрузок вредоносных пакетов невелико, однако из-за возможностей латерального перемещения и скрытности истинное число скомпрометированных машин оценить сложно. То, что инфраструктура атаки оставалась активной более трёх месяцев после публикации, свидетельствует о высоком уровне организации.

Для защиты организаций, входящих в экосистему Alibaba, рекомендуется проверить все машины разработчиков на наличие упомянутых пакетов, а также искать признаки активности: наличие инъекций в Python-файлы с маркером "# __INJECT_MARKER__", сетевые запросы с поддельными заголовками Origin и Referer, а также подозрительную активность в DingTalk. При обнаружении заражения необходимо проводить восстановление с чистой машины, ротировать все ключи и секреты, и сохранять криминалистические артефакты до очистки.