wack0/bitlocker-attacksBitLocker에 대한 공개 공격 목록
TPM에만 VMK가 봉인(seal)된 BitLocker에 대한 공개 공격 목록입니다. 정확한 방법이 아직 공개되지 않은 공개 공격(예: baton drop)은 범위에서 제외됩니다.
대부분의 공격은 VMK가 TPM에만 봉인되는 경우를 대상으로 합니다. 이는 기본 설정이며, 자동 BitLocker가 Microsoft 계정에 복구 키를 에스크로(escrow)하는 것과 함께 사용하는 방식입니다.
기본적으로 Windows 8부터 Secure Boot가 활성화된 경우 Secure Boot 무결성 검증이 사용됩니다.
VMK를 TPM에만 봉인해야 한다면, 가장 안전한 구성은 PCR 0, 2, 4, 7, 11과 함께 레거시 무결성 검증을 사용하는 것입니다(그리고 시스템을 완전히 최신 상태로 유지하는 것도 중요합니다).
이것은 소프트웨어 공격으로부터만 보호한다는 점에 유의하십시오.
하드웨어 공격은 일반적으로 공격자가 VMK가 TPM에만 봉인된 시스템에 물리적으로 접근할 수 있을 때만 유용합니다.
| 요약 | 설명 | 수정 | 공개 공개 시점 | 발견자 |
|---|---|---|---|---|
| TPM 스니핑: bootmgr가 TPM과 평문으로 통신 | Windows Boot Manager가 TPM과 평문으로 통신하므로, LPC 버스의 별도 TPM 칩(즉, fTPM 또는 "Pluton"/HSP가 아닌 경우)을 사용한다면 해당 버스의 로직 애널라이저로 VMK를 덤프할 수 있습니다. 참고: Pulse Security 블로그 게시물, LPC 스니퍼 Verilog 코드. | 없음, 단 펌웨어 TPM은 애초에 취약하지 않음 | 2019년 1월 | marcan |
| 하드웨어 디버거: 일부 시스템은 하드웨어 디버거를 활성화하기 전에 PCR7에 측정(measure)하지 않음 | TCG EFI Platform Specification for TPM (섹션 6.4)에는 다음 내용이 포함되어 있습니다: "플랫폼이 UEFI 환경 이전에 사용될 수 있는 펌웨어 디버거 모드를 제공하거나, 플랫폼이 UEFI 환경용 디버거를 제공하는 경우, 플랫폼은 디버거 사용을 허용하기 전에 EV_EFI_ACTION 이벤트를 PCR[7]로 확장(extend)해야 한다" 일부 시스템은 일부 하드웨어 디버거(예: Intel DCI)를 활성화하기 전에 이 측정을 수행하지 않습니다. 따라서 이러한 취약한 시스템에서는 Secure Boot 우회(물리적 접근이 있다면 Secure Boot가 여전히 활성화된 상태에서 최소 두 가지 방법이 가능함) 또는 하드웨어 공격(SPI 플래시에 직접 쓰기)을 통해 하드웨어 디버거를 활성화할 수 있습니다. 그런 다음 bootmgr!FvebUnsealCallback 내부에 (예를 들어) 중단점을 설정하여 VMK를 덤프할 수 있습니다. 참고: Digital Forensics Research Conference Europe 2023의 이 기사. | 취약한 시스템의 경우 없음. 취약한 시스템의 정확한 목록은 알려져 있지 않음. | 2023년 3월 | 브라질 연방경찰 |
| fTPM 글리칭(glitching): 글리칭을 통한 코드 실행으로 fTPM 상태 전체를 손상 | fTPM을 구현하는 온-SoC 프로세서/마이크로컨트롤러가 부팅 초기에 코드 실행을 얻을 수 있을 정도로 글리칭에 취약한 경우, fTPM 상태 전체가 손상되어 VMK 덤프 등이 가능해집니다. 참고: 연구 논문, AMD PSP용 페이로드 등 | IntelME: 2021년 11월 / Alder Lake AMD: 알 수 없음, 없음? 기타(ARM64, ARMv7 등): 알 수 없음 | 2023년 4월 | Technische Universit ät Berlin - SecT의 Hans Niklas Jacob, Christian Werling, Robert Buhren, Jean-Pierre Seifert |
| 부팅 시 IOMMU 비활성화: 플래시 덤프/재기록으로 UEFI 비휘발성 변수 저장소를 수정하여 부팅 시 IOMMU를 비활성화 | 일부 UEFI 펌웨어는 변수 데이터에 따라 부팅 시 IOMMU를 활성화하지 않습니다. 플래시를 덤프하고 해당 변수를 수정한 후 재기록하면, TPM 비휘발성 상태가 여전히 유효한 상태에서 부팅 시 IOMMU가 비활성화됩니다. 이 시점에서 공격자는 bootmgr가 시작되기 전에 PCI DMA를 사용하여 DMAR ACPI 테이블을 덮어쓴 다음, 안전 모드로 부팅하고 PCI DMA를 다시 사용하여 SYSTEM 셸을 얻을 수 있습니다. 라이팅(writeup) 참조.이것이 어떤 구성 요소에 해당하는지는 알 수 없습니다. 해당 라이팅은 Intel 시스템을 사용하며, 관련 코드는 Intel Firmware Support Package에서 제공됩니다. AMD 버전(AGESA/CBS)도 영향을 받는지는 알 수 없습니다. |
소프트웨어 공격은 일반적으로 bootmgr 또는 다른 부팅 애플리케이션의 취약점으로, 임의 볼륨에 대해 파생된 BitLocker 키가 메모리에 있을 때 악용이 가능합니다.
부팅 애플리케이션 내에서 코드 실행을 얻을 수 있다면, "evil cleaner" 공격자가 파생된 키가 메모리에 있는 상태에서(또는 키를 여전히 파생할 수 있을 때) 실행되는 부트킷을 설치할 수 있으며, 따라서 TPM 대신 또는 TPM에 추가로 암호나 시작 키를 사용하는 시스템을 손상시킬 수 있습니다.
취약한 시스템은 2022년 5월 또는 2022년 6월 업데이트가 설치되어 있지만 이후 업데이트는 설치되지 않은 상태입니다.
연결 옵션 GUID는 해시된 데이터의 일부이므로, 사용된 device 요소는 검증되지 않은 것으로 표시되어야 합니다.
Windows 7 이하에서 사용할 수 있는 요소는 없습니다(사용자 지정 비기본 설정을 사용하는 경우에는 여전히 가능할 수 있지만).
Windows 8 이상에서는 osloader!osdevice가 기본적으로 검증되지 않으므로 사용할 수 있습니다.
이를 악용하는 가장 쉬운 방법은 BCD 원시 장치 편집기인 bcdeditmod를 사용하는 것입니다. BCD 레지스트리 하이브를 수동으로 편집하는 것도 가능합니다(스스로 알아내십시오).
악용 절차:
{default}에서 첫 번째 요소로 osdevice를 복사합니다{default}!osdevice의 연결 옵션 GUID를 첫 번째 device 요소로 설정합니다{first}!osdevice의 연결 옵션 GUID를 두 번째 device 요소로 설정합니다debug)을 설정합니다bootmgfw 바이너리로 대상 장치를 부팅합니다이 취약점은 17년 이상 존재했으며, 도입된 것으로 알려진 최초의 빌드는 2005년 10월의 6.0.5231.2 (winmain_idx03.051004-2120)입니다.
Secure Boot 무결성 검증을 사용하는 경우, 다운그레이드 공격은 이 취약점을 악용하기 위해 여전히 작동합니다.Set up a PXE boot server with a vulnerable bootmgfw.efi (where legacy integrity validation is used, this must be the bootmgfw.efi from the target device) renamed correctly for EFI booting.
For the BCD, set up one default entry where device is the BitLocker encrypted osdevice; path is "\"; and a recovery sequence.
The recovery sequence should point to a single startup entry, where device is boot, path points to an EFI application to run (from the PXE server); and pxesoftreboot is enabled.
When Secure Boot is disabled, that EFI application can just be an application to scan physical memory looking for a BitLocker keytable to dump.
When Secure Boot is enabled, that EFI application can use a known Secure Boot bypass (where physical access is required if needed).
For exploiting a Windows boot application in this way, you will need to replace the BCD with your second one on the PXE server.
This means pressing an arrow key during bootmgr startup to force the boot menu to show; and then replacing the BCD on the PXE server at that point.
악용 과정은 다음과 같습니다:
manage-bde -pause C:를 실행한 다음 manage-bde -protectors -delete C:를 실행합니다.이 시점에서 디스크의 BitLocker 메타데이터에는 평문 VMK가 포함됩니다.
이를 덤프하고 그 VMK를 사용하여 FVEK를 복호화합니다.
복호화된 FVEK는 앞서 만든 디스크 이미지에서 파티션을 복호화하는 데 사용할 수 있습니다.
참고: 저는 Windows 10에서 매우 특정한 상황(복구 키가 없는 TPM 전용 BitLocker)에서만 이 문제를 성공적으로 악용했습니다. 그러나 다른 사람들은 취약한 WinRE가 있는 Windows 11에서 이 문제를 성공적으로 악용했습니다 (Nickel).
제가 아는 한, 이 취약점은 부팅 관리자가 존재한 이래로 존재해 왔습니다 - 2005년 6월의 6.0.5098.0 (winmain_beta1.050628-1740) 에도 이미 있는 것으로 보입니다. 다만 그 이전 버전은 BCD 이전이므로 그렇게 오래된 빌드에서는 악용 방식이 다를 것입니다. 관련 코드는 더 일찍도 존재했던 것으로 보입니다 (램디스크 관련 코드는 2005년 4월 빌드 5048에도 동일하게 보입니다). 그러나 빌드 5098이 어떤 형태로든 BitLocker가 포함된 가장 이른 덤프 빌드입니다.
이를 악용하려면 bitpixie에서처럼 기본 항목과 복구 시퀀스를 설정해야 합니다. 이는 파일이 로드될 때 OS 장치에 대한 키가 파생되도록 하기 위함입니다.
복구 시퀀스에는 램디스크를 설정하기 위한 추가 장치 항목이 있어야 합니다. 이 경우 bcdeditmod를 사용하세요. 여기서 custom:21100000과 같은 사용자 지정 요소를 사용하세요. 여기에 사용할 장치 항목의 예는 !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]]입니다. 여기서 part2 블록 장치를 대상 시스템의 BCD에 있는 것으로 교체해야 합니다.
그런 다음 원하는 방식으로 메모리에서 파일을 덤프할 수 있습니다. 저는 고급 옵션 메뉴를 통해 자체 서명된 mcupdate로 이전 winload를 사용하는 것을 선호하지만, 다른 옵션도 있습니다 (예: PXE 소프트 리부트를 통한 타사 운영 체제; bugcheck나 알려진 취약한 드라이버를 사용하여 WinPE에서 메모리를 덤프하는 것도 가능하지만, winload는 NT 메모리 맵에서 해당 메모리 영역을 사용 가능으로 표시하므로 winload에서 해당 메모리를 불량 등으로 표시하는 다른 설정이 없으면 덮어쓸 수 있습니다).
제가 선호하는 방법의 개념 증명 구현이 이 저장소에 ramleak.zip으로 포함되어 있습니다. 사용 방법은 포함된 readme를 읽으세요.
Maxim Suhanov에게 감사를 전합니다. CrashXTS 분석 글을 읽고 hiberfil.sys를 덤프할 다른 방법을 고안하면서 영감을 받았습니다.
이제 이 버그와 yellowkey에 대한 제 생각을 말씀드리겠습니다:
MSRC에 제출할 때 실제로 문제가 있었던 것은 이번이 처음이었고, 주로 Secure Boot와 관련된 그들의 오해였습니다. 다른 BitLocker 0day가 공개되는 상황을 고려하여 지금 이걸 공개하기로 결정했습니다. 저는 거의 1년 동안 이걸 어떻게 할지 고민하며 보류해 왔습니다.
yellowkey와 달리, 저는 이것이 "백도어"라는 과장된 주장을 하지 않겠습니다. 제 생각에 yellowkey는 백도어가 아닙니다. 관련 구성 요소는 WinPE(특히 WinRE 전용이 아님)와 관련이 있고, 거기서 주요 "취약점"은 해당 코드 경로에 도달하기 위해 winpeshl.ini를 삭제하는 것입니다. MS가 WinRE + BitLocker 시나리오에서 그 파일을 삭제하는 것이 불가능하다고 생각한 이유를 충분히 이해할 수 있습니다.
BitLocker로 암호화된 파티션에서 램디스크를 로드하는 것이 실제로 부팅 환경의 기능이라는 점을 고려하면, 실제로 작동시키기 위해 기존 트릭을 사용해야 했지만, 다른 사람들이 원한다면 이것도 백도어라고 말할 수 있을 것입니다. 그러나 저는 그렇게까지 말하지 않겠습니다. 부팅 환경은 복잡하며 (계속 커지고 있습니다. 최신 bootmgfw_ex.efi는 더 이상 2.88MB 이미지에 맞지 않습니다 - 한 시대의 끝), 특정 기능들이 서로 상호작용하는 방식 때문에 여러 취약점이 발견되었습니다.
| Intel Firmware Support Package: 알 수 없음 AMD AGESA/CBS: 알 수 없음 |
| 2026년 3월 |
| MDSec의 Craig S. Blackie |
| 요약 | 설명 | 수정 | 공개 공개 시점 | 발견자 |
|---|
| 부팅 환경이 새 키 테이블을 생성할 때 이전 키 테이블을 지우지 않음 | 부팅 라이브러리 초기화 함수에 플래그 집합이 전달됩니다. 비트 7이 설정된 경우(최소한 bootmgr의 경우 그렇습니다), 기존 키 테이블은 무시되고 새 키 테이블이 생성됩니다. 기존 키 테이블은 지워지지 않고 메모리에 남아 있습니다. 이를 통해 공격자는 임의의 osdevice로 bootmgr를 로드한 다음, bootmgr를 악용하여 코드 실행을 얻거나, RS2+ bootmgr를 사용하여(단 하나의 Secure Boot Policy만 존재하도록) WinPE를 로드하고 알려진 취약 드라이버를 사용하여 키 테이블을 찾아 덤프할 수 있습니다.레거시 무결성 검증을 사용하면 BitLocker 파티션 메타데이터의 부팅 애플리케이션 허용 목록으로 인해 이 공격이 작동하지 않습니다. | 2022년 1월에 완화됨(대부분의 경우 bootmgr 로딩을 차단). 2023년 3월 빌드 25330에서 수정됨(새 키 테이블을 생성하기 전에 기존 키 테이블을 매핑하고 지움). 다운그레이드 공격은 이 취약점을 악용하기 위해 여전히 작동합니다. | 2022년 8월(baton drop 포함); 2022년 1월에 발견됨. | Rairii |
| 레거시 무결성 검증이 연결(associated) 옵션을 잘못 구현 | 레거시 무결성 검증 영향(취약한 bootmgr 사용 시), Secure Boot 무결성 검증은 전혀 영향 없음 BitLocker 레거시 무결성 검증은 모든 부팅 옵션을 순회하며, 옵션이 존재하는지 확인하거나, 알 수 없는 옵션이 존재하지 않는지 확인하거나, 해싱하여 변경되지 않았는지 확인합니다. 원래 구현은 연결 옵션도 순회하려고 시도했지만, 이를 수행하는 데 잘못된 오프셋을 사용했습니다. 이로 인해 BitLocker 레거시 무결성 검증에 보이지 않는 부팅 옵션이 포함된 BCD를 제작할 수 있었습니다. 여기에는 특히 debug와 같은 많은 위험한 옵션이 있으며, BitLocker 키 테이블 덤프로 이어질 수 있습니다.연결 옵션을 순회할 때 올바른 오프셋을 사용하여 수정되었습니다. 이 버그는 CVE-2022-29127입니다. | 2022년 5월 | 2022년 6월(emfcamp에서, bindiffing 덕분에) | Microsoft (WDG)의 Matt Wesemann |
| dangerous association: 레거시 무결성 검증이 연결 옵션을 잘못 구현(2부) | 레거시 무결성 검증 영향(취약한 bootmgr 사용 시), Secure Boot 무결성 검증은 전혀 영향 없음 이전 취약점에 대한 수정은 잘못되었으며 연결 옵션의 한 수준만 확인했지만, 부팅 옵션을 사용하는 코드는 재귀적으로 처리했습니다. 이로 인해 BitLocker 레거시 무결성 검증에 보이지 않는 부팅 옵션이 포함된 BCD를 제작할 수 있었습니다. 참고: 공개 공개. 다른 코드처럼 연결 옵션으로 재귀하여 수정되었습니다. 이 버그는 CVE-2022-22048입니다. | 2022년 7월 | 2022년 12월; 2022년 5월 이전 패치를 bindiffing할 때 발견됨 | Rairii |
| bitpixie: PXE 소프트 리부트가 메모리에서 파생된 BitLocker 키를 지우지 않음 | UEFI 시스템에서만 악용 가능(레거시 BIOS 또는 CSM에서는 불가). 레거시 무결성 검증 영향(취약한 bootmgr 사용 시), Secure Boot 무결성 검증 영향 PXE 소프트 리부트는 네트워크 부팅 시 허용되며, 단순히 BS->LoadImage()와 BS->StartImage()를 수행합니다.파생된 BitLocker 키는 BS->StartImage가 호출되는 시점에 여전히 메모리에 있습니다.그런 다음 메모리에서 덤프할 수 있습니다. 추가로: BitLocker 키는 부팅 애플리케이션 로딩 초기에 파생됩니다. 디스크에서 PE 로딩에 실패하면 무결성 검증이 수행되지 않으며 파생된 키가 메모리에 남습니다. 그런 다음 PXE 소프트 리부트를 수행할 수 있으므로 레거시 무결성 검증도 우회됩니다. 참고: 공개 공개. bootmgr!PxeSoftReboot를 호출하기 전에 bootmgr!BlNetSoftReboot에서 BitLocker 키 테이블을 지워서 수정되었습니다. 이 버그는 CVE-2023-21563입니다. | 2022년 11월(빌드 25236); 2023년 1월(백포트) Secure Boot 무결성 검증을 사용하는 경우, 다운그레이드 공격은 이 취약점을 악용하기 위해 여전히 작동합니다. | 2023년 2월, 2022년 8월에 발견됨 | Rairii |
| push button decrypt: WinRE의 리셋이 복호화 중에 중단될 수 있어 공격자가 셸을 얻어 키 보호기를 비활성화할 수 있음 | Windows Server는 리셋 기능을 지원하지 않으므로 취약하지 않음. 레거시 무결성 검증 및 Secure Boot 무결성 검증 모두 영향(취약한 winre 이미지 사용 시) 시스템의 WinRE로 부팅하면 연결된 osvolume에 대한 키가 파생됩니다. 이 키는 push button reset(데이터 제거 포함)을 수행할 때 메모리에 남아 있도록 허용됩니다. "내 파일만 제거" 리셋을 시작하면 약 98% 완료 시점에 드라이브 복호화가 시작됩니다. 이 시점에 재부팅하면 winre로 재부팅되어 오류와 재부팅 버튼이 표시됩니다. 재부팅 후 Windows 설치 프로그램이 업그레이드 화면으로 시작됩니다. 여기서 Shift+F10으로 셸을 얻을 수 있습니다.여기서 셸만 있으면 복호화를 일시 중지하고 모든 키 보호기를 제거할 수 있으며, 평문 VMK를 사용하여 FVEK를 복호화할 수 있고, 이 FVEK를 이전에 만든 디스크 이미지와 함께 사용할 수 있습니다. 리셋 전에 BitLocker 복구 키를 요구하도록 수정되었습니다. 이 버그는 CVE-2022-41099입니다. | 2022년 11월(winre 이미지를 수동으로 패치해야 함) | 2023년 5월 | 알 수 없음 |
| dubious disk: 부팅 환경 컨텍스트에서의 임의 코드 실행 | 이 버그 또는 그 변종의 악용은 부팅 환경 컨텍스트에서 임의 코드 실행을 달성하므로, BitLocker 키 파생(bootmgr에서의 임의 코드 실행 사용) 또는 BitLocker 키 테이블 덤프(다른 부팅 애플리케이션에서의 임의 코드 실행 사용)가 가능합니다. 이 버그와 그 변종은 CVE-2022-30203, CVE-2023-21560, CVE-2023-28269, CVE-2023-28249, (알 수 없음), CVE-2024-38065입니다. | 2022년 7월에서 2024년 7월 사이에 다양한 수정. 다운그레이드 공격은 이러한 취약점을 악용하기 위해 여전히 작동합니다. | 2024년 6월(공개 라이팅, 2024년 7월에 수정된 변종 누락); 원래 2021년 8월에 발견되어 2022년 1월~3월 사이에 악용됨 | Rairii |
| CrashXTS: 암호화 공격, SYSTEM 하이브의 정밀 손상을 가능하게 하여 하이버파일이 평문으로 기록됨 | BitLocker는 AES-XTS를 사용합니다. 암호화된 파티션의 여러 이미지를 촬영하면 SYSTEM 하이브의 오프셋을 찾을 수 있으며, 따라서 SYSTEM\ControlSet001\Control\CrashControl 키의 오프셋도 찾을 수 있고, 하이버파일을 디스크에 기록할 때 암호화하는 필터 드라이버가 로드되지 않도록 하이브를 손상시킬 수 있습니다. 따라서 시스템을 하이버네이트하고 파티션을 다시 덤프하면 볼륨 키를 포함한 전체 평문(압축된) RAM 덤프를 얻을 수 있습니다.참고: 공개 라이팅. 해당 필터 드라이버가 필요할 때 로드되지 않으면 버그체크를 발생시키도록 수정되었습니다. 이 버그는 CVE-2025-21210입니다. | 2025년 1월 | 2025년 1월 | Maxim Suhanov |
| break out in hives: systemdatadevice 요소로 인해 winload가 공격자가 지정한 SYSTEM 하이브를 사용함 | Windows 10(th1)부터 systemdatadevice 요소에 대한 지원이 winload에 추가되었습니다. 이 요소가 있으면 winload는 osdevice 대신 이 장치에서 SYSTEM 하이브를 읽습니다.따라서 공격자는 WinPE에서 SYSTEM 하이브를 가져와 Setup!CmdLine을 cmd.exe로 수정하고, WinRE 부팅 시 winload가 이 하이브를 사용하도록 할 수 있습니다. 이후 WinRE로 부팅하면 키가 파생된 경우 osvolume에 대한 BitLocker 키가 메모리에 있는 상태로 SYSTEM 셸이 열립니다. 따라서 BitLocker 우회가 가능합니다. systemdatadevice에서 SYSTEM 하이브를 로드하는 기능을 제거하여 수정되었습니다. 이 버그는 CVE-2024-20666입니다. | 2024년 1월(winre 이미지를 수동으로 패치해야 함) | 2025년 2월; 2023년 3월에 발견됨 | Rairii |
| break out in hives 2: systemdatadevice 요소를 악용하는 대체 방법, 다운그레이드 공격과 함께 사용 가능 | break out in hives에 대한 수정은 winload를 업데이트했습니다. 그러나 이전(수정되지 않은) winload 버전은 해당 주 버전의 Windows를 부팅하기 위해 잠재적으로 계속 실행될 수 있습니다(모든 버전에서 실제로 작동하지 않을 수 있음). 따라서 공격자는 이전 winload를 가져와 BCD를 수정하여 그 winload로 부팅하고 공격을 반복할 수 있지만, 다른 악용 방법을 사용해야 합니다. BCD에 winpe 요소가 설정되어 있어야 합니다(설정되지 않은 경우 BitLocker로 암호화된 osvolume의 SYSTEM 하이브가 손상됩니다!)여기서 작동하는 SYSTEM 하이브는 동일한 주 버전 Windows의 install.wim 이미지에서 가져와야 합니다(WinPE/WinRE 아님). Win32 하위 시스템이 완전히 초기화되지 않을 수 있지만, ControlSet001\Control\Session Manager!SetupExecute에서 smss를 구성하여 파생된 키가 메모리에 있는 상태에서 SYSTEM 권한의 임의 네이티브 하위 시스템 코드 실행을 달성할 수 있습니다.Secure Boot가 활성화된 경우 bootmgr에서 systemdatadevice 요소를 지워서 수정되었지만, 이 수정은 PCA 2023 서명 bootmgr_ex에만 적용되었으므로 KB5025885 완화가 활성화되지 않은 경우 이 취약점은 여전히 존재하며 수정되지 않은 상태로 남아 있습니다. 이 버그는 CVE-2025-21213입니다. | 2025년 1월, PCA2023 서명 bootmgr_ex에만 적용 | 2025년 2월; 2024년 1월(원래 수정 이후)에 발견됨 | Rairii |
| 부팅 환경이 ramdisk 로드 시 SDI를 확인하지 않음, SDI에 사용된 WIM에 대한 오프셋이 있음 | ramdisk를 로드할 때 부팅 환경(및 NT wimfsf.sys)은 SDI 파일이 있는 경우 SDI 파일에서 사용된 WIM의 오프셋을 가져오며, 사용된 SDI 파일에 대한 검증이 없습니다. 따라서 제작된(crafted) SDI 파일을 복구 시퀀스에서 사용하여 osdevice BitLocker 키가 파생된 상태로 임의의 WinPE WIM을 부팅할 수 있습니다.계산된 WIM 오프셋이 WIM의 실제 로드 오프셋과 같은지 확인하고, 다르면 STATUS_INVALID_IMAGE_FORMAT을 반환하도록 수정되었습니다. 이 버그는 CVE-2025-48804입니다. | 2025년 7월 | 2025년 8월(Black Hat에서) | Microsoft (MORSE)의 Alon Leviev 및 Netanel Ben Simon |
YellowKey 일명 trans writes (미러, 비밀번호: bitlocker): 한 볼륨에 위치한 파일 시스템 트랜잭션 파일이 다른 볼륨의 파일에 영향을 줄 수 있음 | Germanium은 새로운 파일 시스템 트랜잭션 기능을 도입했습니다(NTFS 트랜잭션과 무관). 이에 대한 로그는 디스크에 있으며 fstx.dll(서비스 스택의 일부)이 파싱하고, WinPE에서만 새 네이티브 실행 파일 autofstx.exe("Boot-time FsTx Update Recovery Utility" - "부팅 시 실패한 FsTx 업데이트를 복구하는 유틸리티")가 로드하며, smss가 레지스트리 항목으로 인해 이를 실행합니다.이 로그에는 전체 NT 경로가 포함되어 있으므로 다른 볼륨의 파일에 영향을 줄 수 있습니다. 이것은 NTFS로 포맷된 이동식 드라이브를 연결한 상태로 WinRE를 부팅할 때 ramdisk에서 winpeshl.ini를 삭제하는 데 사용할 수 있습니다. 이 파일이 삭제되면 winpeshl.exe는 Ctrl 키를 누르고 있으면 파생된 osdevice BitLocker 키가 메모리에 있는 상태로 SYSTEM 셸을 시작합니다.참고: Will Dormann의 추가 라이팅. 이 버그는 CVE-2026-45585입니다. | 2026년 6월 | 2026년 5월 | Nightmare-Eclipse |
| ram leak: 부팅 환경에 ramdisk 생성 장치에 대한 제한이 없음 | ramdisk를 생성하도록 구성된 경우, 로드할 파일과 로드할 장치는 BCD에서 제공됩니다. 부팅 환경은 전달된 장치에 대한 검사가 없으므로, 키를 파생할 수 있다는 가정 하에 BitLocker로 암호화된 파티션이 허용됩니다. 따라서 공격자는 BitLocker로 암호화된 파티션의 임의 파일로 ramdisk를 설정할 수 있으며, 파생된 BitLocker 키가 지워진 후에도 파일 내용이 RAM에 남아 나중에 덤프할 수 있습니다. 추가로, 공격자는 이를 사용하여 BitLocker로 암호화된 OS 파티션에 파일이 존재하는지 여부를 확인할 수 있습니다. 흥미로운 대상에는 다음이 포함됩니다: 하이버네이션 파일(파생된 BitLocker 키를 포함하며 압축되어 있어 RAM에 완전히 들어맞아야 함, 특히 로그온 화면에서 "종료" 즉 로그오프 후 하이버네이트하는 경우), 페이지파일, SYSTEM 및 SAM 하이브, 취약점을 확인하기 위한 타사 서비스 또는 드라이버(SYSTEM 하이브에서 식별). | 없음. MSRC가 오해로 인해 낮은 우선순위로 종결. | 2026년 5월, 원래 2025년 3월에 발견됨. | Rairii |
| bitskrieg: WinRE 부팅이 Emergency Management Services를 금지하지 않음 | Emergency Management Services를 사용하면 Special Administration Console을 통해 직렬 포트에서 실행 중인 Windows 시스템을 제어할 수 있으며, 여기에는 SYSTEM 셸을 실행하는 기능도 포함됩니다. 이는 WinRE에서 허용되므로, 파생된 osdevice BitLocker 키가 메모리에 있는 상태로 SYSTEM 셸을 여는 데 사용할 수 있습니다. | 없음, 0day로 기각됨. | 2026년 6월 | Jonas Lyk |