💀 Уязвимости — старые, атаки — новые

Продолжаем делиться нашими исследованиями: сегодня поговорим о внедрении шеллкода в Microsoft Office и разберем старую, но до сих пор актуальную уязвимость CVE-2017-11882, связанную с работой компонента Microsoft Equation Editor (EQNEDT32.EXE).

Мы рассмотрим документ Excel — XML-файл, сжатый в ZIP-архив. Документы Excel могут быть бинарными, их формат — Compound Binary File Format. К бинарным форматам относятся Excel 97-2003, Excel 5.0/95.

🔎 Предварительный анализ

На рисунке 1 — фрагмент содержимого вредоноса в hex-редакторе. Сигнатура 50 4B указывает на то, что это формат ZIP. Для первичного анализа воспользуемся утилитой OfficeMalScanner. Команда Inflate показывает содержимое документа и сохраняет файлы в C:\Users\<username>\AppData\Local\Temp\DecompressedMsOfficeDocument.

На рисунке 2 видно, что в нашем образце RFQPC25-1301.xlsx есть подозрительный файл Q5.8ZIBJ. Хотя утилита OfficeMalScanner сохранила содержимое исследуемого файла, для примера извлечем его другим способом.

Сохраним файл RFQPC25-1301.xlsx и изменим его расширение на .zip, чтобы просмотреть вложенное содержимое, а именно файл Q5.8ZIBJ. На рисунке 3 выделена сигнатура D0 CF 11 E0 A1 B1 1A E1 (Compound Binary File Format) — именно этот файл эксплуатирует CVE-2017-11882.

💻 Расшифровка шеллкода

Поскольку CVE-2017-11882 связана с переполнением буфера стека и позволяет выполнить шеллкод, необходимо найти его точку входа и понять, какие команды он будет выполнять. Вернемся к OfficeMalScanner, найдем точку входа и попробуем применить перебор ключей XOR для расшифровки основного тела шеллкода.

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

Для отладки шеллкода используем самописную подсобку, которая открывает файл download.dat, считывает его и переходит посредством call на начальный адрес считанных байт. Переименовав файл Q5.8ZIBJ в download.dat, запускаем в отладчике подсобку. Чтобы попасть на точку входа в шеллкод, необходимо пересчитать адрес (рисунок 5). Прибавим к начальному адресу адрес, полученный при помощи OfficeMalScanner (адреса ee554, ee593; рисунок 6). Отметим, что результат выполнения и данные одинаковы вне зависимости от того, какой адрес мы выберем (рисунок 7).

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

Для быстрой расшифровки поставим точку останова на финальную команду перед исполнением и запустим код в отладчике. На рисунке 8 — следующие строки расшифрованного шеллкода:

LoadLibraryW
GetProcAddress
ExpandEnvironmentStringsW
%APPDATA%\word.exe
UrlMonURLDownloadToFileW
http://combo.s3.eu-north-1[.]amazonaws.com/jekonbary2.1.exe
WideCharToMultiByte
WinExec
ExitProcess

🕵️‍♀️ Подводим итоги. Как работает шеллкод:

➡️ Получает адреса WinAPI-функций GetProcAddress и LoadLibraryW.
➡️ При помощи этих функций получает адреса других необходимых API.
➡️ Выполняет функцию ExpandEnvironmentStringsW. Передав ей аргумент %APPDATA%\word.exe, получает значение %APPDATA%\Roaming\word.exe.
➡️ При помощи UrlMonURLDownloadToFileW скачивает основной модуль, расположенный по адресу http://combo.s3.eu-north-1[.]amazonaws.com/jekonbary2.1.exe, и сохраняет его под именем word.exe.
➡️ Запускает скачанный модуль с помощью WinExec.

Файл word.exe — это скомпилированный скриптовый сценарий AutoIt. После извлечения скрипта мы установили:

🔸 В коде содержится шеллкод, обфусцированный путем добавления в строку 561840652.
🔸 В теле скрипта размещена основная бинарная нагрузка, которая расшифровывается при помощи шеллкода с использованием XOR-ключа 9A6VBEF324RR3VT3Z8.
🔸 Сам бинарный файл копируется в директорию C:\Users\<username>\AppData\Local\Temp с именем Mazatl, после этого шеллкод запускает легитимные процессы и переписывает секцию .code вредоносным расшифрованным кодом.

👀 Больше деталей — в нашей статье на Хабре 💎

🔥 GuLoader: как злоумышленники используют инсталлятор NSIS

Недавно мы рассказывали, как злоумышленники используют в атаках язык AutoIt, сегодня по следам нашей новой статьи на Хабре поговорим о ВПО GuLoader и разберем атаку с применением другого легитимного инструмента — NSIS.

💀 Nullsoft Scriptable Install System (NSIS) — система создания установочных программ для Microsoft Windows с открытым исходным кодом, разработанная компанией Nullsoft. NSIS была задумана как альтернатива InstallShield, предназначенного для коммерческих продуктов.

⚙️ Изучим вредоносный файл

Определить, что ВПО собрано при помощи NSIS, можно, например, с помощью Detect It Easy. Для извлечения содержимого из установочного файла можно воспользоваться архиватором 7-Zip. Извлечем все файлы в директорию и проанализируем их (рисунок 1).

Стоит обратить внимание на Basted.Non (фрагмент его содержимого в hex-редакторе — на рисунке 2). Откроем файл в Notepad++ и изучим. В коде на рисунке 3 есть переменные Colloque и Hexonic с кажущимися бессмысленными текстовыми сообщениями, а также функция Logjam, которая начиная с седьмого символа формирует строку с шагом восемь символов. В код также добавлены «мусорные инструкции».

Для деобфускации сохраняем основной массив текста (переменную Colloque) в файл и воспроизводим сценарий (рисунок 5). Отдельно отметим, что переменная Hexonic преобразуется в IEX.

👁 Проанализируем код

Деобфусцированный код преобразуем в читаемый вид (рисунок 6) — здесь обратим внимание, что значения некоторых переменных заданы в виде шестнадцатеричных строк. Также есть строка (выделена зеленым), которая преобразуется через функцию Logjam (выделена красным). После ее деобфускации получим: $Anfordring -bxor $danabluen.

XOR-ключом является 189 dec (bd — в hex-формате), он выделен желтым цветом. Функция Counteraggressions, предназначенная для XOR-операций, — синим. Функция Bitterish отвечает за конвертацию строк в виде hex-значений в байты.

Дополним сценарий алгоритмом преобразования и расшифровки строк (рисунок 7). На рисунке 8 — фрагмент кода с расшифрованными строками в читаемом виде.

🔎 Что внутри

На рисунке 9 — основной алгоритм вредоносного сценария. Отметим, что, так как второй регион памяти (переменная Kriminalbetjent) изначально имеет атрибут PAGE_READWRITE, то исполняться будет шеллкод из региона Minerne.

Шеллкод заполнен «мусорными инструкциями» и антиотладочными приемами, и исследовать его проблематично. Дерево процессов, а также сетевая коммуникация при динамическом анализе — на рисунке 10. Нагрузка, которую пытается скачать шеллкод, на данный момент недоступна.

Стоит отметить, что байты, ранее записанные в регион памяти Kriminalbetjent, также присутствуют в одном из регионов памяти процесса msiexec.exe, но страница уже имеет атрибут PAGE_EXECUTE_READWRITE.

🕵️‍♀️ Итоги, или Все по классике

Как и в случае вредоноса, написанного на AutoIt, для доставки ВПО GuLoader на атакуемую систему используется легитимный инсталлятор, позволяющий упаковать файл. Внутри основного вредоносного файла — всe по классике: XOR-шифрование и «мусорный» код, затрудняющий анализ. Мы смогли частично восстановить техники злоумышленников, а также получить дополнительные индикаторы, проведя ручной анализ, и не дали заражению распространиться.

➡️ Читать полную версию статьи на Хабре 💎

⚙️ Как восстановить удаленные журналы событий

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

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

1️⃣ Фреймворк Volatility

Журналы событий хранятся в файлах с расширением .evtx и имеют одноименный формат. Попробуем извлечь их при помощи фреймворка Volatility, позволяющего получить имена журналов, в отличие, например, от Bulk Extractor.Поскольку мы знаем, что регистрацией журналов событий занимается служба EventLogs в контексте процесса svchost, нам нужно найти PID этого процесса и сохранить EVTX-файлы, содержащиеся в его памяти. Самый простой способ поиска нужного нам процесса — это поиск хэндлов к файлам, в именах директорий которых содержится строка winevt (рисунок 1). Когда мы нашли нужный PID, сохраним файлы из памяти этого процесса.

У Volatility есть небольшой минус: помимо EVTX-файлов, сохраняются и другие файлы, но это не критично, если далее мы восстанавливаем их при помощи CQEVTXRecovery. Копируем все файлы из директории /home/forensic/dump/ в директорию C:\test\evtxrec\reca. Поскольку структура извлеченных EVTX-файлов повреждена, необходимо восстановить ее. Попробуем сделать это при помощи утилиты CQEVTXRecovery (рисунок 2). Как видим по рисунку 3, результат неутешительный: информации в журналах нет.

2️⃣ Bulk Extractor

Теперь попробуем найти и сохранить EVTX-файлы при помощи Bulk Extractor. Метод поиска данных в Bulk Extractor построен на карвинге: указываем файл, где нужно искать, директорию, в которой необходимо сохранить найденные данные, и непосредственно формат данных, которые необходимо найти (рисунок 4). Когда карвинг-данные сохранены, попробуем восстановить журналы при помощи EvtxECmd (рисунок 5). Стоит отметить, что утилита, в отличие от Volatility, не сможет проанализировать директорию, в которой будут не только EVTX-файлы. На выходе получим CSV-файл и посмотрим результат при помощи Timeline Explorer (рисунок 6). Нужного результата мы опять не получили. Казалось бы — ну вот и все, ключевые сведения в журналах не сохранились. Но не тут-то было. Давайте вернемся к журналам, которые мы сохранили при помощи Volatility. Просмотрев содержимое файлов, находим интересную информацию (рисунки 7–9). Как видим, теперь у нас есть информация для дальнейших действий по реагированию на инцидент. Стоит отметить, что очистка журналов не влияет на данные, содержащиеся в оперативной памяти: журналы событий будут повреждены и при обычных условиях.

💻 Итоги: утилиты не панацея

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

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

Желаем удачных расследований! Полную версию статьи вы можете прочитать на Хабре 😉