BackDoor.Skeye.1

• Упаковщик: отсутствует
• Дата компиляции: 01.04.2019 15:00:46
• SHA1-хеш: a259db436aa8883cc99af1d59f05f4b1d97c178b

Описание

Бэкдор, написанный на C и работающий в среде 32- и 64-битных операционных систем семейства Microsoft Windows. Используется для целевых атак на информационные системы, удаленного управления компьютером путем перенаправления ввода-вывода командной оболочки на управляющий сервер, сбора информации о зараженном устройстве. Оригинальное имя вредоносного модуля — sk.exe. В коде бэкдора прослеживается связь с образцами семейств Mikroceen и Logtu.

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

Имеет одну экспортируемую функцию: DllEntry, следующего вида:

При запуске образца как EXE-файла запускается только функция malmain.

Бэкдор записывает журнал событий в файл %TEMP%\\wcrypt32.dll с указанием даты и времени сообщения, но вместо читаемого сообщения логируется его код. Ниже в таблице представлена расшифровка кодов сообщений.

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

После этого следует первая проверка на наличие отладочного процесса — бэкдор проверяет BeingDebugged флаг в PEB (Process Environment Block). Если идет отладка, бэкдор завершается.

Далее создает мьютекс test0 или test0_cu в том случае, если запущен не от NT AUTHORITY/SYSTEM. Если указанный мьютекс уже существует, то завершает свою работу.

Читает идентификатор бота из файла %TEMP%\\test0.dat. На основе идентификатора бота инициализируется 8-байтовый ключ шифрования.

Далее BackDoor.Skeye.1 входит в цикл работы с управляющим сервером. Перед отправкой запросов в очередной раз проверяет наличие процесса отладки образца. На этот раз с помощью функции NtQueryInformationProcess проверяет ProcessDebugPort, ProcessDebugObjectHandle и ProcessDebugFlags. Если отладчик обнаружен, то завершает свою работу.

В запросах используется строка User-Agent:

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2)

При обращении к управляющему серверу сначала отправляется GET-запрос на проверку доступности последнего; в образце зашиты два набора (сервер-порт) адресов управляющих серверов. hxxps://atob.kommesantor.com/?t=%d&&s=%d&&p=%s&&k=%d, где параметр t — идентификатор бота, s — номер сессии, p — строка dut6@bV0, k — результат функции GetTickCount().

Если в ответ пришел код 200, это означает, что соединение с сервером успешно установлено, и бэкдор запрашивает команду для выполнения. Если в ответ пришел код 403, программа пытается повторить запрос, при этом в HTTP-заголовок Host вместо адреса управляющего сервера вписывает www.mail[.]ru. Если и в этом случае получить код 200 не удается, пробует второй зашитый управляющий сервер. В случае повторной неудачи ожидает несколько секунд, после чего предпринимает очередную попытку.

Для запроса команды используется GET-запрос с адресом hxxps://atob.kommesantor.com/?e=%d&&t=%d&&k=%d, где e — ноль, t — идентификатор бота, k — результат функции GetTickCount().

Если в ответ пришел код 200, то в cookie ответа содержится идентификатор команды, которую необходимо выполнить, а данные ответа зашифрованы операцией XOR с 8-байтовым ключом, основанным на идентификаторе бота.

Для отправки результата выполнения команды используется POST-запрос с адресом hxxps://atob.kommesantor.com/?e=%d&&t=%d&&k=%d, где e — идентификатор выполненной команды, t — идентификатор бота, k — результат функции GetTickCount(); результат выполнения запроса передается данными, зашифрованными операцией XOR с 8-байтовым ключом, основанным на идентификаторе бота.

Список команд:

В процессе расследования целевой атаки с применением данного бэкдора были найдены следующие серверы:

atob[.]kommesantor[.]com
term[.]internnetionfax[.]com
    
rps[.]news-click[.]net

Все три домена разрешаются в 103.97.124[.]193

Другие модификации бэкдора Skeye

Другой обнаруженный образец бэкдора (0b33a10c0b286c6ffa1d45b261d8a338) детектируется Dr.Web как BackDoor.Skeye.2.

Ключевые отличия данной модификации представлены следующим списком:

• экспортируемые функции отсутствуют;
• образец работает как служба, устанавливает или удаляет себя, в зависимости от аргументов, с которыми запущен (install, uninstall, без аргументов).

Функция malmain запускается также и из ServiceMain;

• идентификатор бота читает из файла %TEMP%\Date, но ключ шифрования формирует аналогичным образом;
• конфигурация (имя мьютекса, адрес сервера, порт, прокси) зашифрована операцией XOR с ключом 0xB7. Адрес управляющего сервера — www2.morgoclass[.]com, порт 443;

  

• протокол взаимодействия с управляющим сервером бинарный. Подключение происходит через TCP-сокет. После подключения к серверу бэкдор отправляет 8-байтовый пакет: первые 4 байта — идентификатор бота, вторые 4 байта — нули. Получение ответа от сервера выполняется в 2 этапа: сперва происходит получение пакета с длиной данных (заголовка), затем — прием и расшифровка самих данных. Структура заголовка выглядит следующим образом:

  struct packet_header
        {
            BYTE marker;
            DWORD cmd_id;
            DWORD size;
        }
        

При этом поле marker должно быть равно 0xFF. Отправка данных на сервер выполняется одним вызовом send с аналогичным заголовком;

• в этом образце представлены не все команды, описанные в первом образце (a259db436aa8883cc99af1d59f05f4b1d97c178b). Отсутствуют команды 80, 81, 85, 86;
• присутствуют отличия в кодах сообщений журнала событий. Отсутствуют коды 10, 65-68, 70-72.

Коды сообщений журнала событий представлены в таблице.

Примечательно, что в двух образцах используются разные наборы кодов для логирования соединения с управляющим сервером. В первом это коды 70-72, при том, что подключение к серверу выполняется через HTTP; во втором это коды 24-26, подключение выполняется через сокет.