BackDoor.PlugX.38

Упаковщик: отсутствует

Дата компиляции: 02:17:55 24.10.2018

SHA1-хеш:

• e6381d09cdf15973f952430e70547d0b88bb1248 (дамп расшифрованного файла msvsct.ini)

Описание

Многокомпонентный троян-бэкдор, написанный на языке С и предназначенный для работы в 32- и 64-разрядных операционных системах семейства Microsoft Windows. Устанавливается при помощи загрузчика BackDoor.PlugX.26, после чего функционирует в оперативной памяти зараженного компьютера. Используется для целевых атак на информационные системы и несанкционированного доступа к данным для их передачи на управляющие серверы. По принципу действия и алгоритмам работы схож с BackDoor.PlugX.28: используются похожие структуры для хранения и обработки данных, в том числе идентичный объект для хранения строк.

Принцип действия

Все функции WinAPI вызываются динамически по алгоритму CRС32, при этом контрольная сумма считается по всему имени функции, включая завершающий \x00.

Как и у BackDoor.PlugX.28, у рассматриваемой модификации отсутствуют единые соглашения о вызовах пользовательских функций. Шифрование строк достаточно простое, реализовано не в отдельной функции, а встраивается.

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

Предполагаемая структура threads_container:

struct threads_info
{
  LIST_ENTRY p_threads_list;
  DWORD threads_count;
};
struct threads_container
{
  CRITICAL_SECTION crit_sect;
  threads_info threads;
};
struct thread_obj
{
  LIST_ENTRY p_threads;
  DWORD thread_ID;
  threads_container *p_threads_container;
  DWORD (__stdcall *p_function)(LPVOID arg);
  LPVOID arg;
  BYTE *name;
};

Начало работы

После получения управления от загрузчика BackDoor.PlugX.38 инициализирует ряд глобальных объектов, которые будут использоваться в дальнейшем. Затем устанавливает свой обработчик исключений SetUnhandledExceptionFilter. При необрабатываемом исключении функция находит в threads_container идентификатор потока, который вызвал это исключение, и формирует строку по формату:

EName:%s,EAddr:0x%p,ECode:0x%p,EAX:%p,EBX:%p,ECX:%p,EDX:%p,ESI:%p,EDI:%p,EBP:%p,ESP:%p,EIP:%p;

где EName — имя потока. Остальные параметры берутся из структуры EXCEPTION_POINTERS. Строка формируется в локальной переменной и далее никак не используется. После этого обработчик завершает данный поток.

После подготовительных действий троян получает привилегии SeDebugPrivilege и SeTcbPrivilege, затем инициализирует главный поток с именем bootProc, которое хранится в открытом виде.

В начале bootProc вызывает FreeLibrary на модуль с именем msvsct.txt. Далее происходит инициализация конфигурации.

Конфигурация, переданная загрузчиком

Для определения конфигурации загрузчик аргументом передает указатель, по которому BackDoor.PlugX.38 проверяет первые 4 байта. Если аргумент начинается с сигнатуры, это значит, что загрузчиком передана структура shellarg. Сигнатура имеет значение 0x504c5547, что соответствует значению PLUG в кодировке ASCII.

Структура shellarg представлена следующим образом:

struct shellarg
{
  DWORD signature;
  DWORD dword_0;
  DWORD dword_1;
  DWORD p_shellcode;
  DWORD shellcode_size;
  DWORD config;
  DWORD config_size;
};

В этом случае конфигурация из аргумента расшифровывается и сохраняется в глобальной переменной троянской программы. Затем из полученной конфигурации извлекается адрес домашней директории бэкдора. Из этой директории троян пытается прочитать файл boot.cfg, в котором также может храниться конфигурация (например, переданная от управляющего сервера). При наличии файла программа считывает из него конфигурацию, расшифровывает и применяет ее.

Алгоритм шифрования конфигурации:

import struct
  
def DWORD(i):
    return i & 0xFFFFFFFF
  
def LOBYTE(i):
    return i & 0x000000FF
  
def dec(key, in_data):
    k1 = k2 = k3 = k4 = key
    result = ""
    for x in in_data:
        k1 = DWORD(k1 + (k1 >> 3) - 0x11111111)
        k2 = DWORD(k2 + (k2 >> 5) - 0x22222222)
        k3 = DWORD(k3 + 0x33333333 - (k3 << 7))
        k4 = DWORD(k4 + (0x44444444 - (k4 << 9)))
        k = LOBYTE(k1 + k2 + k3 + k4)
        result += chr(ord(x) ^ k)
    return result
  
def decrypt(addr, size):
    data = get_bytes(addr, size, 0)
    key = struct.unpack("<I", data[:4])[0]
    result = dec(key, data)
    return result

Конфигурация, зашитая в тело трояна

Зашитая в тело трояна конфигурация расшифровывается в том случае, если аргумент, полученный от загрузчика, не имеет значения сигнатуры PLUG.

Структура конфигурации:

struct timeout
{
  BYTE days;
  BYTE hours;
  BYTE minutes;
  BYTE seconds;
};
struct srv
{
  WCHAR type;
  WCHAR port;
  BYTE address[64];
};
struct proxy_info
{
  WCHAR type;
  WCHAR port;
  BYTE address[64];
  BYTE username[64];
  BYTE password[64];
};
struct st_config
{
  DWORD dword_0;
  DWORD key;
  DWORD dword_1;
  DWORD flag_hide_service;
  BYTE gap_0[24];
  DWORD flag_delete_proc_bins;
  DWORD dword_2;
  DWORD flag_dont_start_service;
  timeout timeout;
  DWORD dword_3;
  BYTE timetable[672];
  DWORD DNS_1;
  DWORD DNS_2;
  DWORD DNS_3;
  DWORD DNS_4;
  srv srv_1;
  srv srv_2;
  srv srv_3;
  srv srv_4;
  BYTE url_1[128];
  BYTE url_2[128];
  BYTE url_3[128];
  BYTE url_4[128];
  proxy_info proxy_1;
  proxy_info proxy_2;
  proxy_info proxy_3;
  proxy_info proxy_4;
  DWORD HTTP_method;
  DWORD inject_flag;
  DWORD persist_mode;
  DWORD flag_broadcasting;
  DWORD flag_elevated_inject;
  WCHAR inject_target_proc[256];
  WCHAR homedir[256];
  WCHAR persist_name[256];
  WCHAR service_display_name[256];
  WCHAR str_1[256];
  WCHAR str_2[256];
  WCHAR campaign_id[256];
}config;

После инициализации конфигурации троян проверяет аргументы командой строки. Если аргумент один, то программа использует стандартный сценарий закрепления и выполнения основных функций; если командная строка содержит три аргумента, то программа выполняет одну из функций в зависимости от их значений.

Выполнение с одним аргументом командной строки

Вариант закрепления зависит от значения config.persist_mode:

0 — не закрепляется, сразу переходит к основной функциональности;
1 — автозагрузка с помощью HKCU\Software\Microsoft\Windows\CurrentVersion\Run;
2 — создает задачи в планировщике;
3 — устанавливает службы (при отсутствии административных привилегий эквивалентен режиму 1).

В случае выполнения без закрепления проверяет флаг config.inject_flag. Если значение не равно 0, то проверяется аргумент, переданный от загрузчика. Если аргумент содержит сигнатуру PLUG, то запускается процесс, указанный в config.inject_target_proc. В этот процесс внедряется шелл-код из структуры shellarg, после чего основной процесс завершается.

В случае выполнения с закреплением троян проверяет текущую рабочую директорию. Если она совпадает с домашней директорией config.homedir, то этап закрепления пропускается и выполняется либо внедрение в процесс, либо основная функциональность. В ином случае создается 2 мьютекса с именами Global\DelSelf(XXXXXXXX) и Global\DelSelf(YYYYYYYY), где XXXXXXXX и YYYYYYYY — идентификаторы текущего и родительского процессов в HEX-представлении соответственно. Во всех режимах закрепления троян переносит свои файлы в домашнюю директорию.

В функции закрепления предусмотрен вариант, когда параметр config.persist_mode может принимать значение 0. Это необходимо на случай, если процесс запущен с 3 аргументами, и второй аргумент равен 100. При таких условиях после переноса своих файлов BackDoor.PlugX.38 перезапускается уже из домашней директории.

При варианте закрепления со значением config.persist_mode == 1 в ключе автозапуска создается параметр с именем, указанным в конфигурации config.persist_name, после чего троян запускает себя из домашней директории.

При варианте закрепления со значением config.persist_mode == 2 в планировщике создается задача через вызов schtasks:

При наличии административных привилегий троян добавляет параметр /ru "system". После создания задачи завершает процесс.

При варианте закрепления со значением config.persist_mode == 3 устанавливается служба. Проверяет наличие службы с именем config.persist_name и, если она есть и остановлена, удаляет ее. Если служба запущена, то создание службы пропускается. В противном случае создает службу config.persist_name с отображаемым именем config.service_display_name. Если значение config.flag_dont_start_service не равно 0, то служба не запускается. После создания службы процесс завершается.

При выполнении основной функциональности создается мьютекс с именем Global\ReStart0. Затем по наличию мьютекса с именем Global\DelSelf(YYYYYYYY) выполняется поиск родительского процесса, после чего он завершается, а исполняемый файл процесса — удаляется (при условии, что установлен флаг config.flag_delete_proc_bins). Далее троян проверяет значение флага config.flag_elevated_inject. Если значение не равно 0, то запускается именованный поток SiProc.

В данном потоке также проверяется аргумент, переданный загрузчиком. Дальнейшее выполнение потока SiProc продолжается только в случае наличия сигнатуры PLUG. Поток перебирает процессы и пытается по значению PID каждого процесса получить идентификатор сессии. В случае успеха копирует маркер доступа процесса и присваивает дубликату HighIntegrity класс (S-1-16-12288). Затем с использованием этого маркера создает процесс msiexec.exe 209 <currentPID>, в который внедряет шелл-код с полезной нагрузкой. Потоку в качестве аргумента передается указатель на структуру elevated_injects:

struct injected_proc
{
  DWORD session_id;
  DWORD pid;
  DWORD hProcess;
  BYTE token_user_name[40];
};
struct elevated_injects
{
  injected_proc procs[32];
  DWORD hThread;
  DWORD hEvent;
};

При каждом успешном внедрении шелл-кода заполняется массив elevated_injects.procs.

После этого происходит инициализация объекта-контейнера плагинов и самих плагинов. Инициализируется массив вспомогательных функций, используемых плагинами. Доступ к этим функциям осуществляется через именованное отображение объекта PI[%8.8X], где параметром формата является идентификатор текущего процесса.

Затем происходит поочередная инициализация каждого плагина, в результате чего создается индивидуальный объект plugin_object:

struct plugin_object
{
  DWORD dword_1;
  DWORD init_flag;
  DWORD index;
  DWORD datestamp;
  DWORD (__stdcall *p_job_func)(LPVOID p_conn_object, packet *p_packet);
  BYTE name[32];
};

Имена плагинов соответствуют таковым у BackDoor.PlugX.28, за исключением отсутствия второго плагина DISK. Значения, помещаемые в plugin_object.datestamp, отличаются для каждого плагина:

По аналогии с BackDoor.PlugX.28 инициализация плагинов KeyLog и Screen отличается от остальных. При инициализации KeyLog создается именованный поток KLProc, в котором через функции RegisterRawInputDevices и GetRawInputData выполняется перехват событий клавиатуры. Журнал содержится в файле <config.homedir>\NvSmart.hlp. При инициализации плагина Screen дополнительно к созданию объекта в цикле загружаются 16 курсоров.

После инициализации всех плагинов запускается именованный поток PlugProc. Поток пытается поочередно прочесть из домашней директории файлы с расширением .plg, имена которых могут принимать значения от 0 до 127. Из каждого такого файла может быть считан сжатый и зашифрованный PE-модуль. Если аргумент от загрузчика содержит сигнатуру PLUG, то после чтения файла инициализируется очередной именованный поток LdrLoadShellcode, который расшифровывает и распаковывает модуль, а затем загружает его, передавая ему в качестве аргумента структуру shellarg с сигнатурой PLUG. Следует отметить, что процедура LdrLoadShellcode используется при внедрении в процессы из конфигурации и процесс msiexec, но она непосредственно пишется в целевой процесс.

После работы с плагинами запускается поток OlProc, в котором выполняется взаимодействие с управляющим сервером. Кроме того, из OlProc запускается еще несколько потоков. Троян предварительно пытается извлечь параметр CLSID из ключа реестра Software\CLASSES\MPLS\. По умолчанию из раздела HKLM, а в случае неудачи — из раздела HKCU. Если указанный параметр отсутствует, то создает его, генерирует случайное значение из 8 байтов, форматирует его как %2.2X%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X и заносит в созданный параметр. Внутри OlProc по аналогии с BackDoor.PlugX.28 выполняется попытка спрятать службу в процессе services.exe (при условии, что установлен флаг config.flag_hide_service). Затем запускается поток OlProcNotify, в котором вновь происходит инициализация конфигурации.

После этого запускается цикл подключений к серверу. Предусмотрена возможность загрузки адреса нового управляющего сервера, если уже были выполнены попытки подключения к 4 серверам. Для этого используются URL вида config.url_<n>. По заданному URL выполняется HTTP-запрос, в ответ на который приходит закодированный адрес сервера, расположенный между строками DZKS и DZJS. Серверы могут разрешаться с помощью запросов к DNS-серверам, прописанных в конфигурационном файле.

Первая попытка подключения выполняется без прокси. Перед этим выполняется проверка значения параметра config.timetable, который отвечает за расписание подключений (байтовый флаг установлен на каждую четверть часа). Затем проверяется тип сервера, к которому выполняется подключение. Структура srv аналогична таковой у BackDoor.PlugX.28:

struct srv
{
  WORD type;
  WORD port;
  BYTE address[64];
};

При этом у BackDoor.PlugX.38 поле type, определяющее протокол подключения, представляет собой битовое поле:

В проанализированном образце протокол ICMP не поддерживается, но значение предусмотрено (установлена заглушка при создании объекта подключения). При использовании протокола HTTPS соединение представляет собой подключение к HTTP-прокси-серверу через сокет.

При создании объекта подключения формируется строка подключения, которая не используется в проанализированном образце:

Protocol:[%4s], Host: [%s:%d], Proxy: [%d:%s:%d:%s:%s]

Для общения с сервером используется структура пакета, аналогичная BackDoor.PlugX.28:

struct packet_hdr
{
  DWORD key;
  DWORD command_id;
  DWORD len;
  DWORD errc;
};
struct packet
{
  packet_hdr header;
  BYTE data[61440] //0xF000;
};

При первичном обращении, аналогично BackDoor.PlugX.28, генерируется от 0 до 0x1F случайных байт, которые отправляются серверу. В ответ на запрос приходит пакет с командой.

При использовании HTTP-подключения присутствуют отличия от BackDoor.PlugX.28 в механизме формирования запроса.

Создается именованный поток SxWorkProc. Сначала по частям формируется User-Agent:

1) зашитая строка Mozilla/4.0 (compatible; MSIE;

2) значение параметра HKLM\SOFTWARE\Microsoft\Internet Explorer\Version Vector\IE или зашитое 8.0;

3) Windows NT X.Y, где X.Y — версия Windows;

4) значения параметров из ключей HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform, а также аналогичные значения из раздела HKCU, объединенные через ;

5) закрывающая скобка ).

Указанные части объединяются в одну строку, которая служит в качестве User-Agent.

Строка ресурса формируется как /index?id=%7.P, где параметром является адрес локальной переменной. Метод выбирается в зависимости от значения config.HTTP_method:

• 0 — GET;
• 1 — POST;
• 2 — случайный выбор между GET и POST.

Затем добавляются M-заголовки, которые необходимы для работы и синхронизации HTTP-соединения (аналогично структуре prefix в BackDoor.PlugX.28).

• M-Session:
• M-Status:
• M-Size:
• M-Sn:

Данные передаются в теле запроса. Пакеты шифруются тем же алгоритмом, что и конфигурация. При подготовке пакета к шифрованию в поле packet.header.key помещается значение 20161127h, однако в дальнейшем оно заменяется на случайный ключ. При шифровании и компрессии как передаваемых, так и принимаемых данных могут быть следующие варианты:

• если в packet_hdr.command_id установлен бит 0x10000000, то пакет не сжимается (например, завершающий пакет после отправки файла);
• если в том же поле установлен бит 0x20000000, то пакет не шифруется.

В поле заголовка len указывается длина сжатых и несжатых данных (2 младших байта — длина сжатых, 2 старших — длина несжатых).

При использовании TCP-соединения данные передаются без каких-либо заголовков.

Общие команды практически соответствуют таковым у BackDoor.PlugX.28:

Работа с плагинами (команда 3) выполняется в отдельном потоке OlProcManager и построена так же, как и в BackDoor.PlugX.28.

При получении новой конфигурации она сохраняется в файл <config.homedir>\boot.cfg и сразу применяется. После этого троян получает данные о прокси-серверах из всех доступных источников:

• из ключа реестра HKLM\Software\CLASSES\MPLS\PROXY извлекаются все параметры, которые представляют собой параметры прокси-серверов, разделенные знаком : — <тип:порт:адрес:идентификатор:пароль>;
• системные данные прокси из ключа реестра HKU\Software\Microsoft\Windows\CurrentVersion\Internet Settings;
• из параметра AutoConfigURL извлекается адрес, который используется для вызова функции UrlDownloadToFileA, и затем с использованием WinAPI InternetGetProxyInfo из jsproxy.dll совершается запрос к appengine[.]google.com, по результатам которого троян получает данные прокси-сервера;
• данные прокси извлекаются из конфигурационного файла Mozilla: .default\prefs.js.

Все полученные данные сохраняются во внутреннем объекте и используются для подключения. Предусмотрена возможность подключения по протоколам SOCKS4, SOCKS5 и HTTP-прокси.

После OlProcNotify, в том же OlProc инициализируется новый поток JoProc, который, в свою очередь, последовательно инициализирует 3 потока:

JoProcListen
JoProcBroadcast
JoProcBroadcastRecv

JoProcListen запускает поток JoProcAccept, который создает объект UDP-соединения, а также подключается к управляющему серверу. Подразумевается, что в этом потоке должна быть асинхронная пересылка между UDP-соединением и подключением к управляющему серверу, однако создаваемый объект UDP-соединения по своей сути является нерабочим. При создании он не выполняет подключения к какому-либо хосту, а условные методы, которые должны передавать и принимать данные, являются заглушками, возвращающими значение 0.

То же самое справедливо и для функций JoProcBroadсast и JoProcBroadcastRecv. JoProcBroadсast перебирает доступные сетевые адаптеры, получает их IP-адреса, маски подсетей и адреса шлюзов, затем создает реальный объект TCP-соединения и завершает свою работу. JoProcBroadcastRecv также не имеет какой-либо функциональности.

Необходимо отметить, что вышеупомянутые операции выполняются только при условии установки флага config.broadcasting. Команды 9, 10 управляющего сервера также предназначены для работы со сканированием сети, при этом полезная функциональность также отсутствует. При получении команды 10 проверяется флаг config.broadcasting, после чего выполнение команды завершается.

Выполнение с 3 аргументами командой строки

При запуске с аргументом 209 учитывается также argv[2] — идентификатор родительского процесса основного трояна, запустившего msiexec.exe с внедрением. В этом случае создается пайп с именем \\.\PIPE\RUN_AS_USER(%d), где параметром формата является PID текущего процесса. Далее инициализируется поток DoImpUserProc, в котором выполняется работа с плагинами. Команды для плагинов троян получает из пайпа, а результаты отправляются в пайп основному процессу.

Работа с плагинами

Выполнение задач плагинов в целом идентично BackDoor.PlugX.28 за исключением:

• в плагине Netstat, который создает таблицу TCP- и UDP-соединений, а также управляет TCP-соединением, теперь учитываются версии ОС с MajorVersion == 10;
• в плагине Nethood присутствует только команда A000h, которая собирает информацию о ресурсах сети. В этой модификации бэкдора отсутствует команда A001h, которая позволяла отключить заданный сетевой ресурс.

Порядок запуска именованных потоков

bootProc является главной функцией, и из нее запускаются остальные потоки:

• SiProc (внедрение в процесс в msiexec.exe)
• OlProc
• OlProcNotify (подключение к управляющему серверу, работа с командами)
• OlProcManager (обработка задач для плагинов в контексте текущего процесса)
• JoProc (сканирование сети)
• JoProcListen (создание туннеля между условным UDP-соединением и управляющим сервером)
• JoProcBroadcast (рассылка по сети)
• JoProcBroadcastRecv (обработка ответов на рассылку)
• PlugProc (работа с плагинами при внедрении)
• LdrLoadShellcode
• KLProc (поток кейлоггера)
• SxWorkProc (обработчик соединения по протоколу HTTP)
• DoImpUserProc (работа с плагинами через пайп)

Потоки плагинов могут запускаться из OlProcManager и DoImpUserProc, в зависимости от конфигурации:

• RtlMessageBoxProc (запускается во время работы с плагином Option, служит для отображения MessageBox с заданными параметрами);
• ScreenT1, ScreenT2 (плагин Screen, потоки для эмуляции RDP);
• ShellT1, ShellT2 (плагин Shell, потоки для чтения и записи пайпа cmd);
• TelnetT1, TelnetT1 (плагин Telnet, потоки для получения и отправки данных консоли).