В конце сентября 2020 года в вирусную лабораторию Доктор Веб за помощью обратился один из российских научно-исследовательских институтов. Сотрудники НИИ обратили внимание на ряд технических проблем, которые могли свидетельствовать о наличии вредоносного ПО на одном из серверов локальной сети. В ходе расследования мы установили, что на НИИ была осуществлена целевая атака с использованием ряда специализированных бэкдоров. Изучение деталей инцидента показало, что сеть института была скомпрометирована задолго до обращения к нам и, судя по имеющимся у нас данным, не одной APT-группой.
В этой статье мы восстановим хронологию заражения сети, идентифицируем обнаруженные бэкдоры и обратим внимание на выявленные пересечения в их коде и сетевой инфраструктуре. Также мы попробуем ответить на вопрос: кто стоит за атаками?
Восстанавливаем события
Мы считаем, что найденные в сети бэкдоры принадлежат двум разным хакерским группировкам. Для удобства обозначим их как APT-группа 1 и APT-группа 2.
В ходе расследования было установлено, что APT-группа 1 скомпрометировала внутреннюю сеть института осенью 2017 года. Первичное заражение осуществлялось с помощьюBackDoor.Farfli.130 модификации бэкдора, также известного как Gh0st RAT. Позднее, весной 2019 года в сети был установлен Trojan.Mirage.12, а в июне 2020 BackDoor.Siggen2.3268.
APT-группа 2 скомпрометировала сеть института не позднее апреля 2019, и в этот раз заражение началось с установки бэкдораBackDoor.Skeye.1. В процессе работы мы также выяснили, что примерно в то же время в мае 2019 года Skeye был установлен в локальной сети другого российского НИИ.
Тем временем в июне 2019 года компания FireEye опубликовала отчет о целевой атаке на государственный сектор ряда стран центральной Азии с использованием Skeye. Позднее, в период с августа по сентябрь 2020 года вирусные аналитики Доктор Веб зафиксировали установку различных троянов APT-группой 2 в сети пострадавшего НИИ, включая ранее не встречавшийся 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-бэкдором PosionIvy:
связей много, поэтому пожалуйста, масштабируйте, спасибо :)На этом графе изображены пересечения в инфраструктуре бэкдоров Skeye и Cotx:
Детальный анализ бэкдора DNSep и его последующее сравнение с кодом бэкдора Cotx выявили сходство как в общей логике обработки команд от управляющего сервера, так и в конкретных реализациях отдельных команд. Мы рассмотрим их ниже.
Другой интересной находкой этого исследования стал бэкдор Logtu, один из его образцов мы ранее описывали в рамках расследования инцидента в Киргизии. Адрес его управляющего сервера совпал с адресом сервера бэкдора Skeye atob[.]kommesantor[.]com. В связи с этим мы также провели сравнительный анализ BackDoor.Skeye.1 с образцами BackDoor.Logtu.1 и BackDoor.Mikroceen.11.
Подробный разбор алгоритмов работы найденных бэкдоров читайте в нашем исследовании на сайте.
Сравнительный анализ кода DNSep и Cotx
Несмотря на то, что каналы связи с управляющим сервером у Cotx и DNSep кардинально различаются, нам удалось найти интересные совпадения в коде обоих бэкдоров.
Функция, отвечающая за обработку команд от управляющего сервера, принимает аргументом структуру:
structst_arg{_BYTE cmd;st_string arg;};
При этом, если нужная функция принимает несколько аргументов, то они все записаны в поле arg с разделителем |.
Набор команд BackDoor.Cotx.1 обширнее, чем у BackDoor.DNSep.1, и включает все команды, которые есть у последнего.
Ниже видно почти полное совпадение кода некоторых функций бэкдоров. При этом следует учитывать, в Cotx используется кодировка Unicode, а в DNSep ANSI.
Обработчик команды на отправку листинга каталога или информации о диске
BackDoor.DNSep.1BackDoor.Cotx.1Функция получения информации о дисках
BackDoor.DNSep.1BackDoor.Cotx.1Функция перечисления файлов в папке
BackDoor.DNSep.1BackDoor.Cotx.1Функция сбора информации о файлах в папке
BackDoor.DNSep.1BackDoor.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 присутствуют строки, которые используются в качестве идентификаторов сборок или версий. Формат некоторых из них совпадает.
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 года.
Характерной особенностью является наличие пересечений в коде и сетевой инфраструктуре проанализированных образцов. Мы допускаем, что выявленные связи указывают на принадлежность рассмотренных бэкдоров к одним и тем же хакерским группировкам.
Специалисты компании Доктор Веб рекомендуют производить регулярный контроль работоспособности важных сетевых ресурсов и своевременно обращать внимание на сбои, которые могут свидетельствовать о наличии в сети вредоносного ПО. Основная опасность целевых атак заключается не только в компрометации данных, но и в длительном присутствии злоумышленников в корпоративной сети. Такой сценарий позволяет годами контролировать работу организации и в нужный момент получать доступ к чувствительной информации. При подозрении на вредоносную активность в сети мы рекомендуем обращаться в вирусную лабораторию Доктор Веб, которая оказывает услуги по расследованию вирусозависимых компьютерных инцидентов. Оперативное принятие адекватных мер позволит сократить ущерб и предотвратить тяжелые последствия целевых атак.