void Groom(HKEY hive) { for (int i = 0; i < 0x20; ++i) { wchar_t value[32]; swprintf(value, L“bin_%02d“, i); MakeBin(hive, value, 0x3FD8); RegDeleteKeyValueW(hive, NULL, value); // leaves holes for victim cells } }

</details>

Une fois qu'un primitif de corruption (overwrite/fill) est disponible, le groom garantit que la **cellule cible se trouve à côté des trous créés par le heap spraying**, permettant des overwrites précis sans heap spraying.

## Accès uniquement via l'API aux hives privilégiées via des descendants mal configurés

Windows n'évalue que l'**ACL sur le composant final** d'un chemin de registre. Si un descendant sous HKLM/HKU accorde `KEY_SET_VALUE`, `KEY_CREATE_SUB_KEY`, ou `WRITE_DAC` à des utilisateurs peu privilégiés, vous pouvez y accéder même lorsque toutes les clés parentes sont verrouillées. Project Zero a trouvé **>1000 de ces clés écrivables dans HKLM sur Windows 11**, y compris des entrées de longue durée comme `HKLM\SOFTWARE\Microsoft\DRM` et plusieurs branches `HKLM\SYSTEM`.

Practical enumeration strategy:

1. Depuis un contexte élevé, parcourez `\Registry\Machine` et `\Registry\User`, en vidant le descripteur de sécurité de chaque clé. Stockez les éléments dont la DACL autorise des SIDs non privilégiés.
2. En tant qu'utilisateur normal, tentez `RegOpenKeyEx` avec `KEY_SET_VALUE|KEY_CREATE_SUB_KEY` contre les chemins enregistrés. Les ouvertures réussies sont des cibles viables pour des bugs de corruption de hives système qui nécessitent des données contrôlées par l'attaquant dans les hives système.
3. Maintenez un cache de handles ouverts vers des emplacements stables accessibles en écriture afin que les PoCs puissent déployer directement des métadonnées corrompues.
```powershell
$targets = Get-ChildItem Registry::HKEY_LOCAL_MACHINE -Recurse |
Where-Object { (Get-Acl $_.PsPath).Access.IdentityReference -match 'S-1-5-32-545' } |
Select-Object -ExpandProperty PsPath

foreach ($path in $targets) {
try { Get-Item -Path $path -ErrorAction Stop | Out-Null }
catch {}
}

Une fois qu’un tel chemin est connu, l’exploit n’a jamais besoin de manipulation hors ligne de la ruche — les API standard du registre suffisent pour placer les cellules corrompues à l’intérieur des ruches privilégiées touchées par des services SYSTEM.

Abus inter-utilisateur de la ruche via HKCU\Software\Microsoft\Input\TypingInsights

Chaque ruche utilisateur contient HKCU\Software\Microsoft\Input\TypingInsights, dont l’ACL accorde KEY_ALL_ACCESS à Everyone (S-1-1-0). Jusqu’à ce que Microsoft resserre cela, n’importe quel utilisateur peut :

• Remplir la ruche d’un autre utilisateur jusqu’à la limite de 2 GiB, provoquant des échecs de connexion ou forçant la troncature de la ruche (utile pour contraindre le comportement de l’allocateur ou pour un DoS).
• Injecter des cellules corrompues dans le NTUSER.DAT d’autres utilisateurs, préparant des exploits latéraux qui se déclenchent lorsque le processus victime lit la clé compromise.
• Modifier les differencing hives pour des applications sandboxées qui s’appuient sur des per-user overlay hives, les forçant à consommer des métadonnées malveillantes.

Cela rend les vulnérabilités de corruption de ruche applicables au lateral movement, pas seulement à l’élévation au sein du même compte.

Transformer la corruption des métadonnées en paged pool overflows

Les grandes valeurs du registre sont stockées dans des enregistrements _CM_BIG_DATA :

• _CM_KEY_VALUE.DataLength contient la taille logique. Son bit de poids fort indique si la charge utile réside à l’intérieur de la cellule ou dans le stockage big-data.
• _CM_BIG_DATA.Count compte des chunks de 16 KiB (16384 octets moins les métadonnées) référencés via une table de chunks.

Lorsqu’un composant appelle CmpGetValueData :

1. Le kernel alloue un paged pool buffer dimensionné strictement d’après DataLength.
2. Il copie Count * 0x4000 octets depuis le stockage de la ruche dans ce buffer.

Si vous pouvez corrompre la cellule de sorte que DataLength < 16344 * (Count - 1), la copie dépasse linéairement la destination vers les objets adjacents du paged pool. Une chaîne d’exploitation fiable est :

1. Utiliser le deterministic groom pour placer le _CM_KEY_VALUE vulnérable près de métadonnées contrôlables.
2. Modifier DataLength à un petit nombre (par ex. 0x100) tout en laissant _CM_BIG_DATA.Count intact.
3. Pool-groom depuis le mode utilisateur (pipes, ALPC ports, section objects) afin qu’un objet choisi (comme le propriétaire EPROCESS->Token ou SRVNET_BUFFER) occupe le chunk suivant après l’allocation de l’étape 1.
4. Déclencher une lecture (par ex. RegQueryValueEx, NtQueryValueKey) afin que CmpGetValueData copie tous les chunks et écrase les champs du voisin avec des données contrôlées par l’attaquant provenant de la ruche.
5. Utiliser l’objet kernel corrompu pour pivoter vers une lecture/écriture arbitraire ou le vol direct du token SYSTEM.

Parce que la longueur du débordement est égale à (Count * 0x4000) - DataLength, vous obtenez un budget d’octets précis et un contrôle complet sur les octets écrits, surpassant de nombreux débordements de pool basés sur des drivers.

Inter-hive linear overflows via tightly packed HBINs

Les hives montées par le processus Registry sont mappées dans des vues alignées sur 2 MiB sans pages de garde. Vous pouvez forcer deux ruches différentes à croître en parallèle jusqu’à ce que leurs plages _HBIN se touchent :

1. Choisir une ruche modifiable par l’attaquant (app hive ou user hive) et une cible privilégiée (par ex. HKLM\SOFTWARE).
2. Créer/supprimer en continu des valeurs de 0x3FD8 octets dans les deux ruches. Chaque allocation ajoute un bin de 0x4000 octets, donc exécuter les deux écrivains en parallèle entremêle leurs bins en mémoire virtuelle (observé avec !process Registry + !vad).
3. Une fois que le bin final de la ruche attaquante se trouve immédiatement avant un HBIN appartenant à HKLM, utiliser le bug de corruption de ruche pour déborder hors de la ruche attaquante, écrasant les en-têtes HBIN ou les cellules à l’intérieur de HKLM.
4. Avec les métadonnées HKLM sous contrôle, vous pouvez :

• Mettre en place une primitive d’incohérence big-data directement dans la ruche privilégiée.
• Corrompre des données de configuration consommées par les services SYSTEM avant même qu’elles ne quittent le kernel.

L’absence de pages de garde signifie qu’un écrasement linéaire depuis une ruche non privilégiée peut corrompre directement les structures de ruche appartenant à SYSTEM, permettant des attaques uniquement sur les données ou la mise en place du débordement de pool décrit ci‑dessus à l’intérieur de HKLM/HKU.

Conseils opérationnels

• Surveiller le placement des ruches avec !vad (mode utilisateur) et !reg view / !pool (kernel) pour confirmer l’adjacence avant de déclencher le débordement.
• Mettre en cache les chemins HKLM modifiables découverts lors de l’énumération afin que les primitives de corruption puissent être déployées rapidement même après des redémarrages.
• Combiner le hive grooming avec le pool feng shui standard (pipe pair freelists, NtAllocateVirtualMemory sur le processus Registry) pour stabiliser les primitives après débordement.

Références

• Project Zero – The Windows Registry Adventure #8: Practical exploitation of hive memory corruption

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.