이 취약점을 발견한 연구자 Nightmare-Eclipse의 글을 보면 거의 일주일 전부터 이어진 것으로 보임
2026년 5월 12일 화요일에는 “이번엔 취약점이 두 개다 [YellowKey] [GreenPlasma] [...] 다음 패치 화요일엔 Microsoft에게 큰 놀라움이 있을 것”이라고 했고, 5월 13일 수요일에는 “전체 사연을 공개할 수 있게 되면 사람들이 내 폭발이 꽤 합리적이었다고 볼 것이고, Microsoft에게도 절대 좋아 보이지 않을 것”이라고 씀
작성자 블로그: https://deadeclipse666.blogspot.com/
2026년 3월 첫 글에는 “누군가 우리 합의를 어겼고, 나는 빈털터리로 집도 잃었다. 그들은 이렇게 될 걸 알면서도 내 등을 찔렀다. 이건 내 결정이 아니라 그들의 결정이다”라는 식의 내용이 있음
이걸 어떻게 봐야 할지 모르겠지만, 내부자가 사실상 “유출”하는 것처럼 들리기도 하고, 다른 사람들도 결과를 재현할 수 있는 듯함

내부자라기보다는 Microsoft와 취약점 공개 절차를 진행하던 중 어떤 이유로 화가 나서 공개해 버린 것으로 읽힘

HN에서 이미 여러 번 논의됐고, 예를 들면 여기 있음: https://news.ycombinator.com/item?id=48130519
이게 백도어인지 아닌지는 결국 평소에 “버그냐 백도어냐”를 어떻게 보는지에 달렸고, 기술 언론이 좋아하는 식의 “Microsoft면 1, BitLocker 해킹” 같은 단순한 얘기는 아님
핵심은 Windows Recovery Environment WinRE의 NTFS 트랜잭션 로그 재생 기능에 있는 버그로, 외부 볼륨의 NTFS 트랜잭션 로그를 읽어 마운트된 파일시스템에 적용할 수 있게 됨. 이로 인해 공격자가 WinRE 인증을 우회할 수 있음
PIN이나 비밀번호 없는 BitLocker에서는 어떤 인증 우회든 디스크 암호화 우회가 됨. 부트로더가 디스크를 이미 언실링하기 때문이고, 이런 구조적 “결함”은 같은 설정의 Linux에도 있음. 예를 들어 Ubuntu 설치기에서 비교적 최근 추가된 Hardware Disk Encryption 체크박스를 쓰는 경우도 마찬가지임
추가 증거가 없다면 NTFS 트랜잭션 로그 문제가 심어진 백도어인지 단순한 열거 버그인지는 익스플로잇 개발에서 흔한 음모론 수위에 따라 달라짐. 개인적으로는 그럴듯한 버그로 보이고, 부팅 시 언실링의 약점은 잘 알려져 있고 명백해서 이게 세상을 뒤흔들 폭로라고 보진 않지만 재미있는 버그이긴 함

실제로 무슨 일이 있었고 왜 이 사람이 이렇게 M$를 폭로하게 됐는지 블로그 글을 빨리 읽고 싶음

회사에서 PIN을 요구하나? 더 중요하게는 회사가 돈 내는 사이버 보험사가 PIN을 요구하나?
BitLocker에 PIN을 요구하는 회사를 본 적이 없음

BitLocker에는 PIN보다 한 단계 위도 있어서, 부팅할 때만 쓰는 키가 들어 있는 USB 스틱을 둘 수 있음. 데이터가 장치에 저장되지 않으니 이 공격에는 안전할 것 같음

PIN 버전 주장이 사실이라고 가정하면, 왜 PIN 버전 대신 약화된 쓸모없는 버전을 공개했는지 흥미로움. 몇 가지 생각은 있지만 전부 근거는 없음

출처: https://infosec.exchange/@wdormann/116565129854382214
“일반적인 WinRE 세션에는 X:\Windows\System32 디렉터리가 있고 그 안에 winpeshl.ini 파일이 있다”
“하지만 YellowKey 익스플로잇에서는 USB 드라이브의 Transactional NTFS 조각들이 다른 드라이브의 winpeshl.ini 파일을 삭제할 수 있는 것처럼 보인다”
흥미롭다. 이 환경은 잘 모르지만, 순진하게 파일 핸들을 만들거나 넘기는 문제일까? 그렇다면 왜 WinRE 재부팅 중 키 입력이 필요할까?
패치가 얼마나 가능할지도 궁금함. 수많은 WinRE USB 드라이브는 손댈 수 없을 테니, BitLocker 쪽에서 접근 권한을 업데이트할 수 있을까? 암호 해제/재암호화가 필요할까? 앞으로 더 나올 게 많아 보임

빠진 부분은 WinRE가 권한을 갖는 이유임. Windows가 TPM에 복호화 키를 저장해서, 복구 키 없이도 WinRE가 디스크를 복호화할 수 있게 함
그래서 이 공격은 Ubuntu 라이브 CD 같은 걸로 부팅하는 게 아니라 WinRE가 필요함
또한 기존 WinRE USB 드라이브를 전부 패치할 필요는 없음. Secure Boot 서명을 폐기하면 TPM 검증을 통과하지 못하고, 따라서 어떤 디스크도 복호화할 수 없게 됨

“보안 전문가들은 일반적으로 단일 암호화 시스템에 의존하지 말고 VeraCrypt 같은 검토가 잘 된 전체 디스크 암호화 대안을 평가하라고 권한다”
만약 FDE에 백도어를 넣었다면, 사람들에게 Windows 사용 자체를 그만두고 Linux를 쓰라고 하는 편이 더 말이 됨
FDE에 백도어를 넣었다면 운영체제 자체에도 백도어가 하나만 있지는 않을 것이라고 봐야 함. 독점 소프트웨어는 전혀 신뢰하면 안 되고, 제대로 감사되지 않은 오픈소스도 신뢰하면 안 됨

Microsoft 제품은 대체로 안 쓰지만, 당신 컴퓨터라도 VeraCrypt는 돌리지 않겠음

아니면 오픈소스인 VeraCrypt 같은 걸 쓰면 됨

이건 BitLocker 전용 문제라기보다 로그인 우회에 더 가까워 보임. PIN 없이 TPM에 의존하면 자동으로 복호화됨
보통은 공격자가 로그인 화면을 넘지 못해야 하니 괜찮아야 하지만, 이 익스플로잇은 복구 환경에서 제한 없는 셸을 얻는 방법을 보여주는 것으로 보임
연구자는 PIN도 우회하는 방법이 있다고 주장하지만 아직 공개하지 않았음

공개 절차로 보상이 안 나왔으니, 돈을 낼 누군가에게 파는 편이 낫다고 본 것일 수 있음

보안 전문가들이 “Microsoft 제품 보안” 역할을 거절하기 시작하는 시점은 언제일까? 나는 이미 그 지점에 와 있음
Microsoft 제품 보안은 MS의 미친 기술 부채와 탐욕의 다음 물결에 다시 무너질 때까지 하는 바쁜 일에 불과함. 이제는 백도어까지 있음

그건 “보안” 역할이 아니라 컴플라이언스 역할임. 대부분의 기업 고객이 진짜로 신경 쓰는 건 그게 전부임
모든 컴플라이언스 규칙을 만족했고, MS의 영향을 받은 “모범 사례”를 따랐으니, 무슨 일이 생겨도 자기 책임이 아니게 됨

iOS도 기본적으로 종단 간 암호화되지 않은 iCloud 백업을 만들고, 그래서 수사기관이 채팅, 브라우저 기록 등을 요청할 수 있음. Signal은 예외적으로 빠져 있음
종단 간 암호화 백업을 위해 ADP를 켤 수는 있지만, 대화 상대들이 켜지 않았을 가능성이 크므로 별 도움이 안 될 수 있음
Microsoft를 변호하려는 게 아니라, 이런 회사들이 모두 PRISM의 일부였다는 얘기임

기업 시장에서는 이걸로 버는 돈이 너무 많아서, 귀찮다는 이유만으로 사람들이 일을 거절하기 시작할 것 같지는 않음

“이제 백도어까지”라고? “이제”?
과거 Windows NT 한 버전이 실수로 디버그 심벌을 켠 채 출시됐을 때, Microsoft가 “보조 키”라고 주장하던 키 이름이 왜 ..._NSAKEY였는지에 대해 얘기해 볼까
단 한 번, 정말 딱 한 번 Windows가 디버그 심벌을 켠 채 출시됐는데, 하필 암호화 키 이름이 “NSAKEY”였음
물론 국가의 잘못에는 계속 눈감는 사람들은 그게 완전히 정상이라고 하고, 당시 Microsoft가 공들여 만든 “백도어가 아니다”라는 변명을 그대로 반복할 것임

익스플로잇을 조금 더 파보니, 이건 TPM 전용 모드의 BitLocker를 노림. 즉 사전 부팅 인증 같은 게 없음
Secure Boot가 부팅 체인을 검증하면 TPM이 스스로 암호화 키를 내줌. 물리 접근이 있으면 큰 차이가 없음
익스플로잇이 담긴 USB로 부팅해 긴급 셸을 얻든, 5달러짜리 마이크로컨트롤러를 사서 메인보드의 특정 핀에 납땜해 TPM 키를 스니핑하든 가능함
Microsoft는 전반적으로 안전하지 않은 것을 팔면서 전체 디스크 암호화라고 판매하고 있음. 플래시 드라이브에 익스플로잇을 넣고 셸을 얻어 파일을 훑고 복사할 수 있는 사람이라면, 마이크로컨트롤러를 사서 YouTube 납땜 영상을 보며 따라 할 수도 있음
그래서 “익스플로잇” 자체가 문제가 아니라, Microsoft가 파는 가짜 안전감이 문제임

“부팅 가능한 스틱으로 긴급 셸에 들어간다”는 방식은 안 됨. TPM은 “승인된” 운영체제로 부팅할 때만 키를 내주며, 구체적으로는 암호화 키가 바인딩된 PCR 상태가 맞아야 함
5달러짜리 마이크로컨트롤러로 특정 핀에 납땜해 TPM 키를 스니핑하는 건 dTPM에서만 가능함. fTPM은 여기에 취약하지 않고, dTPM보다 훨씬 더 널리 쓰임

Ubuntu도 몇 버전 전에 TPM 기반 FDE를 내놨음. 그때도 같은 생각이 들어서 쓰지 않기로 했음
부팅할 때 암호문을 입력하는 건 이미 근육 기억이고, 신뢰할 수 있는 단순한 보안을 줌
메인보드 없이도 데이터를 복구할 수 있음
일상용으로는 evil maid 공격을 막기 위해 Secure Boot+TPM+암호문을 조합한 슬롯을 쓰고, 백업 암호문 슬롯을 하나 더 두는 하이브리드라면 괜찮을 수도 있음

Linux LUKS도 정확히 같은 방식으로 설정할 수 있음
이건 BitLocker 공격이라기보다 Secure Boot 체인에 대한 공격으로 보임
PIN 없는 잠금 해제의 가치는 위협 모델이 디스크 폐기, 디스크 분리, TPM과 디스크의 분리 정도로 제한될 때 있음
기기를 여러 사용자가 정기적으로 쓴다면 PIN 입력은 불편하거나 불가능할 수 있음. 그래서 접근 검증 제어를 신뢰된 운영체제 구성요소로 넘기는 구조가 됨

매우 심각한 버그이긴 하지만 BitLocker는 전체 디스크 암호화가 맞음. 다만 인증 우회가 가능할 뿐임

“TrueCrypt 사용은 안전하지 않으며, 수정되지 않은 보안 문제가 있을 수 있다”던 문구 기억나는 사람? ;)

TrueCrypt/VeraCrypt가 떠오름. 아마 더 안전한 암호화 해법일 가능성이 큼. 이번 사태 뒤에는 확실히 더 안전해 보임