🔥 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 также может успешно применяться, особенно если цель — быстрое извлечение без привязки к процессам. Но итоговая эффективность зависит от множества факторов, в том числе от формата и состояния извлекаемых фрагментов.

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

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