---
title: "깃허브, 윈도우 제로데이 공개한 보안 연구자 계정 차단"
published: 2026-05-28T21:45:54.000Z
canonical: https://jeff.news/article/3385
---
# 깃허브, 윈도우 제로데이 공개한 보안 연구자 계정 차단

마이크로소프트와 갈등을 겪던 보안 연구자 나이트메어 이클립스의 깃허브 계정이 차단됐고, 연구자는 깃랩으로 옮겨갔다. 연구자는 마이크로소프트가 취약점 제보를 무시하거나 보상하지 않았다고 주장하며 추가 제로데이 공개를 암시했고, 이미 공개된 일부 윈도우 취약점은 실제 공격에 악용 중인 것으로 확인됐다.

- 윈도우 보안 쪽에서 꽤 위험한 드라마가 이어지는 중임
  - 보안 연구자 나이트메어 이클립스가 윈도우 제로데이 익스플로잇을 공개해왔고, 깃허브 계정이 차단됨
  - 연구자는 깃랩으로 옮겼고, 마이크로소프트가 자신을 보복성으로 압박했다고 주장함
  - 기사에 따르면 마이크로소프트는 연구자가 버그를 제보하던 마이크로소프트 계정도 이미 삭제한 것으로 알려짐

- 연구자의 주장은 “제보했지만 제대로 소통도 보상도 못 받았다”에 가까움
  - 글에서는 마이크로소프트가 연락 시도를 거부했고, 자신은 “한 푼도 받지 못했다”고 주장함
  - 이는 마이크로소프트 보안 대응 센터의 버그 바운티 보상을 겨냥한 말로 보임
  - 해당 프로그램은 조건에 따라 엔드포인트 제로데이에 3만~10만 달러, 하이퍼브이 취약점에는 최대 25만 달러를 지급할 수 있음

- 갈등은 4월 초부터 본격화됐다고 함
  - 연구자는 사전 경고 없이 BlueHammer 제로데이를 공개했음
  - 이후 글들에서 마이크로소프트와 보안 대응 센터를 강하게 비난했고, 표현은 꽤 격앙돼 있음
  - 7월 14일에 추가 공개를 암시하는 발언도 했는데, 맥락상 더 많은 제로데이 공개 가능성으로 읽힘

> [!WARNING]
> 이미 공개된 윈도우 제로데이 중 일부는 실제 공격에 악용 중인 것으로 확인됐다고 보도됨. 이건 연구자와 기업 간 감정싸움으로만 볼 사안이 아니라, 운영 환경에 바로 영향을 줄 수 있는 보안 리스크임.

- 공개된 취약점 목록이 꽤 심각함
  - BlueHammer는 윈도우 디펜더를 통해 시스템 권한을 얻는 취약점으로 설명됨
  - RedSun도 시스템 권한 상승을 가능하게 하는 취약점임
  - UnDefend는 디펜더를 무력화함
  - GreenPlasma는 CTFMon 서비스를 통해 시스템 권한을 얻고, MiniPlasma는 윈도우 클라우드 필터 드라이버 결함을 이용해 비슷한 권한 상승을 제공함
  - YellowKey는 비트로커 취약점으로, 암호화된 드라이브를 거의 힘들이지 않고 여는 문제로 설명됨

- 특히 BlueHammer, RedSun, UnDefend는 실제 공격에 악용 중인 것으로 확인됐다고 함
  - 나머지도 전체 또는 일부 개념증명 코드가 공개됐기 때문에 악용이 어렵지 않을 수 있음
  - 제로데이 공개가 보안 연구의 압박 수단이 되는 순간, 방어자에게는 패치 전 노출 시간이 그대로 공격 기회가 됨

- 외부 전문가 반응도 마이크로소프트에 우호적이지만은 않음
  - Tharros의 윌리엄 도먼은 과거 마이크로소프트 보안 대응 센터가 협업하기 좋았지만, 숙련 인력이 줄고 절차만 따르는 사람들이 남았다는 취지로 비판함
  - 그는 연구자가 익스플로잇 동영상을 제출하지 않아 케이스가 닫혔을 가능성을 언급했는데, 요즘 마이크로소프트 보안 대응 센터의 요구 조건이라는 설명도 덧붙임
  - 물론 마이크로소프트는 세부 내용을 밝히지 않았기 때문에, 연구자가 표준 공개 절차를 따르지 않은 것인지 회사 대응이 문제였는지는 확정하기 어려움

- 깃허브 계정 차단은 보안 측면에서 효과보다 역효과가 커 보인다는 평가가 나옴
  - 이미 코드가 퍼졌다면 계정 하나를 닫아도 보안 위험은 사라지지 않음
  - 오히려 마이크로소프트 소유 플랫폼이 비판적 연구자를 막았다는 인상을 주기 쉬움
  - 연구자는 이미 깃랩으로 옮겼기 때문에 유통 채널만 바뀐 셈임

- 이 사건은 90일 공개 관행이 흔들리는 더 큰 흐름과도 맞물림
  - 인공지능 기반 보안 연구로 취약점 탐색과 악용 속도가 빨라지면서, 기존의 제보 후 90일 패치 대기 모델이 낡았다는 지적이 커지고 있음
  - 공격까지 걸리는 시간과 미사용 익스플로잇의 여유가 줄어드는 상황에서는 기업의 보상·검증·패치 프로세스도 더 빨라져야 함
  - 연구자와 벤더 사이 신뢰가 깨지면 가장 손해 보는 쪽은 결국 패치 전 시스템을 운영하는 사용자와 기업임

- 한국 개발자와 보안팀 입장에서는 “해외 보안 커뮤니티 싸움”으로 넘기기 어렵다
  - 윈도우, 디펜더, 비트로커는 국내 기업과 공공기관에서도 널리 쓰는 기본 인프라임
  - 제로데이 공개와 실제 악용이 겹치면, 패치 관리·위협 인텔리전스·엔드포인트 탐지 정책을 바로 점검해야 함
  - 특히 보안 솔루션 자체를 우회하거나 무력화하는 취약점은 일반 애플리케이션 버그보다 대응 우선순위가 높아질 수밖에 없음

---

## 기술 맥락

- 제로데이가 위험한 이유는 패치보다 공격 정보가 먼저 움직이기 때문이에요. 제조사가 문제를 고치기 전에 개념증명 코드나 익스플로잇이 공개되면, 공격자는 바로 재현을 시도할 수 있고 방어자는 임시 완화책으로 버텨야 해요.

- 버그 바운티와 책임 있는 공개 절차는 이 시간차를 줄이기 위한 장치예요. 연구자는 취약점을 먼저 기업에 알려주고, 기업은 보상과 패치를 통해 공개 전 위험을 낮추는 구조죠. 그런데 보상이나 소통에서 신뢰가 깨지면 연구자가 공개 압박을 선택할 유인이 커져요.

- 이번 사례에서 특히 민감한 건 윈도우 디펜더와 비트로커가 언급됐다는 점이에요. 디펜더는 많은 조직에서 기본 방어선이고, 비트로커는 디스크 암호화의 핵심이에요. 이런 방어 계층 자체가 우회되거나 무력화되면 일반 앱 취약점보다 운영 리스크가 훨씬 커져요.

- 깃허브 계정 차단은 유통 경로를 막는 조치에 가깝지만, 보안 문제를 해결하는 조치는 아니에요. 코드가 이미 복제됐거나 다른 저장소로 옮겨가면 방어 효과는 제한적이에요. 결국 중요한 건 계정 제재보다 취약점 재현, 영향 범위 확인, 패치와 완화책 배포 속도예요.

## 핵심 포인트

- 깃허브가 윈도우 제로데이 익스플로잇을 공개해온 연구자 나이트메어 이클립스 계정을 차단함
- 연구자는 마이크로소프트 보안 대응 센터가 소통과 보상에 실패했다고 주장하며 추가 공개를 예고함
- 공개된 취약점에는 디펜더를 통한 시스템 권한 상승, 디펜더 무력화, 비트로커 우회 등이 포함됨
- BlueHammer, RedSun, UnDefend는 실제 공격에 악용 중인 것으로 확인됐다고 보도됨

## 인사이트

계정 차단은 코드 유통을 잠깐 불편하게 만들 수는 있어도 이미 공개된 익스플로잇을 없애지는 못한다. 더 큰 문제는 보안 제보자와 플랫폼 사이의 신뢰가 무너지면, 90일 공개 관행 자체가 점점 버티기 어려워진다는 점이다.