가상화된 보안(취약점): 공격자가 VBS 엔클레이브를 악용하는 방법

공격자는 탐지되지 않고 호스트에서 멀웨어를 전송하고 실행할 새로운 방법을 늘 찾고 있습니다. 저희는 VBS(가상화 기반 보안) 엔클레이브 내부에서 멀웨어를 실행하고 일반적인 보안 보호 조치를 우회하는 새로운 기술을 연구했습니다. 저는 2025년 8월 8일, 라스베이거스의 DEF CON 33 프레젠테이션을 통해 이 공격 표면을 살펴봤습니다.

Microsoft의 보안 구현에 포함된 VBS는 중요한 OS 구성요소를 격리하도록 설계된 가상 환경을 만듭니다. VBS 엔클레이브는 프로세스의 특정 영역을 격리해 다른 프로세스, 프로세스 자체, 심지어 커널까지도 접속할 수 없도록 하는 기술입니다. 

VBS 엔클레이브는 보안을 향상시킬 수 있지만 공격자에게도 매력적일 수 있습니다. 엔클레이브 내부에서 실행되는 멀웨어는 일반적으로 사용되는 메모리 기반 탐지 및 포렌식에 표시되지 않기 때문입니다. 이 아이디어를 연구한 결과, VBS 엔클레이브가 악용될 수 있는 여러 가지 방법을 찾았습니다.

VBS 엔클레이브의 기반이 되는 VTL(가상 신뢰 수준)의 개념을 이해하는 것이 중요합니다. 각 신뢰 수준은 물리적 메모리에 대해 서로 다른 접속 권한을 가진 상태로 그 메모리에서 실행되는 엔터티를 제공합니다. 하위 VTL은 상위 VTL의 메모리에 접속할 수 없습니다. 

현재 Windows는 주로 두 가지 신뢰 수준을 사용합니다.  VTL0은 일반 커널 및 일반 사용자 실행 모드를 포함해 기존 OS 구성요소를 실행하는 데 사용되며, VTL0보다 더 높은 권한을 가진 VTL1은 보안 커널 모드와 격리된 사용자 모드의 두 가지 새로운 실행 모드를 생성합니다.

• 보안 커널 모드는 보안 커널을 실행하는 데 사용됩니다. 보안 커널은 VTL1에서 실행되는 커널이기 때문에 일반 커널보다 더 많은 권한을 가지고 있습니다. 보안 커널은 일반 커널에 정책을 적용하고 민감한 메모리 영역에 대한 접속을 제한할 수 있습니다. 보안 커널은 매우 좁고 타사 드라이버를 지원하지 않기 때문에 공격 표면이 크게 줄어듭니다.
• 격리된 사용자 모드는 VTL1의 메모리 분리 기능을 사용하는 특별한 종류의 사용자 모드 프로세스인 보안 프로세스를 실행하는 데 사용됩니다. 격리된 사용자 모드의 메모리는 일반 커널을 포함한 어떤 VTL0 코드도 접속할 수 없습니다.

VTL0 및 VTL 1을 함께 사용하면 4가지 실행 모드가 생성됩니다. 

• Ring0 VTL0 - 일반 커널 모드
• Ring0 VTL1 - 보안 커널 모드
• Ring3 VTL0 - 일반 사용자 모드
• Ring3 VTL1 - 격리된 사용자 모드

VBS 엔클레이브는 격리된 사용자 모드에 상주하는 사용자 모드 프로세스의 한 부분을 생성해 ‘엔클레이브 모듈’이라고 불리는 DLL을 이 부분에 로딩할 수 있습니다. 이는 VTL0에서 실행되는 그 어떤 항목에도 접속할 수 없는 데이터와 코드를 포함하는 ‘신뢰할 수 있는 실행 환경’이 되므로 시스템을 감염시킬 수 있는 공격자로부터 민감한 작업을 격리하는 데 용이합니다.

VTL1에 대한 접속이 제한되기 때문에 DLL을 엔클레이브에 로딩하려면 Microsoft가 발급한 특별한 인증서를 사용해 적절하게 서명해야 합니다. 그런 서명 없이 모듈을 로딩하려고 하면 실패하게 됩니다. 신뢰할 수 있는 제3자만 엔클레이브 모듈에 서명할 수 있지만, 이러한 모듈을 로드할 수 있는  사람에 대한 제한은 없으므로 이러한 모듈에 서명이 되어 있는 한, 어떤 프로세스든 임의의 모듈을 엔클레이브에 로딩할 수 있습니다.

VBS 엔클레이브는 몇 가지 이유로 공격자에게 매력적인 수단입니다. 첫째, 엔클레이브의 주소 공간에는 EDR(엔드포인트 탐지 및 대응)과 분석 툴을 포함해 VTL0에서 실행되는 그 어떤 것으로도 접속할 수 없습니다. 둘째, 엔클레이브 내에서 이루어진 API 호출은 EDR에 보이지 않을 수 있습니다.

이러한 점을 인식하고 저희는 공격자가 엔클레이브에서 악성 코드를 실행하는 방법을 조사했습니다. 또한 멀웨어가 실행된 후 어떤 기법을 사용할 수 있는지 살펴보았습니다. 이 블로그 게시물에 저희가 발견한 내용이 나옵니다.

VBS 엔클레이브 모듈은 디버그 가능하도록 구성할 수 있습니다. 엔클레이브 모듈은 VTL1에서 실행되므로 디버거에서 엔클레이브 메모리에 접속해 데이터를 검색하거나 브레이크 포인트를 배치할 수 없기 때문에 일반적으로는 디버그를 수행할 수 없습니다. 하지만 저희는 디버그 가능한 엔클레이브 모듈이 실행되면 이 모듈은 여전히 VTL1에 로드된다는 점을 확인했습니다. 

디버그를 활성화하기 위해, 보안 커널은 디버그 가능한 엔클레이브 모듈에 적용되는 몇 가지 예외를 구축합니다. 디버그 가능한 엔클레이브 모듈 내의 메모리 권한도 VTL0 프로세스에 의해 수정될 수 있습니다. 모듈에서 처리하는 데이터가 쉽게 노출될 수 있습니다.

이는 VBS 엔클레이브의 핵심 목적을 효과적으로 약화시키고, VTL0에서 메모리 섹션을 격리합니다. 이러한 이유로 Microsoft는 개발자가 디버그 가능한 엔클레이브 모듈을 배포하지 않을 것을 강력히 권고하고 있습니다.

공격자가 어떤 디버그 가능한 서명된 엔클레이브 모듈을 획득하면 DEF CON에서 제가 말씀드린 몇 가지 단계를 수행해 VTL1 코드 실행을 달성할 수 있습니다. 이렇게 하면 공격자가 위험할 수 있습니다. 엔클레이브 메모리에 접속 시 EDR이 이루어질 수 있기 때문입니다. 그러나 이 공격은 API 모니터링을 우회할 수 있어 EDR 솔루션의 가시성을 제한할 수 있습니다.

이 기법은 엔클레이브 내부에서 실행할 때 얻을 수 있는 몇 가지 장점을 활용하는 은밀한 ‘세미 VTL1’ 임플란트를 만드는 데 유용할 수 있습니다.

저희는 공격자가 VBS 엔클레이브에서 BYOVD(Bring Your Own Vulnerable Driver) 기법을 사용해 멀웨어를 실행할 수 있는지 살펴보았습니다. 이 작업은 취약점을 통해 서명된 엔클레이브 모듈을 찾는 것과 관련이 있습니다.

그러던 중 Microsoft Edge에서 사용하는 VBS 엔클레이브 모듈인 CVE-2023-36880에 주목하게 되었습니다. Chrome 플랫폼 보안팀의 알렉스 고프(Alex Gough)가 발견한 이 취약점을 통해 공격자는 엔클레이브 내부에서 임의의 데이터를 읽고 쓸 수 있습니다. 

저희는 엔클레이브 스택을 ROP(Return-Oriented Programming) 체인으로 덮어쓰는 읽기/쓰기 프리미티브를 악용하려고 시도했고 결국, 엔클레이브 내에서 셸코드를 실행할 수 있었습니다. 그러나 런타임에서 만들어진 코드의 실행을 차단하도록 설계된 보안 방어 조치인 ACG(Arbitrary Code Guard)를 사용하면 엔클레이브가 서명되지 않은 코드 실행으로부터 보호된다는 점을 발견했습니다(그림). 

이론적으로는 전체 ROP 악용이 가능하기는 하지만 아직 엔클레이브 내에서 ACG를 우회하고 서명되지 않은 코드를 로드할 방법은 찾지 못했습니다.

저희는 양성 상태와 악용된 상태 사이를 지속적으로 전환하는 페이로드를 생성하는 우회 기법인 Gargoyle에서 영감을 받은 ‘Mirage’라는 메모리 스캐닝 우회 기법을 살펴보았습니다. 

Mirage는 VTL1과 VTL0 메모리 간을 전환하는 식으로 우회합니다. 셸코드를 VTL1 엔클레이브 메모리에 저장하고, 취약점을 이용해 주기적으로 VTL0으로 다시 전송한 다음, 이를 실행한 후 즉시 VTL0 메모리에서 삭제합니다.

페이로드가 대부분의 시간 동안 VTL1에 숨겨져 있기 때문에 메모리 스캔과 덤프에 대한 복원력이 뛰어납니다. 잠복 단계에서는 페이로드가 탐지되지 않으며 여기에 접속할 수도 없습니다. 또한 엔클레이브에서 EDR 툴의 시야 밖에서 VTL0에 셸코드를 기록하므로 모니터링으로는 탐지하기가 어렵습니다.

엔클레이브 멀웨어의 또 다른 흥미로운 응용 분야는 안티 디버그입니다. 엔클레이브 내에서 실행되는 코드는 디버거를 비롯한 VTL0 애플리케이션에 접속할 수 없어 멀웨어의 이점을 크게 누릴 수 있습니다.

저희는 다양한 접근 방식을 살펴보았습니다. 프로세스 VTL0 주소 공간에 대한 엔클레이브의 접속을 통해 프로세스 PEB(프로세스 환경 블록)를 수동으로 읽고 BeingDebugged 플래그의 값을 확인할 수 있습니다. 디버거가 탐지되면 엔클레이브가 프로세스를 종료할 수 있습니다.

프로세서 클럭 사이클을 사용해 여러 엔클레이브 호출 간에 소요된 시간을 측정하고 상당한 지연이 감지되면 프로세스를 종료하는 시간 기반 디버깅 기법도 살펴보았습니다.

코드의 중요한 부분을 안티 디버그 체크와 함께 엔클레이브로 옮기면 동적 분석을 거의 완벽하게 방어하는 멀웨어를 만들 수 있습니다. 이 접근법을 올바르게 구축하면 Hyper-V 또는 보안 커널 디버그를 통해서만 무력화할 수 있습니다.

현재로서는 아주 제한된 수의 애플리케이션만이 엔클레이브를 사용하고 있습니다. 따라서 엔클레이브의 비정상적인 사용/남용을 쉽게 탐지할 수 있습니다. 이러한 기회를 활용하기 위해 보안팀 직원은 다음과 같은 사항에 중점을 둘 수 있습니다.

• VBS 엔클레이브의 알려진 정상 사용 기준선을 설정하고 편차를 표시합니다.
• 엔클레이브 API의 비정상을 모니터링합니다.
• 새 프로세스를 나타낼 수 있는 엔클레이브 DLL의 로딩 여부를 모니터링합니다.
• 중요한 시스템과 애플리케이션을 격리하기 위해 설계된 다른 보안 기법(예: 마이크로세그멘테이션)을 사용합니다.

VBS 엔클레이브는 애플리케이션의 민감한 부분을 보호할 수 있는 효과적인 툴을 제공하지만, 공격자가 멀웨어를 ‘보호’하는 데 사용할 수도 있습니다. DEF CON 프레젠테이션에서 설명해 드린 바와 같이, 현 시점에서 엔클레이브 공격 전략은 대개 이론 수준에 그치고 있습니다. 그러나 숙련된 공격자들이 VBS 엔클레이브를 악의적인 목적으로 사용할 수 있는 취약점을 찾아내기 위해 자체적인 리서치를 수행하고 있을 것이라고 확신할 수 있습니다. 

환경 내에서 엔클레이브의 사용을 파악하는 것은 이렇게 진화하는 위협에 앞서 나가기 위한 힘찬 첫걸음입니다.

제가 이전에 작성한 블로그 게시물인 VBS 엔클레이브를 악용해 회피성 멀웨어 만들기에서 자세한 기술 정보를 알아보세요.