Создатели вредоносного ПО используют множество техник для обхода антивирусов. Самая распространённая из них – это упаковывание: эта техника позволяет сжать или зашифровать вредоносный код. Вместо него в операционную систему загружается код распаковщика, который несет в себе сжатую/зашифрованную нагрузку. После её распаковки код передаёт управление вредоносному ПО.
Данный процесс можно представить в виде следующей последовательности действий:
Распаковка вируса – это первый шаг в его анализе. Пока этого не будет сделано, мы не сможем узнать о его базовых функциях. В основе большинства техник распаковки лежат три следующие функции Windows API.
1) VirtualAlloc:
Выделяет или изменяет состояние региона виртуальной памяти вызывающего процесса. Память выделенная этой функцией автоматически инициализируется нулями.
Тут самым важным аргументом является lpaddress, который задаёт базовый адрес буфера для кода [если передать NULL, система сама выберет адрес]. Эта часть API критична в анализе зарезервированной/выделенной памяти зловредным ПО в случаях process injection.
2) VirtualProtect:
Эта функция изменяет права доступа к региону виртуальной памяти вызывающего процесса.
Для того, чтобы вредоносный код мог исполняться, необходимо добавить, используя VirtualProtect, право на исполнение [aka execute] в выделенном регионе памяти. Таким образом, в коде распаковщика, можно наблюдать последовательность чередующихся вызовов VirtualAlloc и VirtualProtect.
Один из значимых аргументов функции – это константа flNewProtect, которая имеет значения, позволяющие менять права доступа к региону памяти на PAGE_EXECUTE_READWRITE (0x40), PAGE_EXECUTE_READ (0x20) и тд .
3) CreateProcessInternalW:
Рис. 1 Последовательность функций для создания нового процесса, когда вызывается ShellExecuteA.
CreateProcessInternalW – незадокументированная функция WinAPI, которая позволяет создать новый процесс.
Когда вирус распаковывается self-injection’ом, ему необходимо создать новый процесс, поэтому, они часто используют данный системный вызов – к нему сводятся все техники self-injection.
Расположите брейкпоинты на:
CreateProcessInternalW – обнаружить self-injection техники
VirtualAlloc , VirtualProtect – обнаружить process injection
Демонстрация: Process Injection
[Астарожна и дангер, если будешь ревёрсить малварь, не пренебрегай виртульной машиной]
Для демонстрации нам понадобится x64dbg и опытный образец TrickBot’а, который использует process injection; заинжектить вредоносный код в explorer.exe для дальнейшего выполнения.
Рис. 2 PE секция упакованной малвари
Рис. 3 Таблица импортов упакованной малвари
Две картинки выше показывают импорты и PE секции упакованного вредоносного ПО. Высокая энтропия [двумя словами:мера хаоса; тысячей восемьюстами: тык ], малое количество импортов и странный вид секций – это всё признаки упакованного вируса. Небольшое различие между размерами секций (рис.2 raw – 4A400 и virtual – 4B000) допустима, однако если оное слишком велико – это еще один признак упакованного вредоносного ПО. Вдобавок запуск Floss by Fireeye не показывает много осмысленных строк.
Рис. 4 Точка останова на VirtualAlloc
Как было объяснено выше: наш первый шаг – это поставить брейкпоинты на VirtualAlloc, VirtualProtect и CreateProcessInternalW [для большей секьюрности можно поставить и на CreateRemoteThread с ResumeThread].
Это легко сделать в консоли ниже дебаггера, напечатав:
bp VirtualAlloc
bp VirtualProtect
bp CreateProcessInternalW
Рис. 5 Зажимаем step over до тех пор пока не встречаем ret и ставим на нём брейкпоинт
После достижения первого VirtualAlloc брейкпоинта, нажимаем step over до первой ret или retn инструкции, ставим на ней брейкпоинт. Когда останавливаемся на этой инструкции, смотрим на значение EAX, что, возможно, содержит адрес буфера для инъекции вредоносного кода.
Правый клик по EAX → Follow in dump
Следуем за EAX адресом в новом окне дампа (их аж 5 штук в x64dbg). Достигнув брейкпоинта, проверяем предыдущие дампы. После нескольких остановок будет заметен MZ заголовок в одном из окошек дампа.
Рис. 6 Вывод после нескольких остановок на VirtualAlloc
Рис. 7 Memory map курильщика)
Когда видим распакованный вредоносный код, кликаем на MZ заголовок и переходим в memory map.
ПКМ на секцию и клик по dump the file.
Открываем дамп в каком-нибудь PE viewer (например PE Bear) и проверяем нормально ли распаковалось.
Рис. 8 Таблица импортов распакованного вируса
Рис. 9 Секции таблицы распакованного вируса
Теперь мы видим нормальные импорты и секции таблиц. Это значит мы распаковали наше вредоносное ПО и можем приступать к дальнейшему анализу.
Источник: https://medium.com/@aroralakshay2014/unpacking-malware-like-a-pro-85cd00c870e9
Данный процесс можно представить в виде следующей последовательности действий:
| 1 2 3 4 5 6 7 8 9 | Начало Е = зашифрованный_код К = извлечь_ключ() М = расшифровать_код(Е, К) адрес = загрузить_в_память(М) передать_управление(адрес) Конец |
Распаковка вируса – это первый шаг в его анализе. Пока этого не будет сделано, мы не сможем узнать о его базовых функциях. В основе большинства техник распаковки лежат три следующие функции Windows API.
| 1 2 3 | VirtualAlloc() CreateProcessInternalW() VirtualProtect() |
1) VirtualAlloc:
Выделяет или изменяет состояние региона виртуальной памяти вызывающего процесса. Память выделенная этой функцией автоматически инициализируется нулями.
| 1 2 3 4 5 6 | LPVOID VirtualAlloc( LPVOID lpAddress, SIZE_T dwSize, DWORD flAllocationType, DWORD flProtect ); |
Тут самым важным аргументом является lpaddress, который задаёт базовый адрес буфера для кода [если передать NULL, система сама выберет адрес]. Эта часть API критична в анализе зарезервированной/выделенной памяти зловредным ПО в случаях process injection.
2) VirtualProtect:
Эта функция изменяет права доступа к региону виртуальной памяти вызывающего процесса.
Для того, чтобы вредоносный код мог исполняться, необходимо добавить, используя VirtualProtect, право на исполнение [aka execute] в выделенном регионе памяти. Таким образом, в коде распаковщика, можно наблюдать последовательность чередующихся вызовов VirtualAlloc и VirtualProtect.
| 1 2 3 4 5 6 | BOOL VirtualProtect( LPVOID lpAddress, SIZE_T dwSize, DWORD flNewProtect, PDWORD lpflOldProtect ); |
Один из значимых аргументов функции – это константа flNewProtect, которая имеет значения, позволяющие менять права доступа к региону памяти на PAGE_EXECUTE_READWRITE (0x40), PAGE_EXECUTE_READ (0x20) и тд .
3) CreateProcessInternalW:
Рис. 1 Последовательность функций для создания нового процесса, когда вызывается ShellExecuteA.
CreateProcessInternalW – незадокументированная функция WinAPI, которая позволяет создать новый процесс.
Когда вирус распаковывается self-injection’ом, ему необходимо создать новый процесс, поэтому, они часто используют данный системный вызов – к нему сводятся все техники self-injection.
Расположите брейкпоинты на:
CreateProcessInternalW – обнаружить self-injection техники
VirtualAlloc , VirtualProtect – обнаружить process injection
Демонстрация: Process Injection
[Астарожна и дангер, если будешь ревёрсить малварь, не пренебрегай виртульной машиной]
Для демонстрации нам понадобится x64dbg и опытный образец TrickBot’а, который использует process injection; заинжектить вредоносный код в explorer.exe для дальнейшего выполнения.
Рис. 2 PE секция упакованной малвари
Рис. 3 Таблица импортов упакованной малвари
Две картинки выше показывают импорты и PE секции упакованного вредоносного ПО. Высокая энтропия [двумя словами:мера хаоса; тысячей восемьюстами: тык ], малое количество импортов и странный вид секций – это всё признаки упакованного вируса. Небольшое различие между размерами секций (рис.2 raw – 4A400 и virtual – 4B000) допустима, однако если оное слишком велико – это еще один признак упакованного вредоносного ПО. Вдобавок запуск Floss by Fireeye не показывает много осмысленных строк.
Рис. 4 Точка останова на VirtualAlloc
Как было объяснено выше: наш первый шаг – это поставить брейкпоинты на VirtualAlloc, VirtualProtect и CreateProcessInternalW [для большей секьюрности можно поставить и на CreateRemoteThread с ResumeThread].
Это легко сделать в консоли ниже дебаггера, напечатав:
bp VirtualAlloc
bp VirtualProtect
bp CreateProcessInternalW
Рис. 5 Зажимаем step over до тех пор пока не встречаем ret и ставим на нём брейкпоинт
После достижения первого VirtualAlloc брейкпоинта, нажимаем step over до первой ret или retn инструкции, ставим на ней брейкпоинт. Когда останавливаемся на этой инструкции, смотрим на значение EAX, что, возможно, содержит адрес буфера для инъекции вредоносного кода.
Правый клик по EAX → Follow in dump
Следуем за EAX адресом в новом окне дампа (их аж 5 штук в x64dbg). Достигнув брейкпоинта, проверяем предыдущие дампы. После нескольких остановок будет заметен MZ заголовок в одном из окошек дампа.
Рис. 6 Вывод после нескольких остановок на VirtualAlloc
Рис. 7 Memory map курильщика)
Когда видим распакованный вредоносный код, кликаем на MZ заголовок и переходим в memory map.
ПКМ на секцию и клик по dump the file.
Открываем дамп в каком-нибудь PE viewer (например PE Bear) и проверяем нормально ли распаковалось.
Рис. 8 Таблица импортов распакованного вируса
Рис. 9 Секции таблицы распакованного вируса
Теперь мы видим нормальные импорты и секции таблиц. Это значит мы распаковали наше вредоносное ПО и можем приступать к дальнейшему анализу.
Источник: https://medium.com/@aroralakshay2014/unpacking-malware-like-a-pro-85cd00c870e9