VBS 엔클레이브를 악용해 회피성 멀웨어 만들기

VBS(Virtualization-Based Security)는 최근 가장 흥미로운 보안 발전 분야 중 하나입니다. 운영 체제의 중요한 구성요소를 격리할 수 있는 기능 덕분에 Microsoft는 Credential Guard 및 HVCI(Hypervisor-Protected Code Integrity)와 같은 기능을 통해 보안을 상당히 향상할 수 있었습니다.

VBS가 활성화하는 기능 중 간과되기 쉬운 기능은 VBS 엔클레이브 입니다. 이 기술은 프로세스의 특정 영역을 격리해 다른 프로세스, 프로세스 자체, 심지어 커널까지도 접근할 수 없도록 하는 기술입니다. 

VBS 엔클레이브는 다양한 보안 응용 분야에 사용될 수 있으며 Microsoft는 논란이 되고 있는 리콜 기능을 포함해 몇 가지 주목할 만한 서비스를 구축하는 데 이 기술을 사용합니다. 또한, Microsoft는 VBS 엔클레이브의 써드파티 개발을 지원하고 적극적으로 도입을 장려하고 있습니다.

엔클레이브는 시스템을 보호하는 데 도움이 될 수 있지만 공격자에게도 매우 매력적일 수 있습니다. 엔클레이브 내부에서 실행되는 멀웨어는 메모리 기반 탐지 및 포렌식 기술에 의해 탐지되지 않을 수 있습니다.

Akamai는 VBS 엔클레이브를 탐색하고 악의적인 목적으로 사용될 수 있는 경우를 이해하기 시작했습니다. 이 블로그 게시물을 통해 Akamai가 발견한 주요 내용을 자세히 설명합니다. Akamai는 이전에 문서화되지 않은 행동을 탐색하고, 공격자가 엔클레이브 내부에서 악성 코드를 실행할 수 있는 다양한 시나리오를 설명하고, ‘엔클레이브 멀웨어’가 사용할 수 있는 다양한 기술을 검토함으로써 VBS 엔클레이브에 대해 자세히 살펴볼 것입니다.

또한, 새로운 접근 방식에 기반한 메모리 회피 기법인 Mirage를 소개합니다. Akamai는 이 기법을 ‘취약한 엔클레이브를 가져오기‘라고 부릅니다. 공격자가 오래된 취약한 버전의 정상적인 엔클레이브를 사용해 이 은밀한 회피 기법을 구축할 수 있는 방법을 살펴보겠습니다.

Windows는 전통적으로 사용자 애플리케이션이 OS를 조작하지 못하도록 프로세서 링 레벨에 의존해 왔습니다. 이 하드웨어 기능은 OS와 사용자 애플리케이션을 분리할 수 있게 해줍니다. 커널은 ring3 사용자 모드 애플리케이션과 격리된 ring0에서 실행됩니다. 이 접근 방식의 문제는 커널 악용과 같은 공격자가 OS를 감염시킬 수 있는 비교적 쉬운 경로를 제공한다는 것입니다.

Windows 커널은 매우 풍부한 공격 표면을 노출합니다. 커널 자체에 의해 노출되는 다양한 서비스와 함께 방대한 써드파티 드라이버 목록은 커널 악용의 끊임없는 개발로 이어집니다. 공격자는 이러한 악용을 사용해 잠재적으로 OS의 모든 측면을 제어할 수 있습니다. 사용자/커널 모드의 경계가 불충분하다는 것이 증명되었습니다.

이 문제를 해소하기 위해 Microsoft는 VTL(Virtual Trust Level)이라는 형태로 OS에 추가적인 보안 경계를 도입했습니다. VTL 권한은 메모리 접속을 기반으로 합니다. 각 신뢰 수준은 그 아래에서 실행되는 엔티티에 물리적 메모리에 대한 서로 다른 접속 권한을 제공합니다. 무엇보다도, 이러한 권한은 낮은 VTL이 높은 VTL의 메모리에 접속할 수 없도록 합니다.

기존의 프로세서 링 아키텍처와 마찬가지로 VTL은 OS를 실행의 다른 ‘모드’로 분리하며 VTL0에서 시작해 (잠재적으로) VTL16에서 끝납니다. ring0이 가장 권한이 많은 프로세서 링과 달리 상위 VTL은 하위 VTL보다 더 많이 권한을 가집니다.

현재 Windows는 VTL0과 VTL1의 두 가지 주요 신뢰 수준을 사용합니다(VTL2도 사용되지만, 이 블로그 게시물의 범위를 벗어납니다). VTL0은 커널과 사용자 모드 애플리케이션을 포함한 기존의 OS 구성요소를 실행하는 데 사용됩니다. VTL0보다 더 많은 권한을 가진 VTL1은 보안 커널 모드 및 격리된 사용자 모드라는 두 가지 새로운 실행 모드를 생성합니다.

보안 커널 모드는 ring0 VTL1 실행 모드를 의미합니다. 이 모드는 보안 커널을 실행하는 데 사용됩니다. 보안 커널은 VTL1에서 실행되는 커널이기 때문에 일반 커널보다 더 많은 권한을 가지고 있습니다. 보안 커널은 이러한 권한을 사용해 일반 커널에 정책을 적용하고 민감한 메모리 영역에 대한 접속을 제한할 수 있습니다.

앞서 언급했듯이 커널은 공격에 노출되는 표면이 넓고 감염되기 쉽습니다. 커널의 일부 권한을 제거하고 그 권한을 보안 커널에 부여함으로써 커널 감염으로부터의 영향을 줄일 수 있습니다.

이론적으로 공격자는 여전히 보안 커널의 감염을 통해 시스템을 완전히 감염시킬 수 있습니다. 그럼에도 불구하고 보안 커널이 매우 좁고 써드파티 드라이버를 지원하지 않아 공격 표면이 상당히 감소하기 때문에 이 시나리오의 발생 가능성은 훨씬 작습니다.

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

엔클레이브 모듈은 시스템과 상호작용을 하거나 시스템에 영향을 미칠 수 있는 능력이 매우 제한적인 작은 ‘계산 단위’로 사용됩니다. 따라서 최소한의 API 세트만 사용할 수 있으며 이로 인해 대부분의 OS 구성요소에 접속할 수 없습니다.

엔클레이브 내부에서 사용할 수 있는 API는 VTL1에 로딩된 전용 라이브러리에서 가져옵니다. 예를 들어, 일반적인 프로세스는 OS에서 서비스를 요청하기 위해 ntdll.dll 라이브러리에 의존하지만 엔클레이브 모듈은 시스템 호출을 통해 보안 커널과 통신하는 데 사용되는 ‘대체’ ntdll인 vertdll.dll 을 사용합니다.

엔클레이브 멀웨어의 개념은 두 가지 중요한 장점을 제공하기 때문에 공격자에게 확실히 매력적일 수 있습니다.

1. 격리된 메모리 영역에서 실행: 엔클레이브의 주소 공간은 EDR과 분석 툴을 포함해 VTL0에서 실행되는 모든 것에서 접속할 수 없기 때문에 탐지가 훨씬 더 복잡해집니다.

2. 추적 불가능한 API 호출: 엔클레이브 내에서 이루어진 API 호출은 EDR에 보이지 않을 수 있습니다. EDR은 시스템 라이브러리 내에 후크를 배치해 사용자 모드에서 API를 모니터링하고, 드라이버를 사용해 커널의 활동을 모니터링합니다. 엔클레이브 호출은 VTL1에서 수행되고 이러한 ‘후크된’ VTL0 구성요소를 거치지 않기 때문에, 이러한 기술로는 엔클레이브에서 발생한 API 호출을 탐지할 수 없습니다.

그림 4는 이 장점을 보여줍니다. Windows API를 호출하는 일반적인 프로세스는 NTDLL 내부의 후크나 커널 자체를 통해 모니터링할 수 있습니다. 그러나 엔클레이브 모듈은 VTL1 상주 vertdll 을 통과하고 보안 커널에 대한 호출을 호출합니다. 이 두 가지 모두 EDR에서 접속할 수 없습니다.

Akamai는 이러한 잠재력을 인식하고 엔클레이브 멀웨어의 개념을 조사하기 시작했습니다. 엔클레이브를 이러한 목적으로 활용하기 위해서는 두 가지 질문에 답해야 합니다.

1. 공격자는 어떻게 엔클레이브 내에서 악성 코드를 실행할 수 있습니까?
2. 엔클레이브 내에서 실행되면 공격자는 어떤 기술을 사용할 수 있습니까?

앞서 언급했듯이, 엔클레이브 모듈을 로딩하려면 Microsoft에서 발급한 인증서로 서명해야 합니다. 즉, 엔클레이브 내에서 자체 코드를 실행할 수 있는 것은 Microsoft에서 승인한 엔티티뿐입니다. 그럼에도 불구하고 공격자는 여전히 몇 가지 옵션을 가지고 있습니다.

첫째, 공격자는 OS 취약점을 이용할 수 있습니다. CVE-2024-49706은 알렉스 이오네스쿠(Alex Ionescu, Winsider Seminars & Solutions에서 근무)가 발견한 취약점으로 공격자는 이를 통해 서명되지 않은 모듈을 엔클레이브에 로딩할 수 있습니다. 이 취약점은 Microsoft에 의해 패치되었지만, 의욕적인 공격자가 향후 유사한 버그를 발견할 수도 있습니다.

두 번째로 간단한 접근 방식은 정상적인 서명을 얻는 것입니다. 이 접근 방식은 Microsoft가 Trusted Signing 플랫폼을 통해 서명 엔클레이브를 써드파티에게 공개하기 때문에 가능합니다. 물론 간단하지는 않지만, 고도로 숙련된 공격자는 Trusted Signing 엔티티에 접속해 자신의 엔클레이브에 서명할 수 있습니다.

이 두 가지 옵션 외에도 Akamai는 공격자가 VBS 엔클레이브 내부에서 코드를 실행하기 위해 사용할 수 있는 두 가지 추가 기술을 탐구했습니다. 바로 디버그 가능한 엔클레이브를 악용하는 방법과 취약한 엔클레이브를 이용하는 방법입니다.

공격자의 관점에서 명백한 문제는 이것이 양날의 검이라는 것입니다. 공격자가 엔클레이브 메모리에 접속할 수 있는 것처럼 EDR도 접속할 수 있습니다. 그럼에도 불구하고, API 모니터링을 피할 수 있다는 장점이 있습니다. 엔클레이브 모듈에 의해 수행되는 API 호출은 여전히 VTL1 DLL과 보안 커널을 통과하므로 EDR의 가시성이 제한됩니다.

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

Akamai는 VirusTotal과 다른 소스를 사용해 디버그 가능한 서명된 엔클레이브 모듈을 식별하려고 시도했지만, 이 글을 쓰는 시점에서는 성공하지 못했습니다. 그러나 충분한 시간이 주어지고 엔클레이브 기술이 널리 도입된다면 결국에는 일부가 유출될 것이라고 가정하는 것이 안전하다고 생각합니다.

Akamai는 엔클레이브 내에서 ACG를 우회하고 서명되지 않은 코드를 로딩하는 방법을 찾지 못했습니다. 이론적으로는 전체 ROP 악용이 가능하므로 공격자가 VTL1에서 임의의 API를 호출할 수 있게 될 가능성이 있습니다. 그러나 Akamai는 이 방향을 추구하지 않았습니다. 그럼에도 불구하고, Akamai는 취약한 엔클레이브에 대한 또 다른 흥미로운 애플리케이션을 확인했으며 이 글의 뒷부분에서 이 내용을 논의할 것입니다.

Akamai는 엔클레이브가 악성 활동에 이용될 많은 잠재력을 가지고 있을 수 있고, 의욕적인 공격자가 엔클레이브를 실행할 수 있다는 것을 이해한 다음, 이러한 종류의 멀웨어에 어떤 기술이 사용될 수 있는지 연구했습니다.

가장 직접적인 사용 방법은 엔클레이브를 의도된 대로 사용하는 것입니다. 엔클레이브가 공격자로부터 민감한 데이터를 보호할 수 있는 것처럼, 공격자는 VTL0 엔티티로부터 ‘비밀’을 숨기기 위해 엔클레이브를 사용할 수도 있습니다.

이는 EDR의 손이 닿지 않는 곳에 페이로드를 저장하거나, 분석가로부터 숨겨진 암호화 키를 봉인하거나, 민감한 멀웨어 설정을 메모리 덤프에서 제외하는 등 다양한 상황에서 유용할 수 있습니다.

보다 고급 옵션의 경우, 많은 기존의 멀웨어 기법이 엔클레이브 내에서 구축될 수 없습니다. 엔클레이브는 제한된 시스템 API 하위 집합으로 제한되기 때문에 파일, 레지스트리, 네트워킹, 기타 프로세스 등과 같은 주요 OS 구성요소와의 상호 작용이 차단됩니다.

그럼에도 불구하고 IUM에서 실행할 때 얻을 수 있는 장점을 활용할 수 있도록 하는 엔클레이브 내에서 실행할 수 있는 여러 가지 기술이 여전히 있습니다.

Akamai는 VTL0 사용자 모드 메모리에 접속해 여러 유용한 기술을 구축할 수 있습니다. Akamai는 악성 엔클레이브를 대상 프로세스에 로딩해, 은밀하게 모니터링하고 민감한 정보를 훔치거나, 프로세스 내의 값을 패치해 동작을 변경할 수 있습니다.

엔클레이브를 사용해 이러한 기술을 구축하면 상당한 장점이 있습니다. 앞서 설명한 바와 같이, 엔클레이브에서 API를 트리거하면 EDR의 모니터링을 피할 수 있습니다. 이러한 기술의 메모리 접속은 엔클레이브에 의해 수행되기 때문에 보이지 않게 유지될 수 있습니다.

엔클레이브는 사용자 모드 프로세스를 ‘엔클레이브를 대신해 작동하도록’ 해, 일반적으로 불가능한 방식으로 시스템에 간접 접속할 수 있습니다. 예를 들어, 엔클레이브는 파일에서 읽고, 소켓을 생성하는 등의 작업을 수행하는 VTL0 루틴을 트리거할 수 있습니다.

이 방법으로 사용자 모드 코드를 실행하는 것은 우회 측면에서 장점이 없다는 점에 유의해야 합니다. 사용자 모드 코드는 다른 사용자 모드 코드와 마찬가지로 실행되기 때문에 EDR에 노출될 수 있습니다.

코드의 중요한 부분을 안티 디버그 체크와 함께 엔클레이브로 옮기면 동적 분석을 거의 완벽하게 방어하는 멀웨어를 만들 수 있습니다.  멀웨어는 엔클레이브를 제대로 실행하기 위해 엔클레이브에 의존하는 반면, 사용자 모드 프로세스는 엔클레이브 내부에서 실행되는 체크를 패치할 수 없습니다. 이 접근법을 올바르게 구축하면 Hyper-V 또는 보안 커널 디버그를 통해서만 무력화할 수 있습니다.

이 취약점은 공격자에게 두 가지 기능을 제공합니다(그림 16).

1. 엔클레이브 내부의 임의 쓰기: 공격자는 SealSettings 를 호출해 임의의 데이터를 암호화한 다음, UnsealSettings 를 호출해 엔클레이브 내부의 대상 주소를 가리킬 수 있습니다. 이로 인해 원래의 데이터가 엔클레이브 메모리에 기록됩니다.

2. 엔클레이브 내부 임의 읽기: 공격자는 SealSettings를 호출할 수 있으며, 엔클레이브 내부의 주소를 소스 버퍼 포인터로 제공할 수 있습니다. 이 경우 엔클레이브는 엔클레이브 메모리에서 데이터를 암호화해 공격자가 제어하는 위치에 씁니다. 그런 다음 공격자는 UnsealSettings를 호출해 데이터를 해독함으로써 엔클레이브에서 임의의 데이터를 읽을 수 있습니다.

현재로서는 아주 제한된 수의 애플리케이션이 엔클레이브를 사용하고 있습니다. 더 널리 도입되더라도 임의의 프로세스보다는 특정 프로세스에 의해서만 로딩될 것입니다. 예를 들어 calc.exe 는 VBS 엔클레이브를 로딩하지 않을 것입니다.

이 때문에, 비정상적인 엔클레이브 사용은 훌륭한 탐지 기회가 될 수 있습니다. 보안팀은 VBS 엔클레이브의 알려진 정상적인 사용 방식의 기준을 구축하고, 그 기준에서 벗어나는 모든 것을 표시함으로써 비정상적인 엔클레이브 사용을 활용해야 합니다. 엔클레이브 사용은 엔클레이브 API를 모니터링하는 것과 로딩된 엔클레이브 DLL을 탐지하는 것의 두 가지 방법으로 식별할 수 있습니다.

다음의 API는 호스팅 프로세스에 의해 VBS 엔클레이브를 관리하는 데 사용되며 이러한 엔클레이브가 로딩 중임을 나타낼 수 있습니다.

• CreateEnclave
• LoadEnclaveImageW
• InitializeEnclave
• CallEnclave
• DeleteEnclave
• TerminateEnclave

비정상적인 엔클레이브 사용을 탐지하는 또 다른 방법은 일반적으로 엔클레이브에서 사용하는 환경 DLL, 즉 Vertdll.dll 및 ucrtbase_enclave.dll의 로딩을 탐지하는 것입니다. 이러한 DLL은 엔클레이브 이외의 다른 것에 의해 사용되지 않아야 하므로, 이 DLL이 존재한다는 것은 해당 프로세스가 이를 사용할 가능성이 높다는 것을 의미합니다.

VBS 엔클레이브는 개발자들이 애플리케이션의 민감한 부분을 보호할 수 있는 놀라운 툴을 제공하지만, 방금 설명한 것처럼 위협적인 공격자가 멀웨어를 ‘보호’하는 데 사용할 수도 있습니다. 이 개념은 현재로서는 대부분 이론적인 개념이지만, 미래에 노련한 위협적 공격자가 악의적인 목적으로 VBS 엔클레이브를 사용할 가능성이 분명히 있습니다.