# 보안 연구자가 Microsoft가 BitLocker 백도어를 만들었다고 말하며 익스플로잇 공개

> Clean Markdown view of GeekNews topic #29609. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=29609](https://news.hada.io/topic?id=29609)
- GeekNews Markdown: [https://news.hada.io/topic/29609.md](https://news.hada.io/topic/29609.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-18T09:55:25+09:00
- Updated: 2026-05-18T09:55:25+09:00
- Original source: [techspot.com](https://www.techspot.com/news/112410-security-researcher-microsoft-secretly-built-backdoor-bitlocker-releases.html)
- Points: 2
- Comments: 1

## Topic Body

- 보안 연구자 **Nightmare-Eclipse**가 YellowKey를 공개하며 BitLocker 전체 볼륨 암호화를 암호 없이 우회할 수 있다고 밝힘
- **YellowKey**는 FsTx 폴더를 Windows 호환 파일 시스템의 USB 드라이브에 복사한 뒤 WinRE에서 특정 순서를 거치면 재현 가능함
- 절차가 완료되면 **명령 셸**이 열리고 BitLocker 보호 볼륨 탐색, 복사, 파일 작업이 가능하다고 전해짐
- Nightmare-Eclipse는 우회 동작이 **공식 WinRE 이미지**에서만 나타난다며 의도적 백도어 가능성을 제기함
- 영향 대상은 **Windows 11, Server 2022, Server 2025**로 제시됐고 Windows 10은 영향받지 않는다고 덧붙임

---

### YellowKey의 작동 조건
- 보안 연구자 **Nightmare-Eclipse**가 [YellowKey](https://github.com/Nightmare-Eclipse/YellowKey)를 공개하며 BitLocker의 전체 볼륨 암호화를 완전히 우회할 수 있다고 밝힘
- YellowKey는 첨부된 **FsTx 폴더**를 NTFS, FAT32, exFAT 같은 Windows 호환 파일 시스템으로 포맷된 USB 드라이브에 복사해 재현할 수 있음
- USB 드라이브 없이도 FsTx 파일을 **Windows EFI 파티션**에 복사하고 암호화된 디스크를 시스템에서 일시적으로 분리하면 동작할 수 있다고 전해짐
- 이후 BitLocker로 보호된 시스템을 재부팅하고 **Windows Recovery Environment(WinRE)** 로 들어간 뒤 특정 입력 순서를 따라야 함
- 절차가 정확히 완료되면 **명령 셸**이 나타나며, 암호 없이 BitLocker 보호 볼륨을 탐색·복사하거나 기타 파일 작업을 수행할 수 있다고 밝힘

### 백도어 의혹의 근거
- Nightmare-Eclipse는 YellowKey가 이전에 알려지지 않은 보안 버그로 보기에는 비정상적이며, Microsoft가 BitLocker 데이터 보호 시스템에 **정상적인 백도어**를 넣었을 가능성을 제기함
- 근거는 문제를 일으키는 구성요소가 **공식 WinRE 이미지**에서만 발견된다는 점임
- 같은 구성요소가 표준 Windows 설치 이미지에도 존재하지만, 실제 시스템에서 관찰된 BitLocker 우회 동작은 나타나지 않는다고 밝힘
- Nightmare-Eclipse는 “이것이 의도적이었다는 사실 말고는 설명을 떠올릴 수 없다”고 밝혔고, Windows 10은 영향받지 않으며 **Windows 11, Server 2022, Server 2025**만 영향을 받는다고 덧붙임

### 외부 확인과 추가 공개
- 제3자 연구자들이 Nightmare-Eclipse의 GitHub 자료에 적힌 방식대로 YellowKey가 동작한다는 점을 [확인](https://www.xda-developers.com/new-windows-11-bitlocker-bypass-needs-usb-stick-researcher-backdoor/)한 것으로 전해짐
- Nightmare-Eclipse는 권한 상승이 가능하다고 알려진 두 번째 익스플로잇 [GreenPlasma](https://github.com/Nightmare-Eclipse/GreenPlasma)도 공개함
- GreenPlasma는 **SYSTEM 수준 접근**을 달성하는 전체 개념증명 코드를 공개하지 않았고, 다음 달 Patch Tuesday 전에 추가 세부사항을 공개할 수 있다고 시사함

### 완화 방향
- YellowKey의 백도어성 동작 의혹에 대한 완화는 비교적 단순하다고 제시됨
- 보안 전문가들은 단일 암호화 시스템에만 의존하지 말고, 잘 검토된 **전체 디스크 암호화** 대안도 평가하라고 권장함
- 예시로 [VeraCrypt](https://www.techspot.com/downloads/6578-veracrypt.html)가 제시됨

## Comments



### Comment 57663

- Author: neo
- Created: 2026-05-18T09:55:25+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48168856) 
- 이 취약점을 발견한 연구자 **Nightmare-Eclipse**의 글을 보면 거의 일주일 전부터 이어진 것으로 보임  
  2026년 5월 12일 화요일에는 “이번엔 취약점이 두 개다 [YellowKey] [GreenPlasma] [...] 다음 패치 화요일엔 Microsoft에게 큰 놀라움이 있을 것”이라고 했고, 5월 13일 수요일에는 “전체 사연을 공개할 수 있게 되면 사람들이 내 폭발이 꽤 합리적이었다고 볼 것이고, Microsoft에게도 절대 좋아 보이지 않을 것”이라고 씀  
  작성자 블로그: [https://deadeclipse666.blogspot.com/](<https://deadeclipse666.blogspot.com/>)  
  2026년 3월 첫 글에는 “누군가 우리 합의를 어겼고, 나는 빈털터리로 집도 잃었다. 그들은 이렇게 될 걸 알면서도 내 등을 찔렀다. 이건 내 결정이 아니라 그들의 결정이다”라는 식의 내용이 있음  
  이걸 어떻게 봐야 할지 모르겠지만, 내부자가 사실상 “유출”하는 것처럼 들리기도 하고, 다른 사람들도 결과를 재현할 수 있는 듯함
  - 내부자라기보다는 Microsoft와 **취약점 공개 절차**를 진행하던 중 어떤 이유로 화가 나서 공개해 버린 것으로 읽힘
  - HN에서 이미 여러 번 논의됐고, 예를 들면 여기 있음: [https://news.ycombinator.com/item?id=48130519](<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$를 폭로**하게 됐는지 블로그 글을 빨리 읽고 싶음

- 더 나은 정리: [https://infosec.exchange/@wdormann/116565129854382214](<https://infosec.exchange/@wdormann/116565129854382214>)  
  공개된 익스플로잇은 **PIN을 쓰는 BitLocker**에는 영향을 주지 않음. PIN이 없으면 BitLocker는 어차피 안전하지 않음  
  원 작성자는 PIN이 있어도 동작하는 익스플로잇을 갖고 있다고 주장하지만, 아직 그 증거는 내놓지 않았음
  - 회사에서 PIN을 요구하나? 더 중요하게는 회사가 돈 내는 **사이버 보험사**가 PIN을 요구하나?  
    BitLocker에 PIN을 요구하는 회사를 본 적이 없음
  - BitLocker에는 PIN보다 한 단계 위도 있어서, 부팅할 때만 쓰는 키가 들어 있는 **USB 스틱**을 둘 수 있음. 데이터가 장치에 저장되지 않으니 이 공격에는 안전할 것 같음
  - PIN 버전 주장이 사실이라고 가정하면, 왜 PIN 버전 대신 약화된 쓸모없는 버전을 공개했는지 흥미로움. 몇 가지 생각은 있지만 전부 근거는 없음

- 출처: [https://infosec.exchange/@wdormann/116565129854382214](<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+암호문을 조합한 슬롯을 쓰고, 백업 암호문 슬롯을 하나 더 두는 하이브리드라면 괜찮을 수도 있음
  - TPM+PIN 익스플로잇도 있다고 주장하긴 하지만, 신뢰할 만한지는 아직 봐야 함  
    [https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...](<https://deadeclipse666.blogspot.com/2026/05/were-doing-silent-patches-now-huh-also.html>)
  - Linux LUKS도 정확히 같은 방식으로 설정할 수 있음  
    이건 BitLocker 공격이라기보다 **Secure Boot 체인**에 대한 공격으로 보임  
    PIN 없는 잠금 해제의 가치는 위협 모델이 디스크 폐기, 디스크 분리, TPM과 디스크의 분리 정도로 제한될 때 있음  
    기기를 여러 사용자가 정기적으로 쓴다면 PIN 입력은 불편하거나 불가능할 수 있음. 그래서 접근 검증 제어를 신뢰된 운영체제 구성요소로 넘기는 구조가 됨
  - 매우 심각한 버그이긴 하지만 BitLocker는 전체 디스크 암호화가 맞음. 다만 인증 우회가 가능할 뿐임

- “TrueCrypt 사용은 안전하지 않으며, 수정되지 않은 보안 문제가 있을 수 있다”던 문구 기억나는 사람? ;)
  - TrueCrypt/VeraCrypt가 떠오름. 아마 더 안전한 암호화 해법일 가능성이 큼. 이번 사태 뒤에는 확실히 더 안전해 보임
