Мы, ESC-VR, успешно воспроизвели эксплойт для CVE-2024-30085 😎

Уязвимость фигурировала на прошедшем в Pwn2Own 2024 в Ванкувере, где Team Theori использовала эксплойт для этой уязвимости в цепочке эксплойтов, осуществляющих Guest-To-Host-Escape из-под управления VMware Workstation, за что и получили свои заслуженные 13 очков в номинации Master Of Pwn.

Соревнования по типу pwn2own и matrixcup помогают подсветить реально эксплуатируемые уязвимости, эксплойты для которых, как правило, не разглашаются (в результате чего образуется состояние Known-Unkown, когда известно, что эксплойт есть, но как он работает неизвестно), и обратить на них особое внимание, ведь за подобными соревнованиями следим не только мы, но и злоумышленник, который может их воспроизвести и проэксплуатировать против незапатченной системы.

🧐 Cldflt.sys — это драйвер мини-фильтр, отвечающий за синхронизацию между пользовательской файловой системой и облаком OneDrive. В драйвере существовала ошибка CWE-122, возникающая в результате некорректной проверки размера bitmap, содержимое которого получается из Reparse Point. При этом память, аллоцируемая под bitmap, имеет фиксированный размер 4096 байт, но при этом не проверяется размер актуальных данных, которые будут скопированы в аллоцированную память.

Наш эксплойт утилизирует WNF- и ALPC- подсистемы для получения примитивов на запись и чтение, конкретно структуры _WNF_STATE_DATA и _ALPC_HANDLE_ENTRY.

💡 Немного деталей о том, как наш эксплойт работает:

1️⃣ Создает множества чанков, размером 4096 байт, через NtCreateWnfStateName и NtAlpcCreateResourceReserve. Таким образом последовательно в памяти размещается _WNF_STATE_DATA и _ALPC_HANDLE_ENTRY.

2️⃣ Создает множества дыр в последовательности созданной на шаге 1, через NtDeleteWnfStateData.

3️⃣ Триггерит уязвимость, таким образом bitmap размещается в одной из заранее подготовлены дыр. Размер bitmap задается равный 4096 + 16, чтобы перезаписать размер данных (_WNF_STATE_DATA.DataSize), на которые указывает _WNF_STATE_DATA.Data.

4️⃣ Перезаписывает через NtUpdateWnfStateData указатели в _ALPC_HANDLE_ENTRY.

5️⃣ Осуществляет через NtAlpcSendWaitReceivePort запись и чтение по произвольному адресу.

6️⃣ Крадет Token у процесса System (Token Stealing).

Конечно же, мы не могли не протестировать наши собственные продукты. И они нас не разочаровали: например, PT Sandbox обнаруживает эксплуатацию данной уязвимости.

Вердикты:

Exploit.Win32.Generic.d,
Exploit.Win32.Generic.a,
Rootkit.Win32.Generic.a

#escvr #cve #news
@ptescalator

СHavocают

Недавно к нам в руки попало фишинговое письмо. Тема письма указана в лучших традициях телефонных спам-звонков, когда вам звонят из ФСБ и пытаются развести на деньги 🥺

Злоумышленники переняли схему: некий Андреев Н. В. запугивает громкими словами и обязует предоставить в срок необходимый перечень документов 😳

По щелчку на документы․zip пользователь перенаправляется на сайт:

hffp[:]//inforussia[.]org/dokumenty.html

• Вместо zip-архива по ссылке открывается HTML-страница с HTML smuggling. Внутри находится большой объем данных, которые зашифрованы base64 и add(35). Во избежание детекта внутри HTML-страницы ключевые названия методов обращены в base64-строки. Зашифрованный пейлоад сохраняется как Dokument_FSB.exe.

• Внутри находится дроппер. По классике он динамически подтягивает стандартные функции из KERNEL32.DLL для загрузки шеллкода. При этом используется кастомный алгоритм хеширования:

def calc_hash(function: str, init=0x43AB):
    calc_hash = init
    for i in function:
        calc_hash = (ord(i) + 0x7313 * calc_hash) & 0xffffffff
    return calc_hash ^ 0xAB98

Но, кроме этого, загружаются такие функции:

• FindResourceW
• LoadResource
• LockResourceA
• SizeofResource
• RtlIpv6StringToAddressA

• Эти API используются для расшифровки самого пейлоада. В одном из ресурсов файла лежат IPv6-адреса, разделенные символами 0D 0A. Эти строки считываются в массив строк, затем переводятся в байты при помощи RtlIpv6StringToAddressA. Уже потом полученный массив байт ксорится с огромным ключом-строкой в 0x2710 байт.

Полученный шеллкод понтово запускают в fiber, так же динамически подгружая API для этого. Внутри находится стандартный загрузчик demon Havoc.

IOCs

2a79d641b2c377474ff640343e77517b21a51315c3736966336372b3da8995b1
7c2f59d9790b816cb6f27a796d7c928046519f7429b7d2bbe53c60a7a55e22a7
ac301b7698ac040f219eb8dfb248595a406b075d91f51116ef60d4dd9f5242ad
inforussia[.]org
193.3.23[.]121
46.29.162[.]93

#TI #Phishing #ioc
@ptescalator

Как не бороться с обфускацией 🫤

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

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

Значение, которое кладется в edx, — второй аргумент функции run_send_recv_timer — вычисляется весьма странным образом, хотя в итоге результат выглядит как на скрине 2.

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

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

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

Найти функцию расшифровки в дампе просто, нужный фрагмент кода — на скрине 3.

🧐 Встает проблема найти ссылку на функцию. Если бы семпл был x32, то задача была бы проста: найти начало функции и байты E8 <function-address-LE>, то есть call с операндом в виде адреса функции расшифровки.

Но в x64 вся адресация RIP-relative, то есть операнды-адреса — это смещения относительно конца текущей инструкции. Значит, мы найдем все инструкции call и проверим, равен ли операнд адресу начала функции расшифровки. Выглядит это так:

calls = self.mdmp.find_bytes(b"\xE8", segment_start, segment_size, find_first=False)
    decrypt_refs = []
for call_pos in calls:
    call_offset = self.mdmp.read(call_pos + 1, 4)
    call_offset = struct.unpack("<i", call_offset)[0]
    if call_pos + 5 + call_offset == decrypt_key_func_start:
        decrypt_refs.append(call_pos)
    if len(decrypt_refs) == 2:
        break

💡Примечание: ссылок две, потому что зашито два ключа — один для ECDH, второй для ECDSA, каждый расшифровывается в отдельной функции.

Найдя ссылку на функцию расшифровки, ищем начало вызывающей ее функции. Ее псевдокод — на скрине 4.

Зашифрованный ключ собирается на стеке и далее расшифровывается. Мы знаем, что за этой красотой стоит сильно обфусцированный ассемблерный код, значит, считать буфер «as is» будет тяжело.

Прибегнем к такому инструменту, как эмулятор. Мы не будем деобфусцировать это скриптом, воспроизводить логику, а просто «выполним» это и считаем результат.

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

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

def emulate_decrypt_key_func(self, func_body):
    emul = speakeasy.Speakeasy()
    shellcode = emul.load_shellcode(fpath=None, data=func_body, arch="amd64")
    ctx = {"entry": True, "mem": emul.mem_alloc(4), "skip_call": True}
    emul.add_code_hook(self.code_hook_key, ctx=ctx)
    emul.run_shellcode(shellcode)
    decrypted = self.decrypt(ctx["encrypted_string"], ctx["key"], ctx["length"])
    return decrypted

Внутри коллбэка мы пропускаем один call — вызов пустышки nullsub_4 — и останавливаемся перед вызовом decrypt_key. В этот момент в одном из параметров лежит готовый буфер с зашифрованным ключом. Далее этот буфер считывается и расшифровывается в ECDH-ключ, как видно на скрине 5.

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

#tip #trick #C2
@ptescalator

Полковники пишут первыми! (🔞)

В коллекции вредоносных рассылок от имени правоохранительных органов пополнение.

В сентябре нескольким адресатам было отправлено письмо от «Следственного комитета» с повесткой для вызова на допрос в качестве свидетеля по уголовному делу (скриншот 1).

Сама повестка — это PDF-документ, который при попытке открыть его грустно констатирует, что просмотреть содержимое не получается и нужно скачать Adobe Font Package, чтобы данные отобразились корректно (скриншот 2).

🔗 Ссылка ведет на домен adobe.updatedownloader.com, откуда, если обратиться к нему с российского IP-адреса, действительно скачивается файл с именем:

adobe_PDF_reader_fonts_update_24.2.5_Win_x86-64.exe (bea1dfdae82c67aac7a262c25dffadc0190270e2412db0c051da9ffab8e3a157)

К сожалению, файл представляет собой Medusa Stealer, поэтому прочитать документ так и не получится…

🧐 Если внимательно приглядеться к письму, можно заметить пасхалки — и разоблачить злоумышленников:

• В поле отправителя указано [email protected] — это легитимный адрес электронной почты государственного органа, однако письмо не содержит подписи DKIM, позволяющей проверить подлинность отправителя.

• Письмо отправлено c IP-адреса, не принадлежащего организации, от имени которой якобы пришла повестка.

• «СЛЕДСТВЕННIЙ КОМИТЕТ» в шапке письма.

IOCs

Net:

updatedownloader.com
62.197.48.140
5.42.73.251

Files:

bea1dfdae82c67aac7a262c25dffadc0190270e2412db0c051da9ffab8e3a157
7fa0642a96e8e9a796a4dba55877d1c730c64f257956872c3f6d405417e30024

#ti #phishing #ioc
@ptescalator

🟥 ⚔️ 💿 Виртуальный диск как начало атаки

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

✍️ VHDX-файл — это виртуальный диск, который можно подключить к системе начиная с Windows 8 двойным нажатием мыши. Он будет считаться логическим томом до выключения системы.

Как и любой контейнер, VHDX-файл может выступать в роли вредоносного объекта. Исследователь Уилл Дорманн в посте от 2019 года рассказал, что с помощью специально подготовленного образа можно спровоцировать системную ошибку в Windows и вызвать «синий экран смерти».

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

💡 Для хакеров преимущество в использовании VHDX-файлов (как и в использовании ZIP-файлов) заключается в том, что они не подпадают под действие MoTW (Mark of the Web): при запуске документа из этих контейнеров не включается режим Protected View, а Windows SmartScreen не предупреждает жертву об опасности. Стоит также отметить, что под VHDX-формат приспособлено меньшее количество антивирусных решений, чем под те же ISO-файлы. Следовательно, при попадании в систему образ вряд ли будет моментально удален этим СЗИ.

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

Хакеры допускают ошибки: они могут использовать один VHDX-файл в двух разных атаках или же загрузить ошибочные файлы. В любом из этих случаев злоумышленники, как правило, удаляют файлы, а так как это диск, то аналитик может попробовать их восстановить (в том числе с точными датами создания этих файлов) — другими словами, аналитик может построить таймлайн изменения файлов на диске. Это можно сделать с помощью специальных инструментов для проведения форензики.

👀 Рассмотрим наиболее эффективные методы и инструменты, которые можно использовать для анализа диска:

• Создание виртуальной машины и монтирование диска в нее. Это позволит посмотреть файлы в проводнике и увидеть то, что получила жертва атаки (но не удаленные файлы).

• Autopsy — универсальный инструмент для исследования образов, который может получать данные из множества файлов разных типов, физических дисков, сырых образов. Есть таймлайн изменения файлов внутри образа (пример — на втором скриншоте).

• FTK Imager — аналог программы Autopsy, показавший наилучшие результаты в извлечении удаленных файлов с диска.

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

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

#ti #tool #tip #news
@ptescalator

🛠 Реверсим Delphi без IDR

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

🕵️ Первый шаг при анализе Delphi — не забыть переключить параметр компилятора в Options → Compiler Options → Compiler, тогда IDA будет лучше обрабатывать вызовы функций.

Классы в Delphi создаются через функцию ClassCreate, которая получает на вход указатель на структуру класса и вызывает в нем функцию Tobject_NewInstance путем вычитания оффсета из указателя на VMT.

👀 Сама структура класса в Delphi выглядит следующим образом (пример на скриншоте 1):

struct DelphiClassInternal
{
  DWORD* vmt;
  DWORD* InterfaceTable; используется только для интерфейсов
  DWORD* PAutoTable; 
  DWORD* PInitTable;  
  DWORD* TypeInfo;
  DWORD* FieldTable;
  DWORD* MethodTable;
  DWORD* DynamicMethodTable;
}

💼 Рассмотрим содержимое полей TypeInfo, MethodTable и FieldTable подробнее, поскольку в них больше всего полезной для анализа информации.

➡️ TypeInfo

В Delphi каждый тип объекта имеет свой идентификатор. Как видно на скриншоте 2, для нашего объекта выставлен идентификатор 7 — тип Class. В зависимости от этого типа, для объекта указывается соответствующий контекст. Для классов это информация о Property и указатель на родительский тип. Зная имя Property, нетрудно понять и разметить Get/Set-функции. Восстановление этих имен позволяет сильно упростить восприятие некоторых блоков кода. Пример на скриншоте 3.

➡️ MethodTable

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

Псевдоструктуру метода можно представить так (пример на скриншоте 4):

struct CMArg
{
  DWORD* TypeInfo;
  WORD   UNK;
  BYTE   NameLen;
  char   Name[];
  BYTE   UNK2[3];
}
struct ClassPubMethod
{
   WORD   EntrySize;
   DWORD* MethodPtr;
   BYTE   NameLen;
   char   Name[];
   WORD   W_UNK1;
   DWORD* ReturnType;
   WORD   W_UNK2;
   BYTE   ArgCount;
   CMArg  Args[];
}

Из-за механизма наследования методов в Delphi восстановление даже части имен методов имеет большую пользу, если сделать это глобально, для всех классов. Затем это можно использовать среди прочего и для генерации структуры VMT класса с осмысленными именами. Пример — на скриншоте 5.

➡️ FieldTable

Заглянув в Class → FieldTable, можно найти большое количество информации о переменных (пример на скриншоте 6). Представлена она может быть в двух вариантах:

1. В виде имени, оффсета и номера типа переменной (из таблицы типов). Первые два байта в FieldTable — количество элементов в этой таблице, следующие четыре — указатель на таблицу типов.

2. В виде имени, оффсета и указателя на тип переменной (таблица начинается сразу после таблицы из п. 1).

Структура переменных имеет следующий вид:

struct VarTypeTable
{
  WORD   Count;
  DWORD* Entries[];
}
struct ClassVar
{
  DWORD* TypeInfo;
  WORD   VarOffset;
  WORD   UNK;
  BYTE   NameLen;
  char   Name[];
}
struct TableClassVar
{
  WORD VarOffet;
  WORD UNK;
  WORD TableTypeNum;
  BYTE NameLen;
  char Name[];
}

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

🤔 Резюме: в Delphi присутствует большое количество RTTI-информации, за счет которой можно относительно просто разметить большое количество функций или восстановить структуру классов для упрощения статического анализа.

#TI #Delphi #Reverse
@ptescalator