RoguePlanet PoC 검증 보고서 - Microsoft Defender

보고서의 목적과 범위

본 보고서는 Microsoft Defender와 관련하여 공개적으로 설명된 RoguePlanet PoC의 검증에 관한 것입니다. 설명된 기술은 2026년 6월 10일 언론에서 LPE(로컬 권한 상승)로 발표되었으며, 로컬 사용자가 NT AUTHORITY\SYSTEM 권한을 얻을 수 있었습니다. 공개 설명에 따르면 이 메커니즘은 Microsoft Defender가 파일을 처리하거나 검사할 때 사용하는 기능을 활용합니다.

테스트의 목적은 통제된 실험실 환경에서 익스플로잇을 준비하고 실행할 수 있는지 확인하고, 최신 Windows 11 시스템에서 Microsoft Defender 보호 메커니즘이 어떻게 작동하는지 관찰하는 것이었습니다. 보고서는 테스트 환경, 업데이트 상태, Microsoft Defender 구성, 컴파일 환경 준비, 컴파일 결과, Defender 대응, 위험 완화 권장 사항을 다룹니다.

테스트는 연구 목적으로 전용 테스트 워크스테이션에서 로컬로 수행되었습니다. 결과는 특정 아티팩트 및 특정 환경 구성의 동작에 대한 평가로 해석되어야 하며, 이 기술의 가능한 모든 변형에 대한 저항성을 완전히 확인하는 것으로 해석되어서는 안 됩니다.

분석 자료에서 참조된 출처:

• 기사:

  https://thehackernews.com/2026/06/microsoft-defender-rogueplanet-zero-day.html

• 공개 PoC 저장소:

  https://github.com/MSNightmare/RoguePlanet/tree/main

• MSYS2 설치 프로그램 소스:

  https://github.com/msys2/msys2-installer/releases/tag/nightly-x86_64

• Visual Studio 소스:

  https://visualstudio.microsoft.com/insiders/?rwnlp=pl

테스트 환경

PoC는 Active Directory 도메인 외부에서 WORKGROUP 작업 그룹에서 작동하는 클라이언트 워크스테이션에서 수행되었습니다. 워크스테이션에 설치된 운영 체제는 Microsoft Windows 11 Home, 버전 25H2, 64비트 아키텍처입니다.

PoC가 수행된 날, 시스템에는 2026년 6월 보안 업데이트와 2026년 5월 및 4월의 이전 업데이트가 설치되어 있었습니다. 즉, 테스트는 테스트 날짜 기준으로 최신 보안 패치가 설치된 최신 Windows 11 25H2 시스템(빌드 26200)에서 수행되었습니다.

Microsoft Defender 구성

테스트에 사용된 워크스테이션에서 Microsoft Defender 바이러스 백신이 활성화되어 일반 모드로 실행 중이었습니다. 보호 서비스가 실행 중이고 활성화되었으며, 바이러스 백신 보호, 맬웨어 방지 보호, 동작 모니터링, 실시간 보호가 활성화되었습니다.

테스트 당일 Microsoft Defender 시그니처는 최신 상태였습니다. 바이러스 백신, 맬웨어 방지, NIS 시그니처는 2026년 6월 10일 13:27:32에 업데이트되었습니다.

마지막 빠른 검사는 2026년 6월 8일 15:00:36부터 15:01:58까지 시그니처 버전 1.451.323.0을 사용하여 수행되었습니다. 전체 검사는 이전에 수행되지 않았거나 기록을 사용할 수 없었으며, FullScanAge 값이 4294967295이고 전체 검사 시작 및 종료 시간이 없음을 통해 알 수 있습니다.

컴파일 환경 준비

GitHub 저장소에서 코드를 컴파일하려는 첫 번째 시도는 winternl.h 헤더가 없다는 오류로 종료되었습니다. 메시지는 시스템에 분석된 코드에 필요한 완전한 Windows SDK 헤더 세트가 없음을 나타냅니다.

그림 1. 첫 번째 컴파일 시도 중 winternl.h 헤더 누락 오류.

코드는 또한 windows.h, Psapi.h, ntstatus.h, virtdisk.h, shlwapi.h, taskschd.h, bcrypt.h를 포함한 Windows API 및 NT API 관련 다른 헤더를 참조했습니다. 따라서 더 완전한 컴파일 환경을 준비하고 적절한 SDK 구성 요소를 설치해야 했습니다.

그림 2. 분석된 코드에 필요한 헤더 목록의 일부.

MSYS2/MinGW-w64 사용 시도

처음에는 MSYS2/MinGW-w64를 사용하여 컴파일 환경을 준비했습니다. 이 환경은 Windows용 GNU 도구(gcc 및 g++ 컴파일러 포함)를 제공합니다. MSYS2의 패키지는 Linux 시스템의 apt나 Windows의 winget과 유사한 역할을 하는 pacman을 사용하여 관리됩니다.

그림 3. MSYS2 설치 완료.

pacman을 사용하여 MinGW-w64 GCC/G++ 툴체인, 즉 Windows용 C/C++ 코드 컴파일을 가능하게 하는 도구 세트가 설치되었습니다. 이 패키지에는 gcc 컴파일러, g++ C++ 컴파일러, 링커, Windows 환경에서 실행되는 애플리케이션을 빌드하는 데 필요한 헤더 및 라이브러리가 포함됩니다. 이 시도의 목적은 Visual Studio를 사용하지 않고 MSYS2에서 제공하는 오픈 툴체인을 사용하여 코드를 컴파일할 수 있는지 확인하는 것이었습니다.

그림 4. pacman을 사용한 MSYS2/MinGW-w64 패키지 설치.

설치 후 g++를 사용하여 코드를 컴파일하려고 시도했습니다. 명령은 소스 파일 경로와 결과 실행 파일 경로를 직접 지정했습니다.

C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe

유니코드 모드 문제

호환되지 않는 문자 유형에 관한 컴파일러 메시지가 첫 번째 중요한 유니코드 모드 문제였습니다. 로그에는 const wchar_t* 또는 wchar_t* 유형의 값을 LPCSTR 또는 LPSTR로 변환할 수 없다는 오류가 포함되었습니다. 이는 코드가 Windows API 함수에 와이드 문자열을 전달하는 반면, 컴파일러는 일반 ANSI 문자열용 함수 변형을 선택하고 있음을 의미했습니다.

Windows API에서 많은 함수는 ANSI(A 접미사)와 유니코드(W 접미사)의 두 가지 변형으로 존재합니다. 예를 들어, CreateFile은 CreateFileA 또는 CreateFileW로 매핑될 수 있고, RegOpenKeyEx는 RegOpenKeyExA 또는 RegOpenKeyExW로 매핑될 수 있습니다. A 변형은 char* 또는 LPCSTR 유형의 매개변수를 예상하고, W 변형은 wchar_t* 또는 LPCWSTR 유형의 매개변수를 예상합니다.

분석된 경우, 코드는 L"..." 형식의 리터럴과 wchar_t 유형의 버퍼를 사용했습니다. 동시에 오류 메시지는 컴파일러가 GetModuleHandleA, RegOpenKeyExA, RegQueryValueExA, GetWindowsDirectoryA, CreateFileA, wsprintfA와 같은 함수를 선택했음을 나타냈습니다. 이는 코드가 유니코드 모드를 염두에 두고 작성되었지만 컴파일 명령에 UNICODE 및 _UNICODE가 정의되지 않았음을 직접적으로 나타냈습니다.

따라서 UNICODE 및 _UNICODE 정의를 추가하여 유니코드 모드를 강제했습니다. 이 변경 후 명시적 접미사가 없는 Windows API 함수는 CreateFileW, RegOpenKeyExW, GetModuleHandleW, GetWindowsDirectoryW와 같은 W 접미사 변형으로 매핑되어야 합니다. 변경 후 일부 오류가 사라진 것은 진단의 정확성을 확인해 주었습니다.

C:\msys64\mingw64\bin\g++.exe C:\Users\User\Downloads\RoguePlanet.cpp -o C:\Users\User\Desktop\roguePlanet.exe -DUNICODE -D_UNICODE

그러나 유니코드 관련 문제가 제거된 후에도 코드와 MinGW 간의 더 깊은 비호환성을 나타내는 오류가 남아 있었습니다. 이는 무엇보다도 소스 코드와 MinGW 헤더 모두에 정의된 FILE_BASIC_INFORMATION 및 FILE_RENAME_INFORMATION 구조체의 중복 정의와 관련되었습니다. 또한 MinGW에서 사용 가능한 FILE_RENAME_INFORMATION 버전은 코드에서 예상한 버전과 달랐으며, 특히 Flags 필드가 누락되었습니다.

추가 오류는 특히 enum flags 및 함수 포인터와 관련하여 g++ 컴파일러의 더 제한적인 유형 접근 방식에서 비롯되었습니다. 이는 VIRTUAL_DISK_ACCESS_MASK 및 ATTACH_VIRTUAL_DISK_FLAG 유형과 함수 포인터를 void*로 전달하는 것과 관련이 있습니다. 결과적으로 MinGW는 상당한 소스 코드 수정 없이 이 코드를 컴파일하는 데 부적합한 것으로 판명되었습니다.

5. MSVC 및 Windows SDK로 마이그레이션

MinGW의 호환성 문제로 인해 MSVC 및 Windows SDK 환경이 준비되었습니다. Visual Studio 설치 관리자에서 "C++를 사용한 데스크톱 개발" 워크로드가 선택되었습니다. 분석된 코드는 네이티브 Windows 애플리케이션으로 C/C++로 작성되었으며 Windows API 및 Windows SDK 구성 요소를 직접 사용했기 때문입니다. .NET, Python, Node.js 또는 웹 애플리케이션 프로젝트가 아니었으므로 해당 기술과 관련된 구성 요소는 설치되지 않았습니다.

그림 5. 데스크톱 C++ 애플리케이션을 위해 선택된 Visual Studio 워크로드 및 구성 요소.

가장 중요한 구성 요소는 MSVC v143, 즉 Windows용 C/C++ 애플리케이션을 빌드하기 위한 Microsoft C/C++ 컴파일러였습니다. 이전에 MinGW/G++로 컴파일을 시도했을 때 헤더, 유형, NT API 구조와 관련된 호환성 오류가 발생했기 때문에 선택되었습니다. 코드는 Windows 관련 메커니즘을 사용했으므로 가장 호환성이 좋은 환경은 Microsoft 컴파일러와 Windows SDK에서 제공하는 라이브러리였습니다.

Windows 11 SDK도 설치되었습니다. 이 구성 요소에는 windows.h, winternl.h, winreg.h, processthreadsapi.h, virtdisk.h와 같은 Windows 시스템 함수를 사용하는 데 필요한 헤더와 링크 중에 사용되는 .lib 가져오기 라이브러리가 포함됩니다. 또한 C++ CMake 도구는 더 복잡한 프로젝트를 분석할 때 유용한 보조 구성 요소로 유지되었습니다.

설치 후, cl.exe 컴파일러, Windows SDK, 링커 라이브러리에 대한 올바른 경로가 설정된 x64 Native Tools Command Prompt for VS Insiders가 사용되었습니다.

그림 6. x64 Native Tools Command Prompt for VS Insiders 실행.

6. MSVC를 사용한 컴파일

MSVC로 전환한 후 코드는 빌드 프로세스에서 훨씬 더 진전되었습니다. 첫 번째 명령은 여전히 Windows API 함수를 ANSI 변형에 매핑하는 오류를 반환했으므로 MSVC 컴파일 중에도 UNICODE 및 _UNICODE 정의를 추가해야 했습니다.

cl /EHsc RoguePlanet.cpp -o rogue.exe

그림 7. 전체 유니코드 및 링킹 구성 없이 MSVC를 사용한 컴파일 시도.

유니코드 스위치를 추가한 후 코드는 더 진행되었고, 헤더 및 유형 호환성 오류는 LNK2019 링커 오류로 대체되었습니다. 이는 컴파일러가 이미 개체 파일을 생성할 수 있었지만, 링커가 사용된 Windows API 함수에 필요한 모든 가져오기 라이브러리를 아직 받지 못했음을 의미합니다.

cl /EHsc /DUNICODE /D_UNICODE RoguePlanet.cpp /Fe:rogue.exe

그림 8. Windows API 함수에 대한 LNK2019 링커 오류.

링커 오류에는 CreateProcessAsUserW, OpenProcessToken, AdjustTokenPrivileges, DuplicateTokenEx, GetTokenInformation, LookupPrivilegeValueW, RegOpenKeyExW, RegQueryValueExW와 같은 함수가 포함되었습니다. 이러한 함수는 보안 토큰, 권한, 특정 사용자 컨텍스트에서 프로세스 시작, 시스템 레지스트리 읽기와 관련되어 있습니다. 헤더는 함수가 존재한다고 선언할 뿐이지만, 링커는 해당 함수의 구현이 위치한 올바른 가져오기 라이브러리를 받아야 합니다.

링커 오류를 해결하기 위해 advapi32.lib 라이브러리가 추가되었습니다. 이는 보안 토큰, 권한, 사용자 계정, 시스템 레지스트리와 관련된 함수를 제공하는 Windows 가져오기 라이브러리입니다. 이를 링킹 단계에 추가한 후, 링커는 이전에 확인되지 않은 외부 기호를 확인하고 실행 파일을 생성할 수 있었습니다.

cl /EHsc /DUNICODE /D_UNICODE RoguePlanet.cpp /Fe:rogue.exe /link advapi32.lib

그림 9. 수정된 컴파일 명령의 결과.

그림 10. 성공한 명령의 결과.

그림 11. 작업 디렉터리 ~\Downloads\\에 생성된 rogue.exe 파일.

Microsoft Defender 대응 및 실행 결과

검증 중에 생성된 실행 파일은 Microsoft Defender에 의해 Trojan:Win64/RoguePlanet.DA!MTB로 즉시 탐지되었으며 심각도 수준은 "심각(Severe)"이었습니다. 시스템은 파일을 격리로 이동하거나 삭제하는 등의 표준 보호 조치를 제안했습니다.

그림 12. 파일이 바이러스 또는 잠재적으로 원치 않는 소프트웨어로 차단되었음을 알리는 Windows 메시지.

그림 13. Microsoft Defender 탐지: Trojan:Win64/RoguePlanet.DA!MTB.

이는 Defender의 탐지 메커니즘이 준비된 아티팩트를 성공적으로 실행되기 전에 악성 또는 잠재적으로 위험한 것으로 식별했음을 의미합니다. 엔드포인트 보호 관점에서 이는 긍정적인 결과입니다. 차단이 프로그램 실행 효과를 관찰한 후가 아니라 실행 파일 단계에서 발생했기 때문입니다.

실시간 보호가 일시적으로 비활성화된 후 파일을 실행할 수 있었습니다. 테스트 관찰에 따르면 두 번째 실행 후 SYSTEM 권한으로 실행되는 콘솔을 얻을 수 있었습니다. 이 결과는 활성 Defender 보호가 테스트된 아티팩트를 차단하는 데 중요했음을 확인합니다.

그림 14. 실시간 보호가 비활성화된 후 테스트 환경에서 프로그램 실행.

그림 15. 테스트 환경에서 시스템 컨텍스트에서 실행되는 콘솔.

위험 평가

Microsoft Defender가 특정 파일 하나를 탐지했다고 해서 취약점 위험이 완전히 제거된 것은 아닙니다. Defender는 알려졌거나 유사한 PoC 아티팩트를 탐지했지만, 수정된 코드, 다른 컴파일, 변경된 파일 구조 또는 다른 로더는 시그니처 기반 또는 휴리스틱 탐지와 관련하여 다르게 동작할 수 있습니다. 테스트 결과는 테스트된 아티팩트에 대한 현재 보호 계층의 효과를 확인하는 것으로 간주되어야 하며, 기술의 가능한 모든 변형이 차단된다는 증거로 간주되어서는 안 됩니다.

동시에 테스트 결과는 활성 실시간 보호 및 최신 시그니처를 사용할 때 Defender가 생성된 아티팩트를 성공적으로 차단했음을 나타냅니다. 사용자가 실시간 보호를 비활성화하거나, 제외를 추가하거나, 탐지된 위협을 허용하거나, 보호 구성을 로컬로 수정할 수 있는 경우 실제 악용 위험이 크게 증가합니다.

실제로 이는 효과적인 완화가 Defender 자체의 존재에만 의존해서는 안 되며, 중앙에서 구성을 강제하고 사용자의 로컬 변경을 차단하는 데에도 의존해야 함을 의미합니다.

9. 권장 사항

보안 정책을 통해 Microsoft Defender 구성을 중앙에서 강제하는 것이 중요합니다. 로컬 사용자가 실시간 보호를 비활성화하거나, 제외를 추가하거나, 탐지된 위협을 허용하거나, 보호 설정을 수정할 수 없어야 합니다. 이러한 모델에서 사용자는 "디바이스에서 허용"과 같은 옵션을 선택하거나 일시적으로 보호를 비활성화하여 독립적으로 탐지를 우회할 수 없어야 합니다.

• 실시간 보호, 클라우드 제공 보호, 자동 샘플 제출을 중앙에서 강제합니다.
• 사용자가 탐지에 대한 제외 및 작업을 관리하지 못하도록 차단합니다.
• 탐지, 격리, 위협 허용 시도, 보호 구성 변경과 관련된 Defender 이벤트를 모니터링합니다.
• Trojan:Win64/RoguePlanet.DA!MTB 탐지를 분석이 필요한 보안 이벤트로 처리합니다.
• 환경의 기능에 따라 애플리케이션 허용 목록, WDAC 또는 AppLocker와 같은 승인되지 않은 실행 파일 실행을 제한하는 추가 메커니즘을 고려합니다.

최종 결론

테스트는 아티팩트를 준비하는 데 Microsoft의 네이티브 툴체인과 호환되는 환경이 필요함을 확인했습니다. MinGW/G++를 사용한 컴파일 시도는 NT API 헤더 및 구조체와의 호환성 문제를 드러냈지만, MSVC 및 Windows SDK로 전환하면 올바른 가져오기 라이브러리를 추가한 후 프로세스가 링킹 단계에 도달하고 궁극적으로 실행 파일을 생성할 수 있었습니다.

일반 모드에서 최신 시그니처와 실시간 보호가 활성화된 Microsoft Defender는 생성된 파일을 Trojan:Win64/RoguePlanet.DA!MTB로 탐지하고 실행을 차단했습니다. 이는 엔드포인트 보호 관점에서 긍정적인 테스트 결과입니다.

동시에 실시간 보호를 비활성화하면 아티팩트를 실행할 수 있었고 SYSTEM 권한으로 콘솔을 얻을 수 있었습니다. 실용적인 결론은 분명합니다. Defender 구성을 중앙에서 강제해야 하며, 사용자가 로컬에서 보호를 약화시키거나, 제외를 추가하거나, 탐지된 위협을 허용할 수 없어야 합니다.