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

BackDoor.Mikroceen.11		BackDoor.Logtu.1
SHA1	Id	SHA1	id
ce21f798119dbcb7a63f8cdf070545abb09f25ba	intl0113	029735cb604ddcb9ce85de92a6096d366bd38a24	intpz0220
0eb2136c5ff7a92706bc9207da32dd85691eeed5	hisa5.si4	7b652e352a6d2a511f226e4d0cc22f093e052ad8	retail2007
2f80f51188dc9aea697868864d88925d64c26abc	josa5w5n	1c5e5fd53fc2ee778342a5cae3ac2eb0ac345ed7	retail
2e50c075343ab20228a8c0c094722bbff71c4a2a	enc0225	00ddcc200d1031b8639026532c0087bfcc4520c9	716demo
3bd16f11b5b3965a124a6fc3286297e5cfe77715	520299	b599797746ae8ccf7907cf88de232faa30ec95e6	gas-zhi
5eecdf63e85833e712a1ff88df1341bbf32f4ab8	Strive	2d672d7818a56029b337e8792935195d53576a9d	jjlk
bd308f4d1a32096a3b90cfdae45bbc5c13e5e801	R0916
b1be4b2f874c8309f553acce90287c8c6bb2b6b1	frsl.1ply
21ffd24b8074d7cffdf4cc339d1fa8fe892eba27	Wdv
8fbec09e646311a285aee06b3dd45ccf58928703	intz726
19921cc47b3de003186e65fd12b82235030f060d	122764
0f70251abc8c64cbc7b24995c3d32927514d0a4b	V20180224
149947544ca4f7baa5bc3d00b080d0e943d8036b	SOE
e7f5a33b33e023a82ac9eee6ed40e4a38ce95277	int815
b4790eec7daa9f931bed43a53f66168b477599a7	UOE
ab660a3ac46d563c756463bd1b64cc45f347a1f7	B.Z11NOV20D
d0181759a175fbcc60975983b351f88970f484f9	299520
7a63fc9db2bc1e9b1ef793723d5877e6b4c566b8	WinVideo
13779006d0dafbe4b27bd282230df299eef2b8dc	SSLSSL
f53c77695a162c78c68f693f57f65752d17f6030	int007server
924341cab6106ef993b506193e6786e459936069	intl1211
8ebf78c84cd7f66ca8708467a28d83658bcf6710	intl821
f2856d7d138430e164f83662e251ee311950d83c	intl821

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

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

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

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

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

Заключение

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

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

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

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

http://feedproxy.google.com/~r/drweb/viruses/~3/IYUfcdnNHag/