- 28,791
- 46
- 8 Ноя 2022
Бэкдоры OctLurk и SilkLurk работают только в памяти компьютера и не оставляют следов на диске.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Серийный номер системного диска или имя компьютера превращались в ключ, без которого вредоносная программа не могла раскрыть собственный код. Касперский обнаружил две ранее неизвестные модульные программы OctLurk и SilkLurk, применявшиеся в шпионских атаках на государственные и связанные с государством организации в Центральной Азии и Сирии. Кампания продолжается как минимум с января 2025 года, говорится в техническом отчете .
Следы заражений нашли в Афганистане, Кыргызстане, Таджикистане, Узбекистане, Казахстане и Сирийской Арабской Республике. Среди пострадавших оказались учреждения здравоохранения, исследовательские центры, государственные ведомства, министерства иностранных дел, правоохранительные органы, логистические компании, организации городского планирования и управления объектами, а также государственные образовательные учреждения.
Специалисты со средней степенью уверенности связывают OctLurk и SilkLurk с одним китаеязычным оператором. Привязать кампанию к известной группировке пока не удалось. Вывод основан на совместном присутствии двух бэкдоров на зараженных компьютерах, совпадении рабочих каталогов и эпизоде, в котором злоумышленники загрузили SilkLurk через командную оболочку OctLurk.
Загрузчики OctLurk и SilkLurk готовились отдельно для каждой жертвы. OctLurk формировал ключ на основе серийного номера диска C:, а SilkLurk вычислял 32-битный хеш имени компьютера. Полученные значения использовались для расшифровки пути к полезной нагрузке и самого вредоносного кода. Копия загрузчика, перенесенная на другую машину, могла не запуститься или не раскрыть исследователям основной модуль.
Разработчики дополнительно усложнили анализ с помощью запутанного кода, сжатия zlib, двойного XOR-шифрования и нескольких наборов арифметических и логических операций. Основные бэкдоры и дополнительные плагины работали преимущественно в оперативной памяти, а на диске оставался небольшой загрузчик. Работа в памяти снижала количество заметных файлов и мешала автоматическим системам анализа воспроизвести заражение в изолированной среде.
Для установки OctLurk злоумышленники использовали административные учетные данные и создавали на удаленных компьютерах запланированную задачу GoogleUpDate. Задача запускала пакетный сценарий с правами учетной записи System, после чего сценарий регистрировал службу Windows и подключал вредоносную DLL-библиотеку. Загрузчик расшифровывал полезную нагрузку, внедрял бэкдор в память и соединялся с управляющим сервером через порт 443.
OctLurk передавал сведения о версии операционной системы, имени компьютера, пользователе, локальном имени узла, IP-адресе, дате и времени. Перед отправкой информация сжималась с помощью zlib и дважды шифровалась по схеме XOR, причем один из ключей состоял из 83 случайных байтов. Управляющий сервер мог прислать команду или дополнительный плагин.
Исследователи изучили модули для запуска командной оболочки, работы с файлами и управления взаимодействием с компьютером. Операторы получали возможность искать, читать, создавать, копировать, перемещать, переименовывать и удалять файлы, менять временные метки, запускать программы, делать снимки экрана, читать и изменять буфер обмена, двигать указатель мыши и имитировать нажатия клавиш.
После закрепления злоумышленники подробно изучали зараженные системы. Пакетные сценарии собирали сведения об оборудовании, программах, активных сеансах, процессах, сетевой конфигурации, антивирусах, настройках Microsoft Defender, открытых портах, DNS-кеше, автозагрузке и запланированных задачах. Отдельные команды выгружали журналы успешных удаленных входов, включая подключения по RDP.
Для кражи учетных данных применялась исполняемая версия Impacket secretsdump, извлекавшая хеши паролей с контроллеров домена. После выгрузки хешей злоумышленники запрашивали список участников группы Domain Controllers, вероятно, чтобы найти дополнительные контроллеры домена для дальнейшего продвижения.
Кейлоггер сохранял нажатия клавиш и содержимое буфера обмена в двух файлах, предварительно изменяя каждый байт собранных данных. Отдельная программа извлекала пароли из Chrome и Firefox. Операторы также устанавливали агент удаленного управления Pandora RC .
Для разведки внутри сети применялся Fscan . Сканер искал доступные узлы, уязвимости и сетевые службы, включая SSH на порте 22 и MySQL на порте 3306, а затем пытался подключаться с учетными данными из заранее подготовленного файла. Команда curl использовалась для соединения с почтовыми серверами, проверки логинов и паролей и выбора папки входящих сообщений.
Вместе с OctLurk операторы разворачивали LurkProxy. Утилита использовала почти ту же архитектуру, но служила не бэкдором, а обратным прокси-сервером. LurkProxy прослушивал порт 64980 на всех сетевых интерфейсах, устанавливал защищенное TLS-соединение с управляющим сервером и передавал пакеты через собственный бинарный протокол со сжатием zlib и двойным XOR-шифрованием.
LurkProxy поддерживал два режима. Первый превращал зараженный компьютер в SOCKS5-прокси и позволял направлять двусторонний трафик к выбранным адресам через инфраструктуру жертвы. Второй работал как прозрачный прокси с заранее заданными адресом и портом. В изученном образце операторы активировали SOCKS5.
SilkLurk закреплялся иначе. Злоумышленники регистрировали службы, запускавшие легитимные программы NVIDIA и Realtek, рядом с которыми размещались вредоносные DLL-библиотеки. Штатные приложения подхватывали подмененные компоненты через DLL side-loading. Загрузчик проверял процесс, переносил зашифрованный файл полезной нагрузки в заданный каталог, создавал службу RmSs с автоматическим запуском и перезапуском после сбоя, а затем расшифровывал и внедрял бэкдор в память.
Конфигурация SilkLurk могла содержать до четырех управляющих серверов и параметры двух прокси. После подключения бэкдор передавал имя компьютера, DNS-домен, имя пользователя, архитектуру процессора, версию и сборку Windows, IP-адрес, идентификатор процесса, время работы системы и имя вредоносного модуля. Операторы могли запросить локальное время, изменить паузу перед повторным подключением, получить или обновить конфигурацию, загрузить дополнительные модули в память и вызвать функции плагинов.
Во время одной из атак SilkLurk открыл командную оболочку и запустил PowerShell. Злоумышленники подключались к общим сетевым папкам с административными учетными данными, искали конфиденциальные документы и после завершения поиска отключали сетевые ресурсы, чтобы скрыть сведения о посещенных серверах. Украденные файлы упаковывались легитимными копиями WinRAR и 7-Zip.
Через SilkLurk также установили PlugX. Отдельный файл развернул легитимную программу Symantec, вредоносный загрузчик и зашифрованную полезную нагрузку. PlugX внедрялся в процесс svchost.exe, закреплялся как служба SymantecRAS и использовал идентификатор кампании KG_MFA.
Управляющие домены SilkLurk и PlugX находились в одной зоне kozow.com. Модульный троян удаленного доступа PlugX применяется как минимум с 2008 года и исторически связан с китаеязычными субъектами угроз. Совпадение инфраструктуры и использование PlugX стали дополнительными основаниями для предварительной атрибуции кампании.
Инфраструктура OctLurk, SilkLurk и LurkProxy строилась на виртуальных частных серверах. Часть адресов OctLurk и LurkProxy совпала с инфраструктурой кампании против критически важных объектов Казахстана, описанной в презентации ГТС .
В марте 2025 года атакующие применяли Linux-бэкдор TrustFall, известный также под названиями MystRodX и SilentRaid . В октябре 2025 года исследователи ГТС нашли новые образцы и дополнительные управляющие серверы, причем три адреса позднее использовались OctLurk и LurkProxy.
Совпадение инфраструктуры указывает на связь нескольких кампаний, нацеленных на Windows и Linux, но не доказывает одновременную работу или единое управление. В отчете не описан первоначальный способ проникновения в организации. Наблюдаемая активность показывает, что после получения административного доступа операторы создавали несколько независимых каналов управления, похищали учетные данные и ставили дополнительные средства удаленного доступа, чтобы сохранить присутствие после обнаружения одного из компонентов.
Полный список доменов, IP-адресов, хешей файлов, имен служб и путей к вредоносным компонентам опубликован в индикаторах компрометации .
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Серийный номер системного диска или имя компьютера превращались в ключ, без которого вредоносная программа не могла раскрыть собственный код. Касперский обнаружил две ранее неизвестные модульные программы OctLurk и SilkLurk, применявшиеся в шпионских атаках на государственные и связанные с государством организации в Центральной Азии и Сирии. Кампания продолжается как минимум с января 2025 года, говорится в техническом отчете .
Следы заражений нашли в Афганистане, Кыргызстане, Таджикистане, Узбекистане, Казахстане и Сирийской Арабской Республике. Среди пострадавших оказались учреждения здравоохранения, исследовательские центры, государственные ведомства, министерства иностранных дел, правоохранительные органы, логистические компании, организации городского планирования и управления объектами, а также государственные образовательные учреждения.
Специалисты со средней степенью уверенности связывают OctLurk и SilkLurk с одним китаеязычным оператором. Привязать кампанию к известной группировке пока не удалось. Вывод основан на совместном присутствии двух бэкдоров на зараженных компьютерах, совпадении рабочих каталогов и эпизоде, в котором злоумышленники загрузили SilkLurk через командную оболочку OctLurk.
Загрузчики OctLurk и SilkLurk готовились отдельно для каждой жертвы. OctLurk формировал ключ на основе серийного номера диска C:, а SilkLurk вычислял 32-битный хеш имени компьютера. Полученные значения использовались для расшифровки пути к полезной нагрузке и самого вредоносного кода. Копия загрузчика, перенесенная на другую машину, могла не запуститься или не раскрыть исследователям основной модуль.
Разработчики дополнительно усложнили анализ с помощью запутанного кода, сжатия zlib, двойного XOR-шифрования и нескольких наборов арифметических и логических операций. Основные бэкдоры и дополнительные плагины работали преимущественно в оперативной памяти, а на диске оставался небольшой загрузчик. Работа в памяти снижала количество заметных файлов и мешала автоматическим системам анализа воспроизвести заражение в изолированной среде.
Для установки OctLurk злоумышленники использовали административные учетные данные и создавали на удаленных компьютерах запланированную задачу GoogleUpDate. Задача запускала пакетный сценарий с правами учетной записи System, после чего сценарий регистрировал службу Windows и подключал вредоносную DLL-библиотеку. Загрузчик расшифровывал полезную нагрузку, внедрял бэкдор в память и соединялся с управляющим сервером через порт 443.
OctLurk передавал сведения о версии операционной системы, имени компьютера, пользователе, локальном имени узла, IP-адресе, дате и времени. Перед отправкой информация сжималась с помощью zlib и дважды шифровалась по схеме XOR, причем один из ключей состоял из 83 случайных байтов. Управляющий сервер мог прислать команду или дополнительный плагин.
Исследователи изучили модули для запуска командной оболочки, работы с файлами и управления взаимодействием с компьютером. Операторы получали возможность искать, читать, создавать, копировать, перемещать, переименовывать и удалять файлы, менять временные метки, запускать программы, делать снимки экрана, читать и изменять буфер обмена, двигать указатель мыши и имитировать нажатия клавиш.
После закрепления злоумышленники подробно изучали зараженные системы. Пакетные сценарии собирали сведения об оборудовании, программах, активных сеансах, процессах, сетевой конфигурации, антивирусах, настройках Microsoft Defender, открытых портах, DNS-кеше, автозагрузке и запланированных задачах. Отдельные команды выгружали журналы успешных удаленных входов, включая подключения по RDP.
Для кражи учетных данных применялась исполняемая версия Impacket secretsdump, извлекавшая хеши паролей с контроллеров домена. После выгрузки хешей злоумышленники запрашивали список участников группы Domain Controllers, вероятно, чтобы найти дополнительные контроллеры домена для дальнейшего продвижения.
Кейлоггер сохранял нажатия клавиш и содержимое буфера обмена в двух файлах, предварительно изменяя каждый байт собранных данных. Отдельная программа извлекала пароли из Chrome и Firefox. Операторы также устанавливали агент удаленного управления Pandora RC .
Для разведки внутри сети применялся Fscan . Сканер искал доступные узлы, уязвимости и сетевые службы, включая SSH на порте 22 и MySQL на порте 3306, а затем пытался подключаться с учетными данными из заранее подготовленного файла. Команда curl использовалась для соединения с почтовыми серверами, проверки логинов и паролей и выбора папки входящих сообщений.
Вместе с OctLurk операторы разворачивали LurkProxy. Утилита использовала почти ту же архитектуру, но служила не бэкдором, а обратным прокси-сервером. LurkProxy прослушивал порт 64980 на всех сетевых интерфейсах, устанавливал защищенное TLS-соединение с управляющим сервером и передавал пакеты через собственный бинарный протокол со сжатием zlib и двойным XOR-шифрованием.
LurkProxy поддерживал два режима. Первый превращал зараженный компьютер в SOCKS5-прокси и позволял направлять двусторонний трафик к выбранным адресам через инфраструктуру жертвы. Второй работал как прозрачный прокси с заранее заданными адресом и портом. В изученном образце операторы активировали SOCKS5.
SilkLurk закреплялся иначе. Злоумышленники регистрировали службы, запускавшие легитимные программы NVIDIA и Realtek, рядом с которыми размещались вредоносные DLL-библиотеки. Штатные приложения подхватывали подмененные компоненты через DLL side-loading. Загрузчик проверял процесс, переносил зашифрованный файл полезной нагрузки в заданный каталог, создавал службу RmSs с автоматическим запуском и перезапуском после сбоя, а затем расшифровывал и внедрял бэкдор в память.
Конфигурация SilkLurk могла содержать до четырех управляющих серверов и параметры двух прокси. После подключения бэкдор передавал имя компьютера, DNS-домен, имя пользователя, архитектуру процессора, версию и сборку Windows, IP-адрес, идентификатор процесса, время работы системы и имя вредоносного модуля. Операторы могли запросить локальное время, изменить паузу перед повторным подключением, получить или обновить конфигурацию, загрузить дополнительные модули в память и вызвать функции плагинов.
Во время одной из атак SilkLurk открыл командную оболочку и запустил PowerShell. Злоумышленники подключались к общим сетевым папкам с административными учетными данными, искали конфиденциальные документы и после завершения поиска отключали сетевые ресурсы, чтобы скрыть сведения о посещенных серверах. Украденные файлы упаковывались легитимными копиями WinRAR и 7-Zip.
Через SilkLurk также установили PlugX. Отдельный файл развернул легитимную программу Symantec, вредоносный загрузчик и зашифрованную полезную нагрузку. PlugX внедрялся в процесс svchost.exe, закреплялся как служба SymantecRAS и использовал идентификатор кампании KG_MFA.
Управляющие домены SilkLurk и PlugX находились в одной зоне kozow.com. Модульный троян удаленного доступа PlugX применяется как минимум с 2008 года и исторически связан с китаеязычными субъектами угроз. Совпадение инфраструктуры и использование PlugX стали дополнительными основаниями для предварительной атрибуции кампании.
Инфраструктура OctLurk, SilkLurk и LurkProxy строилась на виртуальных частных серверах. Часть адресов OctLurk и LurkProxy совпала с инфраструктурой кампании против критически важных объектов Казахстана, описанной в презентации ГТС .
В марте 2025 года атакующие применяли Linux-бэкдор TrustFall, известный также под названиями MystRodX и SilentRaid . В октябре 2025 года исследователи ГТС нашли новые образцы и дополнительные управляющие серверы, причем три адреса позднее использовались OctLurk и LurkProxy.
Совпадение инфраструктуры указывает на связь нескольких кампаний, нацеленных на Windows и Linux, но не доказывает одновременную работу или единое управление. В отчете не описан первоначальный способ проникновения в организации. Наблюдаемая активность показывает, что после получения административного доступа операторы создавали несколько независимых каналов управления, похищали учетные данные и ставили дополнительные средства удаленного доступа, чтобы сохранить присутствие после обнаружения одного из компонентов.
Полный список доменов, IP-адресов, хешей файлов, имен служб и путей к вредоносным компонентам опубликован в индикаторах компрометации .
- Источник новости
- www.securitylab.ru
