Статья Magnibar — сложнейший азиатский шифровальщик уже в твоем доме: история, анализ. Часть 3

Magnibar — сложнейший азиатский шифровальщик уже в твоем доме: история, анализ. Часть 3​

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

Дисклеймер ​

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

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

1. Отслеживание и анализ первичной полезной нагрузки;
2. Отслеживание и анализ вторичной полезной нагрузки;
3. Анализ ядра Magniber.

Отслеживание и анализ вторичной полезной нагрузки​

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

Если продолжить рассматривать ранее полученный журнал трассировки, то мы увидим, что в некоторые процессы было что-то записано. Видите вызов NtWriteVirtualMemory? Именно он отвечает за этот процесс. Чтобы продолжить анализ, нам нужно поймать этот самый записываемый фрагмент и выудить его из легитимного процесса.

Потому что если сейчас мы создадим любой файл, типа 1.txt, он будет мгновенно зашифрован. Магнибар жив, но действует от имени легитимного svchost.exe, то есть это не попытка маскировки, сейчас файлы действительно шифрует этот процесс.

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

1. DIE — Detect it Easy: многофункциональный инструмент, имеющий просто огромный арсенал. Позволит нам опередить тип компилятора вредоноса, язык, библиотеки и таблицы импорта/экспорта с последующим дизассемблированием.
2. PE Bear — неплохой инструмент для просмотра и редактирования составляющих PE файла.
3. Tiny Tracer — утилита для динамического отслеживания исполнения бинарных элементов. Так называемый трейсер.
4. IDA PRO — инструмент для реверс-инжиниринга. Изначально рассматривался как дополнительный инструмент, но в этой статье его роль была почти что основной.
5. Reko — декомпилятор, также знаком нам с прошлых статей.
6. Orca — простой и хороший обозреватель таблиц входящих в пакеты Microsoft Installer (.msi).
7. HollowHunter — утилита, распознает и сбрасывает множество потенциально вредоносных имплантов (замененные/имплантированные PE, шелл-коды, перехватчики, патчи в памяти).
8. BareTail — инструмент для мониторинга файла журнала в режиме реального времени. А также поможет нам просмотреть содержимое шеллкода.
9. Floss — утилита, которая использует передовые методы статического анализа для автоматического деобфускации строк из двоичных файлов вредоносных программ.

Собственно, для того, чтобы извлечь шеллкод из памяти, мы воспользуемся утилитой HollowsHunter, всё ограничивается простым запуском с параметром /shelc. Извлеченный шеллкод из процесса svchost.exe имеет название 27482842с5.shc, которое никак не связано с его оригинальным. Далее мне захотелось убедиться, что именно этот процесс и этот шеллкод являются составляющей Магнибера.

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

hollowshunter.exe /kill 27482842с5.shc

И действительно, после этой манипуляции шифрование остановилось, следовательно, мы движемся в верном направлении.

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

Воспользуемся утилитой BareTail для просмотра содержимого. Это подтверждает несколько моих гипотез:

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

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

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

floss.exe -f sc64 2d7897c0000.shc

Полученная информация подтверждает, что это действительно шелл-код Магнибера. В коде также присутствуют строки, отвечающие за удаление .vbs скрипта и информация о расширении зашифрованных файлов — .vasqdyc. Теперь мы можем перейти к более детальному анализу. Начнем с изучения того, как работает этот код и какие функции он выполняет. Наиболее логичным шагом будет использование Tiny Tracer, как это было предложено в предыдущей части статьи. Однако сначала нам нужно преобразовать .shc в исполняемый файл или внедрить его в уже существующий PE.

Немного танцев с бубном ​

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

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

Я постиг только один способ и мне он кажется достаточно простым. Мы будем использовать следующие инструменты:

1. Yasm — ассемблер, который полностью копирует код ассемблера NASM.
2. GoLink — обычный компоновщик файлов.

Для начала создаем файл со следующими инструкциями с помощью ассемблера Yasm:

Global Start
Start:
incbin "shellcode.bin"

Затем, используя тот же ассемблер и командную строку, сгенерируем файл .obj из кода, чтобы можно было применить линкер:

yasm.exe -f win 64 -o shellcode.obj shellcode.asm

А теперь задействуем GoLink, чтобы преобразовать это все в исполняемый файл:

golink /ni /entry Start shellcode.obj

Сгенерированный .exe полностью автономен и теперь с ним можно делать абсолютно всё.

Разбираем шеллкод ​

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

• ntdll;NtQueryDirectoryFile — возвращает шифровальщику информацию о файле;
• ntdll;NtQueryInformationProcess — возвращает информацию о процессе;
• ntdll;NtSetInformationFile — позволяет устанавливать информацию о файле, допустим менять расширение.

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

Охотимся за ядром​

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

1. Непосредственно шифрование данных, которое включает в себя несколько шагов:

• Генерация ключей AES.
• Генерация ключа AES и IV.
• Защита ключа AES и IV.
• Непосредственно шифрование #1.
• Непосредственно шифрование #2.

1. Вторичное повышение привилегий выполняемое между двумя этапами шифрования.
2. Сбор информации об устройстве жертвы и отправка статистики на C&C сервер.

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

Продолжение следует...

Выводы к третьей части ​

На данный момент, мы имеем достаточно запутанный шифровальщик, который взаимодействует весьма нетипичным образом. Внедрение шеллкодов в память достаточно распространено, но здесь оно реализовано целыми ступенями, что весьма забавно. Анализ ядра обещает быть достаточно интересным, так что не теряйте. А на этом у меня всё, ещё свидимся.