- PVSM.RU - https://www.pvsm.ru -
APT-группа Donot Team (также известная как APT-C-35, SectorE02) активна по крайней мере с 2012 года. Интерес злоумышленников направлен на получение конфиденциальной информации и интеллектуальной собственности. Среди целей преступников — страны Южной Азии, в частности государственный сектор Пакистана. В 2019 году мы наблюдаем их деятельность в Бангладеш, Таиланде, Индии, на Шри-Ланке и Филиппинах, а также за пределами азиатского региона — в Аргентине, ОАЭ, Великобритании.
В течение нескольких месяцев мы следили за изменениями в коде вредоносных загрузчиков группы. В этой статье мы рассмотрим один из векторов атак, подробнее остановимся на упомянутых загрузчиках и коснемся особенностей сетевой инфраструктуры.
В начале заражения жертва получает документ MS Word в формате Office Open XML. Несмотря на отсутствие явных подтверждений, мы с уверенностью полагаем, что изначальный вектор проникновения — целенаправленное фишинговое письмо с офисным вложением. Документ сам по себе не является вредоносным, но злоупотребляет возможностью автозагрузки внешних элементов для запуска документа следующей стадии.
Загружаемый файл представляет собой RTF-документ, эксплуатирующий уязвимость CVE-2018-0802 в Microsoft Equation. Работе основного шеллкода предшествует цепочка промежуточных, расшифровывающих следующий слой однобайтовым XOR с ключами 0x90 и 0xCE:
Расшифровка первым шеллкодом второго
Расшифровка вторым шеллкодом третьего
Расшифровка третьим шеллкодом основного
Основной шеллкод выполняет следующие действия:
sc create ServiceTool displayname= "ServiceFill" binpath= "C:WindowsTasksServiceflow.exe" start= "auto"
sc start ServiceTool
Расшифровка строк BAT-сценария в модифицированных библиотеках UACMe
Декомпилированный код основного шеллкода
Таким образом, на данном этапе в системе надежно закреплены два загрузчика, о работе которых мы поговорим подробнее.
Несмотря на классификацию, задачи у троянов различаются. Так, файл Serviceflow.exe выполняет сторожевую роль (watchdog). Он собирает информацию о системе:
и записывает результаты в файл log.txt. Проверяет существование файлов A64.dll и sinter.exe в каталоге WindowsTasks и в случае необходимости догружает их с управляющего сервера 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, с которым происходит дальнейшее взаимодействие. Загружаемые компоненты располагаются в каталоге AppDataRoamingInStore, а их запуск обеспечивается с помощью планировщика задач.
Расшифрованные строки фрагментов команд и шаблона задачи
Результат работы вредоносных загрузчиков — встраивание в систему компонентов фреймворка yty [2], которые позволяют извлекать более полную информацию о жертве, включая файлы с заданными расширениями, перехваченные строки ввода, список процессов, скриншоты. Мы оставим рассмотрение работы плагинов за рамками этой статьи.
Исследуя другие аналогичные образцы, мы обнаружили оставленные пути и имена проектов в отладочной информации:
Кроме подстроки «yty 2.0», связывающей трояны с вышеупомянутым фреймворком, мы отметили подстроку «Lo2», которая может быть сокращением «Loader 2».
В версиях загрузчиков до середины 2018 года все используемые строки хранились в файле в открытом виде. В следующих сборках злоумышленники стали использовать шифрование строк. От версии к версии алгоритм менялся следующим образом:
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
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
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
В процессе написания скрипта для расшифровки мы обнаружили, что некоторые отдельные строки расшифровать не удается. Но затем оказывалось, что для таких строк подходит какой-либо из других описанных выше способов расшифровки. Убедившись, что в каждом образце реализован лишь один способ декодирования данных, мы пришли к выводу, что злоумышленники попросту забывали удалить неиспользуемые строки или заменить их на правильно зашифрованные для следующей версии вредоноса.
Строки в одном из образцов загрузчика были зашифрованы различными способами, в то время как в исполняемом файле реализован лишь один
Такие ошибки всегда на руку исследователям: например, неоднократно среди забытых строк попадались контрольные серверы злоумышленников, ранее нам неизвестные.
Для полноты картины отметим некоторые характерные черты, которые помогут связать между собой будущие атаки группировки:
WHOIS-информация о домене burningforests[.]com
WHOIS-информация о домене cloud-storage-service[.]com
Donot Team отличается использованием своих собственных инструментов на каждой стадии атаки. Применяемые техники для усложнения анализа кода — с одной стороны, отсутствие попыток тщательно скрыть или замаскировать свои действия в системе — с другой. Многократные атаки [3] на одни и те же цели могут не только свидетельствовать об особом интересе к выбранному кругу жертв, но и подтверждать невысокую эффективность используемых тактик и техник.
Автор: Алексей Вишняков, Positive Technologies
Автор: ptsecurity
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/337362
Ссылки в тексте:
[1] UACMe: https://github.com/hfiref0x/UACME
[2] yty: https://attack.mitre.org/software/S0248/
[3] Многократные атаки: https://www.netscout.com/blog/asert/donot-team-leverages-new-modular-malware-framework-south-asia
[4] Источник: https://habr.com/ru/post/476740/?utm_campaign=476740&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.