Windows Registry Hive Exploitation Primitives

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

なぜ hive の破損が特別なのか

Windows registry hives は memory-mapped .regf files で、カスタムアロケータ（HvAllocateCell、HvReallocateCell、HvFreeCell）によって管理されます。アロケータは以下の特徴を持ちます:

  • 割り当てをランダム化しない — セルの配置は以前の registry API 呼び出しの順序/サイズのみに依存するため、レイアウトはホスト間で再現可能です。
  • 整合性チェックが欠如している — ヘッダ/データフィールドを手動で変更しても、カーネル側の消費者（Cmp* ルーチン）や Registry プロセス自体がそれを信用します。
  • 特権のある hives とアドレス空間を共有する — 多くの場合、攻撃者が制御する hives が HKLM/HKU hives と同じユーザーモードのアドレス領域にマップされ、ハイブ間のオーバーフローを可能にします。

これにより、hive ベースのメモリ破損バグ（例: CVE-2023-23420 / CVE-2023-23423）は、LPE に対して非常に信頼性が高くなります。

registry API による決定論的なレイアウトグルーミング

hive の割り当てが決定論的であるため、Win32 APIs のみでセルの配置をグルーミングできます。典型的なワークフローは次のとおりです:

  1. ターゲットキーをリセット（削除/再作成）して、hive bin が既知のセルのみを含むようにします。
  2. 慎重に選択したサイズの値を作成して予測可能な連続セルを割り当てる:
  • キー/値のメタデータセルは8バイトの倍数です。
  • 0x3FD8バイトの値を書き込むと、新しい0x4000バイトの bin（0x3FD8 データ + _HBIN ヘッダ/パディング）を強制し、後で bin をインターリーブするのに理想的です。
  1. resize に優しい型を使用する（例: REG_BINARY）と、長さを変えて RegSetValueEx を呼ぶだけで個々のセルを解放/拡張できます。
  2. 操作のシーケンスを記録する（作成/削除/リサイズ）。アロケータにランダム性がないため、これを再生すると他のシステムで同じレイアウトが再現されます。
Example layout shaper (simplified C) ```c void MakeBin(HKEY base, const wchar_t *name, size_t bytes) { std::vector buf(bytes, 0x41); RegSetKeyValueW(base, NULL, name, REG_BINARY, buf.data(), (DWORD)buf.size()); }

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>

Once a corruption primitive (overwrite/fill) is available, the groom guarantees that the **target cell resides next to the sprayed holes**, enabling precise overwrites without heap spraying.

## 誤設定された子孫キーを介した API-only の特権ハイブへのアクセス

Windows はレジストリパスの最後のコンポーネントの **ACL のみを評価します。** HKLM/HKU 以下のいずれかの子孫が低権限ユーザーに `KEY_SET_VALUE`、`KEY_CREATE_SUB_KEY`、または `WRITE_DAC` を付与している場合、親キーがすべてロックされていてもそれに到達できます。Project Zero は Windows 11 の HKLM に **>1000 のそのような書き込み可能なキー** を発見しました。例として `HKLM\SOFTWARE\Microsoft\DRM` のような長期間存在するエントリや、いくつかの `HKLM\SYSTEM` ブランチが含まれます。

Practical enumeration strategy:

1. 昇格したコンテキストから `\Registry\Machine` と `\Registry\User` を走査し、各キーの security descriptor をダンプします。DACL が非特権の SIDs を許可しているエントリを保存してください。
2. 通常ユーザーとして、記録したパスに対して `RegOpenKeyEx` を `KEY_SET_VALUE|KEY_CREATE_SUB_KEY` で試みます。成功して開けたものは、システムハイブ内の攻撃者制御データを必要とする hive corruption バグの実行可能なターゲットになります。
3. PoCs が直接破損したメタデータを展開できるよう、**stable writable locations** へのオープンハンドルのキャッシュを維持してください。
```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 {}
}

Once such a path is known, the exploit never needs offline hive tampering—標準のレジストリAPIで十分 to stage the corrupt cells inside privileged hives touched by SYSTEM services.

HKCU\Software\Microsoft\Input\TypingInsights を介したユーザー間ハイブ悪用

各ユーザーハイブには HKCU\Software\Microsoft\Input\TypingInsights が存在し、そのACLは KEY_ALL_ACCESS を Everyone (S-1-1-0) に付与している。Microsoft が修正するまで、任意のユーザーは次を行える：

  • 他ユーザーのハイブを2 GiBの上限まで埋め、ログオン失敗やハイブの切り詰めを引き起こす（アロケータ挙動を誘導したりDoSに有用）。
  • 他ユーザーの NTUSER.DAT に破損セルを注入し、被害者プロセスが改ざんされたキーを読み取った際に発動する横移動用のエクスプロイトを仕込める。
  • ユーザーごとのオーバーレイハイブに依存するサンドボックス化されたアプリのための差分ハイブを改変し、悪意のあるメタデータを読み込ませる。

これにより、ハイブ破損の脆弱性は同一アカウント内での権限昇格だけでなく、横移動にも応用可能となる。

メタデータ破損をpaged pool overflowsに変える

大きなレジストリ値は _CM_BIG_DATA レコードに格納される：

  • _CM_KEY_VALUE.DataLength は論理サイズを保持する。上位ビットはペイロードがセル内に格納されているか、big-dataストレージにあるかを示す。
  • _CM_BIG_DATA.Count はチャンクテーブルで参照される 16 KiB チャンク（メタデータを除く16384バイト）を数える。

任意のコンポーネントが CmpGetValueData を呼ぶと：

  1. カーネルは DataLength に基づいて厳密なサイズの paged pool buffer を割り当てる。
  2. ハイブストレージから Count * 0x4000 バイトをそのバッファにコピーする。

もしセルを改ざんして DataLength < 16344 * (Count - 1) を満たせば、コピーは隣接する paged-pool オブジェクトへと直線的に宛先を超えて書き込む。信頼性の高いエクスプロイトチェーンは次の通り：

  1. 決定論的なグルーミングを用いて、脆弱な _CM_KEY_VALUE を制御可能なメタデータの近くに配置する。
  2. _CM_BIG_DATA.Count をそのままにして DataLength を小さな値（例: 0x100）に書き換える。
  3. ユーザーモードからプールグルーミング（pipes、ALPC ports、section objects）を行い、選んだオブジェクト（例えば EPROCESS->Token のオーナーや SRVNET_BUFFER）がステップ1の割り当ての次のチャンクを占めるようにする。
  4. 読み取りをトリガー（例: RegQueryValueEx, NtQueryValueKey）して CmpGetValueData に全チャンクをコピーさせ、ハイブ由来の攻撃者制御データで隣接オブジェクトのフィールドを上書きさせる。
  5. 破損させたカーネルオブジェクトを使って任意の読み書きへピボットするか、直接SYSTEMトークンを盗む。

オーバーフロー長は (Count * 0x4000) - DataLength に等しいため、正確なバイト予算を得られ、書き込まれるバイトを完全に制御できる。これにより多くのドライバベースのプールオーバーフローより優位となる。

密にパックされた HBIN を介したハイブ間線形オーバーフロー

Registry プロセスによってマウントされたハイブは 2 MiB アラインされたビュー としてマップされ、ガードギャップはない。異なる2つのハイブをロックステップで成長させ、その _HBIN 範囲が接するまで強制することができる：

  1. 攻撃者が書き込み可能なハイブ（app hive または user hive）と特権ターゲット（例: HKLM\SOFTWARE）を選ぶ。
  2. 両ハイブで 0x3FD8 バイトの値を継続的に作成/削除する。各割り当ては 0x4000 バイトのビンを追加するため、両方のライターを並列で動かすと仮想メモリ上でビンが交互に並ぶ（!process Registry + !vad で観察可能）。
  3. 攻撃者ハイブの最終ビンが HKLM の HBIN の直前に位置したら、ハイブ破損バグを使って攻撃者ハイブからオーバーフローさせ、HKLM 内の HBIN ヘッダやセルを破壊する。
  4. HKLM のメタデータを制御下に置ければ、次のことが可能：
    • 特権ハイブ内に直接 big-data の不整合プリミティブを仕込む。
    • SYSTEM サービスがカーネル外に出す前に消費する設定データを破壊する。

ガードページが存在しないため、非特権ハイブからの線形上書きは SYSTEM 所有のハイブ構造を直接破壊 でき、データのみの攻撃を可能にしたり、前述のプールオーバーフローを HKLM/HKU 内で仕込むことができる。

運用上のヒント

  • !vad（ユーザーモード）や !reg view / !pool（カーネル）でハイブの配置を監視し、オーバーフローを発動する前に隣接を確認する。
  • 列挙中に見つけた書き込み可能な HKLM パスをキャッシュしておき、再起動後でも迅速に破壊プリミティブを展開できるようにする。
  • ハイブグルーミングを標準的なプールのフェンシュー（pipe pair freelists、Registry プロセスでの NtAllocateVirtualMemory）と組み合わせて、オーバーフロー後のプリミティブを安定させる。

References

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする