Skip to content
KitploitKITPLOIT
도구블로그
Log in
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
CVE-2026-50656-rogueplanet-validation — 통제된 Windows 11 실험실 환경에서 RoguePlanet Microsoft Defender PoC에 대한 검증 보고서. 빌드 노트, Defender 탐지 결과, 위험 평가 및 완화 권장 사항을 포함합니다. | Kitploit
도구/GitHubGitHub/g0thamrabb1t/cve-2026-50656-rogueplanet-validation
Privilege EscalationVulnerability AnalysisExploitationMalware AnalysisPenetration TestingLearning & EducationBinary ExploitationLabs & Practice

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유
GitHub
g0thamrabb1t/cve-2026-50656-rogueplanet-validation

CVE-2026-50656-rogueplanet-validation

통제된 Windows 11 실험실 환경에서 RoguePlanet Microsoft Defender PoC에 대한 검증 보고서. 빌드 노트, Defender 탐지 결과, 위험 평가 및 완화 권장 사항을 포함합니다.

저장소 보기
273개월 전아직 검토되지 않음

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비트 아키텍처입니다.

매개변수값
시스템 이름Microsoft Windows 11 Home
에디션Home
시스템 버전25H2
OS 버전10.0.26200
빌드 번호26200
아키텍처x64 / 64비트
설치 유형클라이언트 / 워크스테이션
호스트 이름LAPTOP-80LPIEH2
디바이스 제조사Lenovo
디바이스 모델Lenovo Legion Slim 5 16IRH8
프로세서12th Gen Intel(R) Core(TM) i5-12450H
RAM32 GB

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

HotFixID업데이트 유형설치 날짜
KB5094135보안 업데이트10.06.2026
KB5094126보안 업데이트10.06.2026
KB5087051업데이트14.05.2026
KB5092762보안 업데이트13.05.2026
KB5054156업데이트28.04.2026

Microsoft Defender 구성

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

매개변수값
AMProductVersion4.18.26050.15
AMServiceVersion4.18.26050.15
AMEngineVersion1.1.26050.11
AMRunningModeNormal
AMServiceEnabledTrue
AntivirusEnabledTrue
AntispywareEnabledTrue
RealTimeProtectionEnabledTrue
BehaviorMonitorEnabledTrue
OnAccessProtectionEnabledTrue
IoavProtectionEnabledTrue
NISEnabledTrue
NISEngineVersion1.1.26050.11
IsTamperProtectedTrue
DefenderSignaturesOutOfDateFalse
RebootRequiredFalse
IsVirtualMachineFalse

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

시그니처 유형버전마지막 업데이트 날짜
AntivirusSignatureVersion1.453.27.010.06.2026 13:27:32
AntispywareSignatureVersion1.453.27.010.06.2026 13:27:32
NISSignatureVersion1.453.27.010.06.2026 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로 마이그레이션

도구 다운로드