Исследователи обнаружили два ранее не описанных вредоносных модуля удалённого доступа для Windows — OctLurk и SilkLurk. Их загрузчики используют параметры конкретного компьютера при расшифровке основной полезной нагрузки: OctLurk — серийный номер диска C:, SilkLurk — имя компьютера. Такой приём мешает автоматическому анализу: образец, перенесённый в обычную лабораторную систему с другими параметрами, может расшифроваться неправильно. При наличии исходных значений исследователь теоретически может воспроизвести нужное окружение.
Кампанию отслеживают как минимум с января 2025 года. Подтверждённые жертвы находились в Афганистане, Казахстане, Кыргызстане, Сирии, Таджикистане и Узбекистане. Среди затронутых организаций исследователи называют государственные учреждения, дипломатические структуры, правоохранительные органы, медицинские и исследовательские организации, логистику, городскую инфраструктуру и образовательные учреждения.
Первый подробный технический разбор OctLurk и SilkLurk команда Kaspersky GReAT опубликовала 30 июля 2026 года. PolySwarm выпустил собственный обзор 6 августа.
В одном из расследованных эпизодов злоумышленники уже располагали административными учётными данными. С их помощью на удалённой машине создавалась задача Windows с именем GoogleUpDate. Она однократно запускала командный файл с правами SYSTEM, после чего создавалась служба NgcCIntSvc, загружавшая вредоносную библиотеку oleasapi.dll.
Этот фрагмент важен ещё и потому, что он не раскрывает первоначальный способ проникновения в организацию. Исследователи показывают уже этап, на котором оператор имеет административные данные и перемещается по сети. Из опубликованного отчёта нельзя сделать вывод, что OctLurk распространялся через фишинг, уязвимость нулевого дня или заражённые документы.
Загрузчик OctLurk хранит путь к основной полезной нагрузке и её содержимое в зашифрованном и сжатом виде. Для расшифровки используются два многобайтных ключа. Один встроен непосредственно в загрузчик, второй формируется из серийного номера диска C:. После двойного преобразования XOR данные распаковываются с помощью zlib.
Полученная библиотека не просто запускается с диска. Загрузчик помещает её непосредственно в память процесса и передаёт управление точке входа. В этом случае, если исследователь заберёт один только загрузчик и отправит его в песочницу, где системный диск имеет другой серийный номер, вычисленный ключ изменится. Основной модуль может не раскрыться корректно. Это дополнительный барьер, заставляющий учитывать параметры исходной системы.
После запуска OctLurk собирает сведения о системе: версию Windows, имя компьютера и пользователя, локальное имя узла, IP-адрес, дату и время. Затем устанавливается связь с управляющей инфраструктурой.
Главный модуль построен как основа для подключаемых компонентов. Дополнительные функции оператор может получать с управляющего сервера непосредственно в память.
Исследователи разобрали три основных расширения: командную оболочку, файловый менеджер и модуль управления интерфейсом. Последний умеет снимать весь экран, делать снимки через заданные интервалы, читать и изменять буфер обмена, перемещать курсор, нажимать кнопки мыши и имитировать нажатия клавиш.
Файловый компонент позволяет перечислять диски и каталоги, искать файлы, читать их содержимое, копировать, перемещать, переименовывать и удалять данные, создавать папки и менять временные метки.
Командный модуль запускает команды через cmd.exe и передаёт результат обратно управляющему серверу. Получается довольно гибкая конструкция: первоначальному модулю не нужно постоянно хранить на диске весь набор возможностей.
Исследованная кампания заметно шире самих OctLurk и SilkLurk. На заражённых системах использовалась исполняемая версия secretsdump.py из набора Impacket. С её помощью злоумышленники извлекали хеши паролей с контроллеров домена Active Directory. После этого они проверяли состав группы Domain Controllers, вероятно, для поиска дополнительных серверов.
Отдельный перехватчик клавиатуры сохранял нажатия клавиш и содержимое буфера обмена в файлы на диске. Инструмент Browser Password Decryptor применялся для извлечения сохранённых учётных данных Chrome и Firefox.
Для разведки сети использовался Fscan. В расследованных эпизодах он проверял внутренние и внешние адреса, искал открытые службы, включая SSH и MySQL, и пытался подключаться к ним с данными из подготовленного файла паролей.
Оператор также устанавливал Pandora RC — легитимное средство удалённого администрирования. То есть даже удаление собственного вредоносного модуля не обязательно лишало злоумышленника доступа к системе.
Через OctLurk запускались штатные средства Windows и PowerShell. Оператор проверял активные сеансы пользователей, процессы, сетевые настройки, текущие TCP-соединения, установленные антивирусы, состояние Microsoft Defender, исключения защиты, пользователей, элементы автозагрузки, задачи планировщика и сведения об аппаратной части компьютера.
Отдельно выгружались события успешного удалённого входа. В отчёте приведён запрос к журналу Security по событию 4624 с типом входа 10 — это удалённый интерактивный сеанс, например RDP.
Исследователи также заметили работу с почтой. Через curl оператор соединялся с почтовым сервером, проходил аутентификацию и выбирал папку Inbox. Сам отчёт отмечает, что такое действие подготавливает почтовый ящик к чтению или другим операциям с сообщениями.
У SilkLurk используется другая схема запуска. Злоумышленники создавали службы Windows, которые запускали легитимные программы NVIDIA и Realtek. Среди изученных вариантов — NetSetSvc.exe, nvgwls.exe, RtkSmbus.exe и RtkNGUI64.exe. Рядом размещались библиотеки с нужными именами — например, nvml.dll или vulkan-1.dll. Легитимная программа загружала такую библиотеку, а та уже помещала SilkLurk в память процесса.
Эта техника известна как подмена загружаемой DLL: программа сама доверенно запускается в системе, но подхватывает библиотеку, которую ей подготовил злоумышленник.
В одном из изученных вариантов загрузчик создавал службу RmSs, настроенную на автоматический запуск. При сбое Windows должна была запускать её повторно.
Основное отличие загрузчика SilkLurk — параметр, которым он привязывает зашифрованные данные к жертве. Код вычисляет 32-битный хеш имени компьютера. Полученное значение участвует в расшифровке пути к полезной нагрузке и самих данных. После этого отдельный код-загрузчик повторно использует хеш имени машины при раскрытии и размещении основного модуля в памяти.
Именно поэтому два загрузчика работают по похожей идее, но используют разные признаки:
OctLurk — серийный номер системного диска;
SilkLurk — имя компьютера.
В обоих случаях задача одна: сделать конкретный образец зависимым от окружения, для которого он был подготовлен.
В конфигурации SilkLurk может храниться до четырёх адресов управляющих серверов, а также данные прокси-серверов.
После подключения модуль создаёт случайный 32-байтовый сетевой ключ, который затем используется для шифрования и расшифровки сетевого обмена. Ключ передаётся управляющему серверу внутри блока, дополнительно защищённого собственным алгоритмом.
После установки канала SilkLurk передаёт сведения о машине, включая имя компьютера, домен, пользователя, архитектуру процессора, версию ОС, IP-адрес и идентификатор процесса. Как и OctLurk, он способен получать дополнительные модули и запускать их непосредственно в памяти.
В одном из расследованных эпизодов SilkLurk использовался для запуска cmd.exe, а затем PowerShell. Через net use оператор подключался к общим сетевым ресурсам с административными учётными данными и искал там конфиденциальные документы. После завершения поиска подключение к сетевой папке закрывалось. Исследователи интерпретируют это как попытку сократить следы доступа к внутренним серверам. Собранные файлы упаковывались обычными WinRAR и 7-Zip.
Это хороший пример смешивания специализированной малвари с обычными административными программами: часть действий выполняет собственный скрытый модуль, часть — привычные утилиты Windows и сторонние инструменты.
SilkLurk был не последним звеном цепочки. В одном случае через его командную оболочку оператор запустил kmsonline.exe. Этот файл разворачивал ещё один модуль удалённого доступа. Система Kaspersky Threat Attribution Engine обнаружила высокую степень сходства образца с PlugX.
PlugX устанавливался отдельно и использовал собственную службу SymantecRAS и собственный управляющий адрес. Такой подход создаёт резервные каналы присутствия. Даже если защитник найдёт SilkLurk, это ещё не доказывает, что доступ злоумышленника полностью закрыт.
Отдельный компонент исследователи назвали LurkProxy. Архитектура у него действительно очень близка к OctLurk, но Kaspersky специально подчёркивает: сам LurkProxy не является бэкдором. Его основная задача — перенаправление сетевого трафика.
Изученный вариант слушал все сетевые интерфейсы на порту 64980 и устанавливал защищённое TLS-соединение с управляющим сервером. Передаваемые пакеты дополнительно сжимались zlib и преобразовывались двойным XOR.
У LurkProxy предусмотрены два режима работы. Первый использует SOCKS5. Во втором целевой адрес заранее встроен в конфигурацию, а через заражённую систему проходит обычный TCP-трафик. В изученном образце был активен SOCKS5-режим.
Фактически заражённый компьютер может становиться промежуточной точкой, через которую оператор получает доступ к другим сетевым ресурсам.
Исследователи нашли несколько технических пересечений между двумя семействами. На части заражённых машин присутствовали оба инструмента. В одном инциденте оператор сначала получил командную оболочку через OctLurk, а затем через неё загрузил библиотеку SilkLurk vulkan-1.dll. В другом случае компоненты обоих семейств находились в одном каталоге C:\ProgramData\intel\. Эти наблюдения позволяют достаточно уверенно говорить, что OctLurk и SilkLurk использует один оператор.
С атрибуцией дальше всё осторожнее. Kaspersky оценивает со средней степенью уверенности, что оператор является китайскоязычным. Конкретной известной группировке кампанию на момент публикации не приписали.
В отчёте упоминается PlugX, который исторически использовался китайскоязычными группами, однако этого недостаточно для автоматической привязки кампании к конкретной команде.
Часть инфраструктуры OctLurk и LurkProxy ранее появлялась в отчёте Государственной технической службы Казахстана о другой вредоносной кампании. В ней использовался Linux-инструмент TrustFall, известный также под названиями MystRodX и SilentRaid. Исследователи обнаружили три управляющих адреса, которые встречались и у TrustFall, и у OctLurk/LurkProxy. Сам отчёт сразу ставит ограничение на этот вывод: неизвестно, работали ли кампании одновременно.
Совпадение инфраструктуры может указывать на общие ресурсы, аренду одних и тех же серверов или связь между операциями, но само по себе не доказывает общего автора.
Kaspersky очень подробно описывает развёртывание OctLurk после получения доступа: использование административных учётных данных, задач планировщика, служб Windows и командных файлов.
При этом единый подтверждённый первоначальный способ проникновения в организации в опубликованной части исследования не приведён. Из отчёта достоверно известно другое: в ряде эпизодов на этапе развёртывания инструментов оператор уже располагал административными учётными данными.
PolySwarm опубликовал собственный обзор 6 августа и сообщил, что располагает образцом OctLurk с SHA-256:
9ea2f55c1c91d04820f5082cf113c73c6320b157baa98d69654117cfc8458296
Материал подтверждает основную картину: машинно-зависимую расшифровку, выполнение основной логики в памяти, модульную архитектуру, дополнительные инструменты кражи учётных данных и использование LurkProxy.
При этом PolySwarm прямо ссылается на исследование Kaspersky и не представляет свою публикацию как первоначальное обнаружение OctLurk и SilkLurk.
В одном месте обзор PolySwarm идёт дальше исходного технического отчёта и связывает набор целей с долгосрочными интересами Китая. Это уже аналитическая интерпретация PolySwarm. Сам Kaspersky ограничивается более осторожной оценкой о китайскоязычном операторе со средней степенью уверенности. Поэтому для новостного текста безопаснее придерживаться именно второй формулировки.
Kaspersky опубликовал часть индикаторов компрометации: управляющие домены и IP-адреса, хеши загрузчиков, компонентов OctLurk и SilkLurk, PlugX и вспомогательных файлов. Среди инфраструктуры OctLurk присутствуют, например, dns[.]multitoconference[.]com и tj[.]tajikistandip[.]com, а для LurkProxy — dns[.]ssentialserv[.]xyz.
Одних хешей здесь недостаточно. Кампания активно использует легитимные программы, системные команды и подгружаемые в память компоненты. При поиске следов полезно сопоставлять сразу несколько признаков: неожиданные службы и задачи, запуск приложений NVIDIA или Realtek с подозрительными библиотеками рядом, появление Fscan или secretsdump, необычные архиваторы в системных каталогах, новые средства удалённого управления и соединения с известной управляющей инфраструктурой. Эти признаки следуют из цепочек, которые исследователи наблюдали в реальных заражениях.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
