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 접근으로 privileged hives에 액세스

Windows는 레지스트리 경로의 마지막 구성 요소에 대한 **ACL on the final component**만 평가한다. HKLM/HKU 아래의 어떤 하위 항목이든 `KEY_SET_VALUE`, `KEY_CREATE_SUB_KEY`, 또는 `WRITE_DAC`를 저권한 사용자에게 부여하면, 상위 키들이 모두 잠겨 있어도 해당 하위 항목에 접근할 수 있다. Project Zero는 **>1000 such writable keys in HKLM on Windows 11**를 발견했으며, 여기에는 `HKLM\SOFTWARE\Microsoft\DRM` 같은 장기 항목과 여러 `HKLM\SYSTEM` 분기가 포함된다.

Practical enumeration strategy:

1. 권한 상승된 컨텍스트에서 `\Registry\Machine`과 `\Registry\User`를 순회하며 각 키의 security descriptor를 덤프한다. DACL이 unprivileged SIDs를 허용하는 항목을 저장한다.
2. 일반 사용자로서 기록한 경로에 대해 `RegOpenKeyEx`를 `KEY_SET_VALUE|KEY_CREATE_SUB_KEY` 권한으로 시도한다. 성공적으로 열린 키는 시스템 hives에 attacker-controlled data를 필요로 하는 hive corruption bugs의 유효한 타깃이다.
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 {}
}

일단 그러한 경로를 알게 되면, 익스플로잇은 오프라인에서 하이브를 조작할 필요가 없으며—표준 레지스트리 APIs만으로도 SYSTEM 서비스가 접근하는 권한 있는 하이브 안에 손상된 셀을 배치할 수 있다.

HKCU\Software\Microsoft\Input\TypingInsights를 통한 교차 사용자 하이브 악용

모든 사용자 하이브에는 HKCU\Software\Microsoft\Input\TypingInsights가 들어 있으며, 해당 ACL은 KEY_ALL_ACCESS를 Everyone (S-1-1-0). 에게 부여한다. Microsoft가 이를 강화할 때까지, 모든 사용자는 다음을 수행할 수 있다:

• 다른 사용자의 하이브를 2 GiB 한도까지 채워 로그온 실패를 유발하거나 하이브 절단을 강제할 수 있다(allocator 동작을 유도하거나 DoS에 유용).
• 다른 사용자의 NTUSER.DAT에 손상된 셀을 삽입해 피해자 프로세스가 손상된 키를 읽을 때 트리거되는 측면 이동 익스플로잇을 준비할 수 있다.
• 사용자별 오버레이 하이브에 의존하는 샌드박스 앱의 differencing hives를 수정해 악성 메타데이터를 사용하도록 강제할 수 있다.

이로 인해 하이브 손상 취약점은 동일 계정 내 권한 상승뿐 아니라 lateral movement에도 적용될 수 있다.

메타데이터 손상을 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 객체로 선형적으로 목적지를 초과(overrun) 한다. 신뢰할 수 있는 익스플로잇 체인은 다음과 같다:

1. 결정론적 groom을 사용해 취약한 _CM_KEY_VALUE를 제어 가능한 메타데이터 근처에 배치한다.
2. _CM_BIG_DATA.Count는 그대로 둔 채 DataLength를 작은 값(예: 0x100)으로 변경한다.
3. 파이프, ALPC 포트, section 객체 등 사용자 모드에서 pool-groom을 수행해 선택한 객체(예: EPROCESS->Token 소유자 또는 SRVNET_BUFFER)가 1단계에서 할당된 다음 청크를 차지하도록 한다.
4. 읽기 트리거(예: RegQueryValueEx, NtQueryValueKey)를 유발해 CmpGetValueData가 모든 청크를 복사하도록 하고 하이브의 공격자 제어 데이터로 이웃의 필드를 덮어쓰기(overwrite) 한다.
5. 손상된 커널 객체를 이용해 임의 읽기/쓰기 권한으로 피벗하거나 직접 SYSTEM 토큰을 탈취한다.

오버플로우 길이가 (Count * 0x4000) - DataLength와 같기 때문에, **정확한 바이트 예산(precise byte budget)**과 기록되는 바이트에 대한 완전한 제어를 확보할 수 있어 많은 드라이버 기반 풀 오버플로우보다 우수하다.

빽빽하게 패킹된 HBIN을 통한 인터-하이브 선형 오버플로우

Registry 프로세스에 의해 마운트된 하이브는 2 MiB-aligned views로 매핑되며 **가드 갭(guard gaps)**이 없다. 두 개의 서로 다른 하이브를 동시에 성장시켜 그들의 _HBIN 범위가 맞닿을 때까지 강제할 수 있다:

1. 공격자가 쓸 수 있는 하이브(앱 하이브 또는 사용자 하이브)와 권한 있는 대상(예: HKLM\SOFTWARE)을 선택한다.
2. 두 하이브 모두에서 0x3FD8-바이트 값을 지속적으로 생성/삭제한다. 각 할당은 0x4000-바이트 bin을 추가하므로, 두 작성기를 병렬로 실행하면 가상 메모리에서 그들의 bin이 교차(interleave)하게 된다( !process Registry + !vad로 관찰 가능).
3. 공격자 하이브의 마지막 bin이 HKLM에 속한 HBIN 바로 앞에 위치하게 되면, 하이브 손상 버그를 이용해 공격자 하이브를 넘쳐(overflow out of the attacker hive) HKLM 내부의 HBIN 헤더나 셀을 파괴한다.
4. HKLM 메타데이터를 제어하게 되면 다음을 할 수 있다:

• 권한 있는 하이브에 직접 big-data 불일치 원시(primitive)를 준비한다.
• 커널을 벗어나기 전에 SYSTEM 서비스가 소비하는 구성 데이터를 손상시킨다.

가드 페이지가 없기 때문에 권한 없는 하이브에서의 선형 덮어쓰기는 직접적으로 SYSTEM 소유의 하이브 구조를 손상시킬 수 있으며, 이는 데이터 전용 공격을 가능하게 하거나 위에서 설명한 pool overflow를 HKLM/HKU 내부에 설정할 수 있게 한다.

운영 팁

• 오버플로우를 트리거하기 전에 인접성을 확인하기 위해 !vad(유저 모드)와 !reg view / !pool(커널)을 사용해 하이브 배치를 모니터링한다.
• 열거 중 발견한 쓰기 가능한 HKLM 경로를 캐시해 재부팅 후에도 손상 프리미티브를 빠르게 배치할 수 있도록 한다.
• hive grooming을 표준 pool feng shui(파이프 페어 freelists, NtAllocateVirtualMemory on Registry process)와 결합해 오버플로우 이후의 프리미티브를 안정화한다.

References

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

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 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.