Исследуем активность кибергруппировки Donot Team

APT-группа Donot Team (также известная как APT-C-35, SectorE02) активна по крайней мере с 2012 года. Интерес злоумышленников направлен на получение конфиденциальной информации и интеллектуальной собственности. Среди целей преступников — страны Южной Азии, в частности государственный сектор Пакистана. В 2019 году мы наблюдаем их деятельность в Бангладеш, Таиланде, Индии, на Шри-Ланке и Филиппинах, а также за пределами азиатского региона — в Аргентине, ОАЭ, Великобритании.

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

Цепочка атаки

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

Загружаемый файл представляет собой RTF-документ, эксплуатирующий уязвимость CVE-2018-0802 в Microsoft Equation. Работе основного шеллкода предшествует цепочка промежуточных, расшифровывающих следующий слой однобайтовым XOR с ключами 0x90 и 0xCE:

Основной шеллкод выполняет следующие действия:

• Однобайтовым XOR с ключом 0x79 расшифровывает бинарные данные из файла %TEMP%\one.
• Создает исполняемые файлы C:\Windows\Tasks\Serviceflow.exe и C:\Windows\Tasks\sinter.exe. Это вредоносные загрузчики группы, о которых мы еще поговорим.
• Создает файл C:\Windows\Tasks\S_An.dll, в котором записаны два байта 0x90.
• Создает файл C:\Windows\Tasks\A64.dll. В зависимости от разрядности системы это модифицированная x64- или x86-версия утилиты UACMe для повышения привилегий в системе. Помимо обхода контроля UAC библиотека создает и запускает BAT-сценарий %TEMP%\v.bat, который зарегистрирует один из созданных ранее загрузчиков как службу при помощи следующих команд:

sc create ServiceTool displayname= "ServiceFill" binpath= "C:\Windows\Tasks\Serviceflow.exe" start= "auto"
sc start ServiceTool

• Создает и запускает JScript-сценарий C:\Windows\Tasks\bin.js. Его задача — запустить библиотеку A64.dll через экспорт RnMod средствами rundll32.
• Создает ярлык WORDICON.lnk в каталоге автозагрузки. Его задача — запустить загрузчик sinter.exe после перезагрузки системы.
• Создает ярлык Support.lnk в каталоге автозагрузки. Его задача — запустить JScript-сценарий bin.js после перезагрузки системы.

Таким образом, на данном этапе в системе надежно закреплены два загрузчика, о работе которых мы поговорим подробнее.

Загрузчики Lo2

Несмотря на классификацию, задачи у троянов различаются. Так, файл Serviceflow.exe выполняет сторожевую роль (watchdog). Он собирает информацию о системе:

• имя пользователя,
• имя компьютера,
• содержимое каталогов \Program Files\ и \Program Files (x86)\,
• версию ОС,
• данные о процессоре —

и записывает результаты в файл log.txt. Проверяет существование файлов A64.dll и sinter.exe в каталоге \Windows\Tasks\ и в случае необходимости догружает их с управляющего сервера skillsnew[.]top и запускает от имени текущего пользователя, извлекая соответствующий токен из процесса winlogon.exe. Троян sinter.exe сигнализирует атакующим о заражении обращением к hxxps://mystrylust.pw/confirm.php и отправляет предварительно собранную информацию о системе по адресу skillsnew[.]top. Затем, если компьютер жертвы представляет дальнейший интерес, получает содержимое файла customer.txt по адресу hxxp://docs.google.com/uc?id=1wUaESzjGT2fSuP_hOJMpqidyzqwu15sz&export=download. В файле содержится имя управляющего сервера car[.]drivethrough.top, с которым происходит дальнейшее взаимодействие. Загружаемые компоненты располагаются в каталоге \AppData\Roaming\InStore\, а их запуск обеспечивается с помощью планировщика задач.

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

Исследуя другие аналогичные образцы, мы обнаружили оставленные пути и имена проектов в отладочной информации:

• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\New_Single_File\Lo2\SingleV2\Release\BinWork.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\New_Single_File\Lo2\SingleV2_Task_Layout_NewICON\Release\BinWork.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\New_Single_File\Lo2\SingleV2_Task_Layout_NewICON_N_Lnk\Release\BinWork.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\New_Single_File\Lo2\SingleV3\Release\WorkFile.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\Off\Off_New_Api\Release\C++\ConnectLink.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\Off\Off_New_Api\Release\C++\TerBin.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\m0\yty 2.0 - With AES Chunks LOC FOR XP Just Bit-Change_Name\Release\TaskTool.pdb
• D:\Soft\DevelopedCode_Last\BitDefenderTest\yty 2.0 - With AES Chunks OFFS Just Bit\Release\C++\MsBuild.pdb
• D:\Soft\DevelopedCode_Last\yty 2.0\Release\C++\Setup.pdb

Кроме подстроки «yty 2.0», связывающей трояны с вышеупомянутым фреймворком, мы отметили подстроку «Lo2», которая может быть сокращением «Loader 2».

В версиях загрузчиков до середины 2018 года все используемые строки хранились в файле в открытом виде. В следующих сборках злоумышленники стали использовать шифрование строк. От версии к версии алгоритм менялся следующим образом:

• С мая 2018 года: перевернуть строку и закодировать Base64.
• С апреля 2019 года: выполнить предыдущие действия дважды.
• С января 2019 года: зашифровать строку алгоритмом AES в режиме CBC и закодировать Base64. Пример кода на Python для расшифровки:

import base64
from Cryptodome.Cipher import AES

aeskey = (0x23, 0xd4, 0x67, 0xad, 0x96, 0xc3, 0xd1, 0xa5, 0x23, 0x76, 0xae, 0x4e, 0xdd, 0xca, 0x13, 0x55)

def aes_decrypt(data, aeskey):
	iv = bytes(list(range(0, 16)))
	key = bytes(aeskey)
	aes = AES.new(key, AES.MODE_CBC, iv)
	return aes.decrypt(data).decode().strip('\x00')

def base64_aes_decrypt(data, aeskey):
	data = base64.b64decode(data)
	data = aes_decrypt(data, aeskey)
	return data

• С июня 2019 года: выполнить посимвольное цикличное вычитание с заданным массивом байтов, закодировать с помощью UTF-8 и закодировать Base64. Пример кода на Python для расшифровки:

subgamma = (0x2d, 0x55, 0xf, 0x59, 0xf, 0xb, 0x60, 0x33, 0x29, 0x4e, 0x19, 0x3e, 0x57, 0x4d, 0x56, 0xf)

def sub_decrypt(data, subgamma):
	o = ''
	length = len(data)
	subgamma_length = len(subgamma)
	for i in range(length):
		o += chr((0x100 + ord(data[i]) - subgamma[i%subgamma_length]) & 0xff)
	return o

def base64_utf8_sub_decrypt(data, subgamma):
	data = base64.b64decode(data)
	data = data.decode('utf-8')
	data = sub_decrypt(data, subgamma)
	return data

• С октября 2019 года: выполнить посимвольный цикличный модифицированный XOR с заданным массивом байтов и закодировать Base64 дважды. Особенность алгоритма XOR в том, что если значение символа строки совпадает со значением символа в заданном массиве байтов — XOR выполнять не нужно. Пример кода на Python для расшифровки:

xorgamma = (0x56, 0x2d, 0x61, 0x21, 0x16)

def modxor_decrypt(data, xorgamma):
	o = ''
	length = len(data)
	xorgamma_length = len(xorgamma)
	for i in range(length):
		c = data[i]
		if c != xorgamma[i%xorgamma_length]:
			c = data[i] ^ xorgamma[i%xorgamma_length]
		o += chr(c)
	return o

def base64_modxor_decrypt(data, xorgamma):
	data = base64.b64decode(data)
	data = modxor_decrypt(data, xorgamma)
	return data

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

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

Особенности сетевой инфраструктуры

Для полноты картины отметим некоторые характерные черты, которые помогут связать между собой будущие атаки группировки:

• Бóльшая часть управляющих серверов арендована у провайдера DigitalOcean, LLC (ASN 14061) и расположена в Амстердаме.
• Атакующие не используют одни и те же серверы для разных DNS-имен: для каждого нового доменного имени предпочитают резервировать новый выделенный хост.
• В большинстве случаев регистрационные данные владельцев доменов скрыты услугами приватности. Для этого используются следующие сервисы: WhoisGuard, Inc.; Whois Privacy Protection Service, Inc.; Domains By Proxy, LLC; Whois Privacy Protection Foundation. В некоторых случаях данные доступны, и можно проследить общий подход к заполнению полей.

• Используются преимущественно .top, .pw, .space, .live и .icu TLD.

Заключение

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

Автор: Алексей Вишняков, Positive Technologies

IOCs