Вредоносные npm-пакеты заражают Windows через установку

Недавний анализ в области cybersecurity выявил сложную кампанию атак, в которой злоумышленники использовали пять npm-пакетов для доставки Windows-binary loader. Кампания, зафиксированная 16 июня 2026 года, была построена так, чтобы каждый отдельный компонент выглядел безобидно при самостоятельной проверке, но в совокупности образовывал полноценную цепочку заражения.

По данным отчета, атакующий намеренно разделил вредоносную функциональность между несколькими пакетами. Такой подход осложняет обнаружение: один пакет отвечает за загрузку, другой — за сокрытие командного канала, третий — за поддержку инфраструктуры на стороне сервера. В результате вредоносная активность растворяется в обычной экосистеме npm.

Какие пакеты использовались

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

• procwire@1.3.0 — выполняет роль загрузчика Windows-binary;
• routecraft@4.2.0 — маскируется под клон Express и подключает procwire на системах Windows;
• bytecraft — утилита XOR;
• endpointmap — кодирует URL-адреса управления C2;
• staticlayer — серверный компонент для обслуживания загрузчика.

Отдельно отмечается, что каждый пакет содержал правдоподобное описание, рассчитанное на доверие разработчиков и автоматических систем анализа. Так, procwire позиционировался как библиотека жизненного цикла и IPC, а bytecraft — как библиотека для преобразования буферов.

Как начиналась атака

Эксплуатация запускалась через хук preinstall в пакете procwire, который выполнялся во время установки npm. Этот этап был ключевым: именно он декодировал конечную точку C2, спрятанную в виде массивов байтов и закодированную с помощью XOR в пакете endpointmap.

После декодирования инфраструктуры управления загрузчик незаметно скачивал и запускал полезную нагрузку. Примечательно, что атака была нацелена только на Windows-системы: на других платформах выполнение останавливалось.

«Разделение вредоносных операций между пакетами позволяет каждому из них выглядеть безопасным при индивидуальном анализе», — следует из отчета.

Методы загрузки и выполнения

Вредоносное ПО использовало несколько способов произвольного выполнения бинарных файлов на хостах Windows в процессе установки npm. Такая гибкость повышала устойчивость к частичным мерам защиты и затрудняла блокировку всей цепочки сразу.

В частности, применялись:

• три метода загрузки: Node.js HTTPS, curl.exe, bitsadmin;
• три метода выполнения: direct launch, cmd.exe, PowerShell.

Отдельное внимание в отчете уделено обходу Mark-of-the-Web, механизма, предназначенного для подавления предупреждений Windows SmartScreen в отношении загруженных исполняемых файлов. По сути, злоумышленники стремились снизить вероятность того, что пользователь или система безопасности заметят запуск вредоносного файла.

Маскировка под обновления ПО

Пейлоады маскировались под имена, ассоциированные с легитимными обновлениями программного обеспечения, включая msedge_update и chrome_installer. Такая легенда повышает шансы на то, что исполняемый файл не вызовет подозрений у пользователя, аналитика или защитного решения, особенно в среде, где регулярно устанавливаются обновления браузеров и вспомогательных компонентов.

Сложность атаки усиливалась и способом формирования URL-адреса C2: он использовал XOR-шифрование и опирался на имя пакета в качестве секретного ключа. При этом конструкция дроппера намеренно избегала легко обнаруживаемых строк, что снижало эффективность статического анализа.

Резервные механизмы и обход защиты

Сначала дроппер пытался получить полезную нагрузку через HTTP GET-запрос, притворяясь механизмом доставки Microsoft и отключая проверку TLS, чтобы избежать обнаружения. Если основной путь не срабатывал, в ход шли запасные варианты — curl.exe и bitsadmin. Это обеспечивало продолжение загрузки даже при наличии отдельных ограничений или средств защиты.

Дополнительно использовался поддельный альтернативный поток данных Zone.Identifier, который служил для обхода предупреждений SmartScreen. Иными словами, злоумышленники не полагались на один прием: они выстраивали многослойную схему сокрытия и доставки.

Роль staticlayer

Пакет staticlayer дополнял дроппер, работая как сервер для обслуживания полезной нагрузки. При этом он требовал клиента, который имитировал User-Agent дроппера. Такая схема self-hosting ограничивала внешнее воздействие, но одновременно делала инфраструктуру достаточно гибкой для распространения вредоносной нагрузки.

Что показывает этот инцидент

Эта кампания демонстрирует продвинутые evasion-тактики, основанные на дроблении вредоносных функций на незаметные компоненты. Для экосистемы npm это особенно опасно: вредоносный пакет может выглядеть как обычная библиотека, пока не активируется в ходе установки.

Главный вывод отчета заключается в том, что защита не должна ограничиваться проверкой репутации пакетов. Необходим мониторинг поведения при установке, анализ цепочек зависимостей и контроль сетевой активности, особенно если пакет запускает preinstall-скрипты или использует нетипичные методы загрузки исполняемых файлов.

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.