Скачать в PDF

2 апреля 2021 года

Введение

В конце сентября 2020 года в вирусную лабораторию «Доктор Веб» за помощью обратился один из российских научно-исследовательских институтов. Сотрудники НИИ обратили внимание на ряд технических проблем, которые могли свидетельствовать о наличии вредоносного ПО на одном из серверов локальной сети. В ходе расследования вирусные аналитики установили, что на НИИ была осуществлена целевая атака с использованием специализированных бэкдоров. Изучение деталей инцидента показало, что сеть предприятия была скомпрометирована задолго до обращения к нам и, судя по имеющимся у нас данным, — не одной APT-группой.

Полученные в ходе расследования данные говорят о том, что первая APT-группа скомпрометировала внутреннюю сеть института осенью 2017 года. Первичное заражение осуществлялось с помощью BackDoor.Farfli.130 — модификации бэкдора, также известного как Gh0st RAT. Позднее, весной 2019 года в сети был установлен Trojan.Mirage.12, а в июне 2020 — BackDoor.Siggen2.3268.

Вторая хакерская группировка скомпрометировала сеть института не позднее апреля 2019, в этот раз заражение началось с установки бэкдора BackDoor.Skeye.1. В процессе работы мы также выяснили, что примерно в то же время — в мае 2019 года — Skeye был установлен в локальной сети другого российского НИИ.

Тем временем в июне 2019 года компания FireEye опубликовала отчет о целевой атаке на государственный сектор ряда стран центральной Азии с использованием этого бэкдора. Позднее, в период с августа по сентябрь 2020 года вирусные аналитики «Доктор Веб» зафиксировали установку различных троянов этой группой в сети предприятия, включая ранее не встречавшийся DNS-бэкдор BackDoor.DNSep.1, а также хорошо известный BackDoor.PlugX.

Более того, в декабре 2017 года на серверы обратившегося к нам НИИ был установлен BackDoor.RemShell.24. Представители этого семейства ранее были описаны специалистами Positive Technologies в исследовании Operation Taskmasters. При этом мы не располагаем такими данными, которые позволили бы однозначно определить, какая из двух APT-групп использовала этот бэкдор.

Кто стоит за атаками?

Деятельность первой APT-группы не позволяет нам однозначно идентифицировать атаковавших как одну из ранее описанных хакерских группировок. При этом анализ используемых вредоносных программ и инфраструктуры показал, что эта группа активна как минимум с 2015 года.

Второй APT-группой, атаковавшей НИИ, по нашему мнению является TA428, ранее описанная исследователями компании Proofpoint в материале Operation Lag Time IT. В пользу этого вывода говорят следующие факты:

1. в коде бэкдоров BackDoor.DNSep и BackDoor.Cotx имеются явные пересечения и заимствования;
2. BackDoor.Skeye.1 и Trojan.Loader.661 использовались в рамках одной атаки, при этом последний является известным инструментом TA428;
3. бэкдоры, проанализированные нами в рамках этих атак, имеют пересечения в адресах управляющих серверов и сетевой инфраструктуре с бэкдорами, используемыми группировкой TA428.

Теперь подробнее рассмотрим выявленные связи. На графе приведена часть задействованной в атаке инфраструктуры с пересечениями бэкдоров Skeye и другим известным APT-бэкдором — PoisonIvy:

На этом графе изображены пересечения в инфраструктуре бэкдоров Skeye и Cotx:

Детальный анализ бэкдора DNSep и его последующее сравнение с кодом бэкдора Cotx выявили сходство как в общей логике обработки команд от управляющего сервера, так и в конкретных реализациях отдельных команд.

Другой интересной находкой этого исследования стал бэкдор Logtu, один из его образцов мы ранее описывали в рамках расследования инцидента в Киргизии. Адрес его управляющего сервера совпал с адресом сервера бэкдора Skeye — atob[.]kommesantor[.]com. В связи с этим мы также провели сравнительный анализ BackDoor.Skeye.1 с образцами BackDoor.Logtu.1 и BackDoor.Mikroceen.11.

Подробные технические описания обнаруженных вредоносных программ находятся в PDF-версии исследования и в вирусной библиотеке Dr.Web.

Сравнительный анализ кода BackDoor.DNSep.1 и BackDoor.Cotx.1

Несмотря на то, что каналы связи с управляющим сервером у Cotx и DNSep кардинально различаются, нам удалось найти интересные совпадения в коде обоих бэкдоров.

Функция, отвечающая за обработку команд от управляющего сервера, принимает аргументом структуру:

struct st_arg
{
  _BYTE cmd;
  st_string arg;
};

При этом, если нужная функция принимает несколько аргументов, то они все записаны в поле arg с разделителем |.

Набор команд BackDoor.Cotx.1 обширнее, чем у BackDoor.DNSep.1, и включает все команды, которые есть у последнего.

В таблице ниже видно почти полное совпадение кода некоторых функций бэкдоров. При этом следует учитывать, в Cotx используется кодировка Unicode, а в DNSep — ANSI.

BackDoor.DNSep.1	BackDoor.Cotx.1
Обработчик команды на отправку листинга каталога или информации о диске
Функция получения информации о дисках
Функция перечисления файлов в папке
Функция сбора информации о файлах в папке

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

Сравнительный анализ кода бэкдоров Skeye, Mikroceen, Logtu

В процессе исследования бэкдора Skeye мы обнаружили, что адрес его управляющего сервера также используется бэкдором семейства Logtu. Для сравнительного анализа мы использовали ранее описанные нами образцы BackDoor.Logtu.1 и BackDoor.Mikroceen.11.

Функции логирования

Логирование во всех случаях так или иначе обфусцировано.

• BackDoor.Mikroceen.11 — сообщения в формате %d-%d-%d %d:%d:%d <msg>\r\n записываются в файл %TEMP%\WZ9Jan10.TMP, где <msg> — случайная текстовая строка. В образце 2f80f51188dc9aea697868864d88925d64c26abc сообщения записываются в файл 7B296FB0.CAB;
• BackDoor.Logtu.1 — сообщения в формате [%d-%02d-%02d %02d:%02d:%02d] <rec_id> <error_code>\n<opt_message>\n\n перед записью в файл %TEMP%\rar<rnd>.tmp шифруются операцией XOR с ключом 0x31;
• BackDoor.Skeye.1 — сообщения в формате %4d/%02d/%02d %02d:%02d:%02d\t<rec_id>\t<error_code>\n записываются в файл %TEMP%\wcrypt32.dll.

Общая логика последовательности записи сообщений в журнал также схожа у всех трех образцов:

• начало исполнения фиксируется;
• в Logtu и Mikroceen в журнал записывается прямое подключение к управляющему серверу;
• в каждом случае указывается, через какой прокси выполнено подключение к серверу;
• в случае ошибки на этапе получения прокси из того или иного источника в журнале фиксируется отдельная запись.

Следует заметить, что настолько подробное и при этом обфусцированное логирование встречается крайне редко. Обфускация заключается в том, что в журнал записываются некоторые коды сообщений и в ряде случаев дополнительные данные. Кроме того, в данном случае прослеживается общая схема последовательности записи событий:

• начало исполнения;
• попытка подключения напрямую;
• получение адресов прокси;
• запись о подключении через тот или иной сервер.

Поиск прокси-сервера

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

Получение адресов прокси-серверов BackDoor.Mikroceen.11:

• из файла %WINDIR%\debug\netlogon.cfg;
• из собственного лог-файла;
• путем поиска соединений с удаленными хостами через порты 80, 8080, 3128, 9080 в TCP-таблице.

Поиск прокси в своем лог-файле:

Поиск в активных соединениях:

Получение адресов прокси-серверов BackDoor.Logtu.1:

• из реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;
• из раздела HKU реестра по SID активного пользователя;
• с помощью WinHTTP API WinHttpGetProxyForUrl путем запроса к google.com.

Получение адресов прокси-серверов BackDoor.Skeye.1:

• из раздела HKCU Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;
• из раздела HKU по SID активного пользователя;
• путем поиска соединений с удаленными хостами через порты 80, 8080, 3128, 9080 в TCP-таблице.

Пересечения в сетевой инфраструктуре

Некоторые образцы совместно использовали одну и ту же сетевую инфраструктуру. Фрагмент графа наглядно показывает взаимосвязь между семействами.

Идентификаторы

В образцах Logtu и Mikroceen присутствуют строки, которые используются в качестве идентификаторов сборок или версий. Формат некоторых из них совпадает.

Кроме того, в значительном числе образцов данный идентификатор равен значению TEST или test.

Пример в BackDoor.Logtu.1 (9ea2488f07bf3edda23d9b7759c2d0c3c8501f92):

Пример в BackDoor.Mirkoceen.11 (81bb895a833594013bc74b429fb1f24f9ec9df26):

Таким образом, сравнительный анализ выявил у рассмотренных семейств сходства в:

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

Заключение

В ходе расследования атак на российские НИИ наши вирусные аналитики нашли и описали несколько семейств целевых бэкдоров, включая ранее неизвестные образцы. Следует отдельно отметить длительное скрытое функционирование вредоносных программ в скомпрометированной сети пострадавшей организации — несанкционированное присутствие первой APT-группы оставалось незамеченным с 2017 года.

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

Специалисты компании «Доктор Веб» рекомендуют производить регулярный контроль работоспособности важных сетевых ресурсов и своевременно обращать внимание на сбои, которые могут свидетельствовать о наличии в сети вредоносного ПО. Основная опасность целевых атак заключается не только в компрометации данных, но и в длительном присутствии злоумышленников в корпоративной сети. Такой сценарий позволяет годами контролировать работу организации и в нужный момент получать доступ к чувствительной информации. При подозрении на вредоносную активность в сети мы рекомендуем обращаться в вирусную лабораторию «Доктор Веб», которая оказывает услуги по расследованию вирусозависимых компьютерных инцидентов. Оперативное принятие адекватных мер позволит сократить ущерб и предотвратить тяжелые последствия целевых атак.

Индикаторы компрометации