Windows 가상화의 심층(제2회) ── 커널에서도 보이지 않는 메모리: VBS·HVCI·Credential Guard의 구조

관리자 권한으로도 커널로도 읽을 수 없는 비밀을, Windows는 어디에 두고 있을까요. 제2회는 이 질문에서 출발해 VBS·HVCI·Credential Guard의 구조를 살펴봅니다.

기존의 Windows에서는 공격자가 관리자로 커널 드라이버를 로드하고 LSASS 프로세스의 메모리를 덤프하면, 암호 해시나 Kerberos 티켓을 훔쳐 다른 머신으로의 측면 이동에 악용할 수 있었습니다.

Credential Guard가 동작하는 Windows 11에서는, 보호 대상인 도메인 자격 증명의 해시를 일반 커널이 찾을 수 있는 곳에 두지 않습니다. Enterprise·Education 등의 라이선스 요건과 하드웨어 요건을 충족하는 장치에서는 22H2 이후 기본으로 이 보호가 켜져 있습니다.¹ 요건과 실제 동작 상태는 별개이므로, 동작하지 않는 경우의 위험이 사라진 것은 아닙니다.

제1회에서는 호스트 Windows가 하이퍼바이저 위의 루트 파티션에서 동작하는 구조를 봤습니다. 이 글에서 따라갈 것은 그 같은 파티션 안쪽에 긋는 또 하나의 경계선입니다.

「Windows 가상화의 심층」 전 3회

같은 Windows 하이퍼바이저를 기반 → 보안의 격리 → 경량 VM으로의 응용 순서로 살펴봅니다.

이 글의 전제

이 글을 읽는 방법

1. 먼저 결론

Windows는 VTL(가상 신뢰 수준)이라는 권한의 축을 추가하고, 비밀을 VTL1에 두었다. VTL0에서 동작하는 일반 커널은 VTL1의 메모리를 읽을 수 없다. 경계를 지키는 것은 커널 자신이 아니라, SLAT의 변환 테이블을 쥔 하이퍼바이저다.

이것이 가상화 기반 보안(VBS)의 골격입니다. VBS는 하이퍼바이저를 써서 격리된 환경을 만들고, 그 안에 보안 기능을 수용합니다. 커널이 침해되어도 격리 환경은 지켜진다는 전제로 설계되어 있습니다.²

flowchart TB
    accTitle: VBS가 만드는 두 세계
    accDescr: 같은 파티션 안에 VTL0과 VTL1이 있고, VTL0에는 일반 커널과 앱이, VTL1에는 보안 커널과 격리된 보안 기능이 들어가며, 경계는 하이퍼바이저가 지킵니다
    subgraph vtl0 ["VTL0(일반 세계)"]
        apps["앱(링 3)"]
        ntk["NT 커널과 드라이버(링 0)"]
    end
    subgraph vtl1 ["VTL1(격리된 세계)"]
        ium["격리된 보안 기능"]
        sk["보안 커널"]
    end
    hv["하이퍼바이저(SLAT로 경계를 강제)"] --- vtl0
    hv --- vtl1
    ntk -.->|읽기 불가| ium

그림1: 하나의 Windows 안에 두 세계가 있고, VTL0의 커널에서 VTL1의 메모리로는 접근할 수 없습니다.

「또 하나의 VM을 띄우고 있다」는 뜻이 아니라는 점이 중요합니다. VTL0과 VTL1은 같은 파티션, 같은 Windows의 안쪽에 있습니다. 이 분할이 어떻게 실현되는지를 차례로 살펴봅니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 22건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 링 모델의 한계 ── 지키는 쪽과 지켜지는 쪽이 같은 높이에 있다

기존 Windows 보안은 링(권한 수준)의 계단 위에 조립되어 있었습니다. 사용자 모드(링 3)는 커널 모드(링 0)가 지킵니다. 그렇다면 링 0은 누가 지키는가──아무도 지킬 수 없습니다. 링 0이 최고 권한이기 때문입니다.

이 구조에는 구조적인 약점이 둘 있습니다.

• 커널은 한 덩어리가 아닙니다. 링 0에서는 Windows 본체뿐 아니라 수많은 타사 드라이버가 동작합니다. 그중 하나에 취약점이 있으면, 공격자는 링 0의 코드 실행을 손에 넣습니다.
• 링 0에서는 모든 것이 보입니다. LSASS 같은 사용자 모드 프로세스가 아무리 스스로를 지켜도, 커널을 장악한 공격자에게 메모리는 읽기 자유입니다. 보호 속성과 페이지 테이블도 커널 자신이 관리하기 때문입니다.

flowchart TB
    accTitle: 기존 링 모델에서 자격 증명을 훔치는 경로
    accDescr: 취약한 드라이버를 통해 링 0을 장악한 공격자는 커널의 전 권한으로 LSASS 프로세스 메모리를 읽고 암호 해시를 얻습니다
    mal["공격자의 코드"] -->|취약한 드라이버를 악용| r0["링 0을 장악"]
    r0 --> readall["물리 메모리 전체를 읽을 수 있음"]
    readall --> lsass["LSASS 메모리에서 해시를 취득"]
    lsass --> lateral["다른 머신으로의 측면 이동에 악용"]

그림2: 지키는 쪽(커널)과 지켜지는 쪽(비밀)이 같은 높이에 있으므로, 링 0이 무너지면 모든 것이 무너진다는 점이 근본 약점입니다.

즉 필요한 것은 「링 0보다 높은 자리」입니다. 제1회에서 그 자리는 이미 등장했습니다. 하이퍼바이저는 커널보다 높은 권한에서 동작하고, CPU의 메모리 접근 허가 제어(SLAT)를 일찍 독점합니다. 하이퍼바이저가 지키는 격리 영역은 링 0(슈퍼바이저 모드)의 OS 소프트웨어로부터의 접근에 대해서도 보호됩니다.³

3. VSM과 VTL ── 권한에 축을 하나 더 더하다

이 절에서는 격리를 제공하는 기능군(VSM) → 격리의 수준(VTL) → 경계를 강제하는 구조(SLAT) → 그 안에서 동작하는 코드의 순서로 정리합니다. 이름이 비슷해도 같은 것은 아닙니다.

3.1. 가상 신뢰 수준(VTL)

이 격리를 제공하는 하이퍼바이저 기능군을 VSM(가상 보안 모드)이라고 부릅니다. VSM은 Device Guard, Credential Guard, 가상 TPM 등의 기반입니다.³

VSM의 중심 개념이 VTL(Virtual Trust Level: 가상 신뢰 수준)입니다. 요점은 다음과 같습니다.³

• VTL은 계층적이며, 번호가 클수록 권한이 높습니다. VTL0이 최하위이고, VTL1은 VTL0보다 권한이 높습니다.
• 아키텍처상 16수준까지 정의되어 있지만, 현재 구현된 것은 VTL0과 VTL1의 둘입니다.
• VTL마다 독립된 메모리 접근 보호를 가집니다. 이 보호는 하이퍼바이저가 파티션의 물리 주소 공간에 대해 관리하므로, 파티션 안의 시스템 소프트웨어는 바꿀 수 없습니다.
• 가상 프로세서는 VTL마다 별도의 레지스터 상태와 인터럽트 기구를 가지며, 낮은 VTL에서는 높은 VTL의 상태를 들여다볼 수 없습니다.

flowchart TB
    accTitle: VTL 분리를 구성하는 세 가지 독립
    accDescr: VTL마다 메모리 접근 보호, 가상 프로세서의 레지스터 상태, 인터럽트 기구가 독립되어 있으며, 낮은 VTL에서는 높은 VTL의 어느 것에도 손을 댈 수 없습니다
    vtl["VTL마다 독립된 것"] --> m1["메모리 접근 보호"]
    vtl --> m2["가상 프로세서의 레지스터 상태"]
    vtl --> m3["인터럽트 기구"]
    m1 -.-> rule["낮은 VTL에서는 높은 VTL에 손을 댈 수 없음"]
    m2 -.-> rule
    m3 -.-> rule

그림3: 메모리뿐 아니라 CPU 상태와 인터럽트까지 별세계로 만드는 것이, 들여다볼 구멍을 남기지 않기 위한 세 가지 세트입니다.

링(0과 3)이 「OS와 앱」을 나누는 축이라면, VTL은 「일반 세계와 격리 세계」를 나누는 두 번째 축입니다. 두 축은 직교하며, VTL1 안에도 커널 모드와 사용자 모드가 있습니다.

flowchart TB
    accTitle: 링과 VTL의 두 축이 만드는 네 영역
    accDescr: 링 축은 커널 모드와 사용자 모드를 나누고, VTL 축은 일반 세계와 격리 세계를 나누며, 조합하면 일반 앱, NT 커널, IUM의 트러스틀릿, 보안 커널의 네 영역이 됩니다
    subgraph ax0 ["VTL0(일반 세계)"]
        a0["링 3: 일반 앱"]
        k0["링 0: NT 커널과 드라이버"]
    end
    subgraph ax1 ["VTL1(격리 세계)"]
        a1["링 3: IUM(트러스틀릿)"]
        k1["링 0: 보안 커널"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

그림4: 권한의 축은 둘이 되었고, 「커널인가」와 「격리 세계인가」는 별개의 질문이 되었습니다.

3.2. 경계의 실체는 SLAT

제1회에서, 게스트 물리 주소(GPA)를 실제 RAM(SPA)으로 대응시키는 두 번째 변환 테이블──SLAT──은 하이퍼바이저가 쥐고 있다고 말했습니다. VSM은 바로 이 성질을 씁니다. VTL의 격리는 Hyper-V 하이퍼바이저와 SLAT를 이용해 만들어집니다.⁴

VTL1이 「이 메모리는 VTL0에 보여 주지 않는다」고 선언하면, 하이퍼바이저는 VTL0용 변환 테이블에서 그 페이지로의 접근 허가를 내립니다. 이후 VTL0의 커널이 그 주소에 손을 대려 해도, CPU의 주소 변환 단계에서 거부됩니다. 커널이 자신의 페이지 테이블을 어떻게 다시 써도 소용없습니다.

페이지 테이블(GVA→GPA)은 커널의 것이어도, 그다음 변환(GPA→SPA)과 최종 접근 허가는 하이퍼바이저의 것이기 때문입니다.

flowchart TB
    accTitle: VTL0에서 VTL1 메모리로의 접근이 거부되는 흐름
    accDescr: VTL0의 커널이 VTL1 메모리를 읽으려 하면 자신의 페이지 테이블은 통과해도 SLAT의 접근 보호에서 거부되고, 제어가 하이퍼바이저로 넘어갑니다
    try["VTL0의 커널이 VTL1 페이지를 읽으려 함"] --> pt["커널 자신의 페이지 테이블은 통과"]
    pt --> slat{"SLAT의 접근 보호는 허가하는가?"}
    slat -->|허가 없음| deny["하이퍼바이저가 개입해 접근을 거부"]
    slat -->|허가 있음| ok["보통의 메모리 접근"]
    deny -.-> point["커널이 바꿀 수 없는 층에서 지켜짐"]

그림5: 방벽은 커널 밖에 있고, SLAT의 보호는 파티션 안의 소프트웨어가 바꿀 수 없습니다.

메모리 연재 제1회에서는 「VAD와 PTE와 보호 속성이 접근 가부를 정한다」고 썼습니다. VBS 환경에서는 그 전부를 통과한 뒤에, 한 겹 더 SLAT 검문이 기다린다──고 정리할 수 있습니다.

3.3. 보안 커널과 IUM

VTL1 안에서 동작하는 것은 일반 NT 커널이 아니라, 보안 커널이라 부르는 작은 커널입니다. VTL1의 사용자 모드는 IUM(Isolated User Mode: 격리 사용자 모드)이라 불리며, 거기서 동작하는 프로그램은 트러스틀릿(신뢰된 프로세스)이라 부릅니다.⁴

트러스틀릿은 일반 프로세스처럼 무엇이든 할 수 있는 것은 아닙니다. 시스템 호출의 상당수는 VTL0 쪽 NT 커널로 마샬링해 처리를 맡깁니다.⁴ VTL1은 「무엇이든 할 수 있는 상위 세계」가 아니라, 비밀을 유지하는 금고로서 의도적으로 작게 만들어져 있습니다. 금고 안에 들여올 수 있는 코드가 적을수록, 공격면도 작아지기 때문입니다.

flowchart TB
    accTitle: 트러스틀릿의 시스템 호출 흐름
    accDescr: VTL1의 트러스틀릿은 시스템 호출의 상당수를 스스로 처리하지 않고 VTL0의 NT 커널로 마샬링해 맡기며, 결과만 받아 VTL1을 작게 유지합니다
    tl["트러스틀릿(VTL1의 IUM)"] --> sc{"시스템 호출이 필요"}
    sc -->|많은 경우| mar["VTL0의 NT 커널에 의뢰"]
    mar --> res["결과만 받음"]
    res -.-> small["VTL1 쪽은 작게 유지되어 공격면이 줄어듦"]

그림6: 금고는 자체 설비를 두지 않고, 잡무는 밖으로 맡겨 비밀만 계속 지킵니다.

4. HVCI ── 커널의 코드 무결성을 금고에서 검증하다

HVCI에서 짚어야 할 것은 검증을 어디서 하는가와 검증 후의 메모리에 무엇을 허용하는가의 두 가지입니다. 그 보호와, 드라이버 호환성에 미치는 영향을 차례로 봅니다.

4.1. 무엇을 검증하는가

VBS 위에 올라가는 대표 기능의 첫 번째가 메모리 무결성──HVCI(하이퍼바이저로 보호된 코드 무결성)입니다. Windows에는 커널 모드 드라이버와 바이너리를 기동 전에 검사해, 미서명·신뢰되지 않는 것을 로드하지 않는 코드 무결성 장치가 있습니다. HVCI는 이 검증을 VBS의 격리 환경 안에서 실행합니다.²

검증 논리 자체를 VTL1로 옮기는 이유는 제2절의 약점 그 자체입니다. 검증 코드가 VTL0의 커널 안에 있으면, 커널을 장악한 공격자는 검증을 바꿔 치울 수 있습니다. VTL1에 있으면 바꿔 치울 손이 닿지 않습니다.

flowchart TB
    accTitle: 검증 코드를 두는 자리에 따른 차이
    accDescr: 검증 코드가 VTL0의 커널 안에 있으면 커널 장악으로 무력화되지만, VTL1에 있으면 커널을 장악한 공격자에게도 손이 닿지 않아 검증이 지켜집니다
    atk["커널을 장악한 공격자"] --> q{"코드 무결성 검증은 어디에 있는가?"}
    q -->|"VTL0의 커널 안(기존)"| bad["검증 논리를 바꿔 치울 수 있음"]
    q -->|"VTL1의 격리 환경(HVCI)"| good["바꿔 치울 손이 닿지 않음"]
    bad --> res1["미서명 코드가 커널에서 실행될 수 있음"]
    good --> res2["검증은 커널 침해 후에도 계속 기능함"]

그림7: 검문소를, 뚫릴 수 있는 쪽의 안쪽에 두지 않는다──그 검증 논리의 이전이 HVCI의 본질입니다.

4.2. 실행 가능 페이지의 규칙

HVCI의 효과는 「기동 시의 검사」에 그치지 않습니다. 커널 메모리 할당에도 제약을 겁니다.⁵

• 커널 페이지는 코드 무결성 검증에 합격한 뒤에야 실행 가능해집니다.
• 실행 가능한 페이지는 쓰기 가능해지지 않습니다(이른바 W^X).

이 둘이 갖춰지면, 버퍼 오버플로 같은 취약점으로 커널 메모리를 다시 쓸 수 있어도, 다시 쓴 내용을 실행으로 옮길 수 없습니다. 실행 가능 페이지는 다시 쓸 수 없고, 다시 쓸 수 있는 페이지는 실행할 수 없기 때문입니다.⁵ 실행 허가의 최종 뒷받침은 SLAT 쪽의 실행 권한에 있으며, 이는 VTL0의 커널이 조작할 수 없습니다.

flowchart TB
    accTitle: HVCI 환경에서 커널 페이지가 실행 가능해지기까지
    accDescr: 드라이버 로드 요구는 VBS의 격리 환경에서 코드 무결성 검증을 받고, 합격하면 실행 가능하면서 쓰기 불가인 페이지로 허가되며, 불합격이면 차단되어 CodeIntegrity 로그에 기록됩니다
    load["커널 코드의 로드·실행 요구"] --> verify{"격리 환경에서의 코드 무결성 검증"}
    verify -->|합격| exec["실행 가능 페이지로 허가(쓰기는 불가)"]
    verify -->|불합격| block["로드 차단"]
    block --> log["CodeIntegrity 운영 로그에 기록(이벤트 ID 3087)"]
    exec -.-> wx["쓰기 가능한 페이지는 실행 불가로 남음"]

그림8: 실행과 쓰기를 양립시키지 않는 규칙의 검증은 VTL1 쪽에서 이루어지며, VTL0의 커널은 뒤집을 수 없습니다.

공격자의 시점에서 따라가면, 이 규칙이 어떻게 먹히는지가 잘 보입니다.

flowchart TB
    accTitle: HVCI 환경에서 코드 주입이 실패하는 흐름
    accDescr: 취약점으로 커널 메모리를 다시 써도, 쓸 수 있었던 페이지는 실행 불가이고, 실행 가능 페이지는 애초에 다시 쓸 수 없으므로, 주입한 코드를 실행으로 옮길 수 없습니다
    inj["취약점으로 커널 메모리에 손보기를 시도"] --> which{"겨냥한 페이지는 어느 쪽?"}
    which -->|쓰기 가능한 페이지| wok["다시 쓰기는 성공"]
    which -->|실행 가능한 페이지| xfail["다시 쓰기 자체가 불가"]
    wok --> nx["그러나 그 페이지는 실행 불가"]
    nx --> dead["주입 코드를 실행으로 옮길 수 없음"]
    xfail --> dead

그림9: 어느 입구로 들어가도 막다른 길이 되는 곳에, 쓸 수 있는 페이지와 실행할 수 있는 페이지를 교차시키지 않는 의미가 있습니다.

4.3. 드라이버 호환성이라는 대가

이 규칙은 옛 설계의 드라이버와 충돌합니다. 자신의 코드를 실행 중에 다시 쓴다, 서명이 없다, 실행 가능하면서 쓰기 가능한 메모리를 요구한다──그런 드라이버는 HVCI 환경에서 로드할 수 없습니다.

차단 사실은 이벤트 뷰어의 Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational(이벤트 ID 3087이 대표)에서 확인할 수 있습니다.⁶

「메모리 무결성을 켜면 주변 기기가 동작하지 않는다」는 문제의 정체는, 많은 경우 이것입니다. 대처의 본줄기는 HVCI 대응 드라이버로의 업데이트이며, 메모리 무결성 무효화는 보호를 통째로 포기하는 최후 수단으로 생각해야 합니다.

드라이버 개발 입장에서 이 검증에 관여한다면, 필터 드라이버 글(「Windows의 미니필터 드라이버」)도 참고하십시오.

flowchart TB
    accTitle: 메모리 무결성에서 주변 기기가 동작하지 않을 때의 원인 분리
    accDescr: CodeIntegrity 운영 로그로 차단된 드라이버를 특정하고, 본줄기는 HVCI 대응 버전으로의 업데이트이며, 대응 버전이 없으면 벤더에 요청하고, 무효화는 영구 설정으로 두지 않는 최후 수단으로 둡니다
    sym["메모리 무결성을 켰더니 기기가 동작하지 않음"] --> log2["CodeIntegrity 로그로 차단 원인을 특정"]
    log2 --> upd{"HVCI 대응 드라이버가 있는가?"}
    upd -->|있음| fix2["업데이트해 켠 채로 해결"]
    upd -->|없음| ask2["벤더에 대응 버전을 요청"]
    ask2 -.-> temp["무효화는 영구 설정으로 두지 않는 최후 수단"]

그림10: 먼저 볼 것은 설정 화면이 아니라 로그이며, 차단의 범인은 이벤트 ID 3087이 알고 있습니다.

5. Credential Guard ── 해시는 LSAIso 안에 있다

HVCI가 커널의 코드 무결성을 지키는 데 비해, Credential Guard는 자격 증명을 지킵니다. 인증을 받는 창구와 비밀의 보관 장소를 나누어 생각하면, 구조와 수비 범위가 이어집니다.

5.1. LSASS와 LSAIso

VBS 위에 올라가는 대표 기능의 두 번째가, 서두의 수수께끼에 대한 답인 Credential Guard입니다.

기존의 Windows는 NTLM 해시와 Kerberos 티켓 종류를 LSA 프로세스(lsass.exe)의 메모리에 유지했습니다. Credential Guard가 켜지면, 이 중 도메인 자격 증명의 NTLM 해시나 Kerberos TGT(티켓 부여 티켓)처럼 보호 대상인 비밀의 보관은 LSAIso.exe──VTL1의 IUM에서 동작하는 트러스틀릿──으로 옮겨집니다.⁷

• lsass.exe(VTL0)는 지금까지와 같이 인증 처리의 창구로 동작합니다.
• 비밀의 실체는 LSAIso.exe(VTL1)가 유지하며, VTL0에서는 접근할 수 없습니다.
• 둘은 RPC(원격 프로시저 호출)로 통신합니다.
• LSAIso는 디바이스 드라이버를 전혀 호스트하지 않고, 필요 최소한의 서명된 바이너리만 수용합니다. 서명은 VBS가 신뢰하는 인증서로 검증됩니다.⁷

flowchart TB
    accTitle: Credential Guard가 켜졌을 때 자격 증명의 배치
    accDescr: VTL0의 lsass는 인증 창구로서 RPC로 VTL1의 LSAIso와 통신하고, 보호 대상 도메인 자격 증명의 해시와 TGT 실체는 LSAIso가 유지하므로, VTL0에서 관리자 권한을 얻은 공격자가 lsass를 덤프해도 보호 대상의 실체는 얻지 못합니다
    subgraph v0 ["VTL0"]
        lsassP["lsass.exe(인증의 창구)"]
        att["공격자(관리자 권한)"]
    end
    subgraph v1 ["VTL1"]
        iso["LSAIso.exe(비밀의 금고)"]
    end
    lsassP <-->|RPC| iso
    att -->|메모리 덤프| lsassP
    att -.->|닿지 않음| iso

그림11: 창구와 금고를 분리했으므로, lsass를 덤프해도 보호 대상 도메인 자격 증명의 해시 실체는 더 이상 없습니다.

기본으로 켜지는 조건

Windows 11 버전 22H2 이후, 라이선스 요건(Enterprise E3/E5·Education A3/A5)과 하드웨어 요건을 충족하는 장치에서는 VBS와 Credential Guard가 기본으로 켜집니다. Pro 등의 에디션에서는 Credential Guard가 자동으로는 켜지지 않습니다(과거에 대상 라이선스로 켜져 있던 단말을 다운그레이드한 경우 등 예외는 있습니다).¹

이 자격 증명 보호는 특별한 추가 제품 이야기가 아니라, 대상 에디션의 현행 Windows 표준 상태입니다.

flowchart TB
    accTitle: 로그인부터 인증까지의 자격 증명 흐름
    accDescr: 로그인 후 비밀의 실체는 VTL1의 LSAIso에 보관되고, 인증이 필요할 때마다 VTL0의 lsass가 RPC로 연산을 의뢰하며, 보호 대상인 장기 비밀 자체는 반환되지 않은 채 인증 처리 결과만 VTL0으로 돌아갑니다
    signin["사용자가 로그인"] --> front["lsass가 창구로 처리"]
    front --> store["비밀의 실체는 LSAIso에 보관"]
    auth["이후의 인증 요구"] --> front
    front -->|RPC로 연산을 의뢰| store
    store -->|"처리 결과를 반환(비밀은 반환하지 않음)"| front

그림12: 보호 대상인 장기 비밀 자체는 금고에서 나오지 않고, VTL0으로 돌아오는 것은 티켓 등 인증 처리의 결과입니다.

5.2. 지켜지지 않는 것을 정확히 알기

보호되는 자격 증명

Credential Guard는 만능 방패가 아닙니다. 보호되는 것은 도메인 자격 증명의 NTLM 해시, Kerberos TGT(티켓 부여 티켓), 도메인 자격 증명으로 저장된 것입니다.

보호 대상이 아닌 것

다음과 같은 것은 대상 밖입니다.⁸

• Kerberos의 서비스 티켓(TGT는 보호됩니다)
• 로컬 계정과 Microsoft 계정의 자격 증명
• 키로거에 의한 입력 시 탈취, 물리 공격
• NTLMv1·MS-CHAPv2·Digest·CredSSP를 쓰는 경로의 자격 증명
• 자격 증명을 독자로 관리하는 타사 소프트웨어의 내부

보호 범위와는 별개로, 인증 호환성도 확인한다

또한 Credential Guard가 켜진 상태에서는 NTLMv1이나 Kerberos의 비제한 위임 등을 쓸 수 없게 되므로, 레거시 인증에 의존하는 업무 시스템에서는 호환성 확인이 필요합니다.⁸ 「켜고 끝」이 아니라, 수비 범위의 안팎을 파악하고 나머지는 다른 대책으로 메운다──이것이 실무에서의 올바른 사용법입니다.

flowchart TB
    accTitle: Credential Guard의 수비 범위
    accDescr: 도메인의 NTLM 해시와 TGT, 저장된 도메인 자격 증명은 보호되는 반면, 서비스 티켓, 로컬 계정, 키로거, 물리 공격, 앱이 독자로 저장한 자격 증명은 보호 대상 밖입니다
    scope{"그 비밀은 수비 범위의 어느 쪽인가?"} --> inA["도메인의 NTLM 해시·TGT"]
    scope --> outA["서비스 티켓이나 로컬 계정"]
    inA --> prot["LSAIso에서 보호됨"]
    outA --> unprot["보호되지 않음(다른 대책이 필요)"]
    unprot -.-> outB["키 입력·물리 공격·앱 독자 저장도 대상 밖"]

그림13: 수비 범위는 분명히 선이 그어져 있으며, 선 바깥은 다요소 인증이나 앱 쪽 설계로 메웁니다.

6. 직접 확인해 보기

VBS와 각 기능의 동작 상태는 지금 쓰는 기기에서 확인할 수 있습니다. VBS라는 기반의 상태와, 그 위에서 동작하는 서비스의 상태를 나누어 읽습니다.

6.1. PowerShell로 VBS와 실행 중인 서비스를 확인한다

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus,
                  SecurityServicesConfigured,
                  SecurityServicesRunning

보는 방법은 다음과 같습니다.⁹

• VirtualizationBasedSecurityStatus가 2이면 VBS가 켜져 있고 동작 중입니다.
• SecurityServicesRunning에 1이 포함되면 Credential Guard, 2가 포함되면 메모리 무결성(HVCI)이 동작 중입니다.

6.2. msinfo32와 설정 화면을 구분해 읽는다

GUI로 동작 상태를 확인하려면 msinfo32의 「가상화 기반 보안」란을 봅니다(실행 중인 서비스로 「하이퍼바이저로 강제되는 코드 무결성」 등이 열거됩니다).

Windows 보안 앱의 「장치 보안 > 핵심 격리」에 있는 「메모리 무결성」 토글은 설정을 비추는 화면이라, 켠 직후의 재시작 대기나 시작 시 호환성 문제로 HVCI가 실제로는 돌고 있지 않은 동안에도 켜진 것처럼 보일 수 있으므로, 동작 중인지의 판정은 msinfo32 또는 Win32_DeviceGuard의 SecurityServicesRunning으로 합니다.⁶

6.3. 프로세스의 유무만으로 동작 중이라 판단하지 않는다

작업 관리자의 자세히 탭에도 흔적이 있습니다. VBS가 동작하는 머신에는 「보안 시스템」(Secure System)이라는 프로세스가 보입니다. LsaIso.exe는 격리 LSA 서비스가 VTL1에서 호스트될 때 나타나는 프로세스이며, HVCI만 켠 구성에서는 보통 나타나지 않습니다.

다만 프로세스의 유무는 어디까지나 흔적이므로, Credential Guard가 동작 중인지의 판정은 앞에서 말한 SecurityServicesRunning(1을 포함하는지)으로 합니다. 둘 다 VTL1 쪽 세계에 대응하는, VTL0에서 보이는 창입니다.

flowchart TB
    accTitle: VBS 관련 기능의 동작 확인 절차
    accDescr: Win32_DeviceGuard 조회로 VBS 동작을 확인하고, SecurityServicesRunning 값으로 Credential Guard와 HVCI 동작을 판정하며, 드라이버 문제는 CodeIntegrity 로그를 보는 흐름
    q0["Win32_DeviceGuard를 조회"] --> q1{"VBS의 Status는 2인가?"}
    q1 -->|아니요| off["VBS 미동작(요건과 설정을 확인)"]
    q1 -->|예| q2{"SecurityServicesRunning의 값은?"}
    q2 -->|1을 포함| cg["Credential Guard 동작 중"]
    q2 -->|2를 포함| hvciR["메모리 무결성(HVCI) 동작 중"]
    hvciR -.-> ev["드라이버 문제는 CodeIntegrity 로그(3087)를 확인"]

그림14: 상태 확인은 VBS 본체, 그 위의 각 서비스, 문제 발생 시의 로그의 세 단계로 진행합니다.

7. 실무에서 피하고 싶은 세 가지 오해

7.1. 「관리자 권한만 지키면 충분하다. VBS는 서버 이야기다」

Credential Guard가 막는 것은 관리자 권한을 빼앗긴 뒤의 피해 확대(해시 반출과 측면 이동)입니다. 즉 VBS는 침해를 전제로 한 다층 방어의 한 겹이며, 클라이언트 PC에서야말로 효과가 있습니다. 요건을 충족하는 Windows 11에서는 기본 사용이 표준이므로, 「우리와는 상관없다」가 아니라 「이미 동작 중이라는 전제로 호환성을 관리한다」가 올바른 자세입니다.

flowchart TB
    accTitle: 침해의 단계와 VBS가 효과를 내는 자리
    accDescr: 초기 침입은 다요소 인증이나 교육 등 다른 대책이 맡고, 권한 상승 너머의 커널 코드 주입은 HVCI가 막으며, 보호 대상 도메인 비밀의 탈취와 측면 이동은 Credential Guard가 막지만, 보호 대상 밖 비밀에는 미치지 않습니다
    s1["초기 침입(피싱 등)"] --> s2["권한 상승"]
    s2 --> s3["커널로의 코드 주입"]
    s3 --> s4["보호 대상 도메인 비밀의 탈취와 측면 이동"]
    s1 -.-> d1["MFA·교육·EDR이 맡음"]
    s3 -.-> d2["HVCI가 여기를 막음"]
    s4 -.-> d3["Credential Guard가 막음(보호 대상만)"]

그림15: VBS는 「침입시키지 않는」 기술이 아니라, 지키는 단계가 다른 「침입 후에 이기지 못하게 하는」 기술입니다.

7.2. 「메모리 무결성에서 문제가 나면 끄면 된다」

끄면 당장은 동작하지만, 커널로의 코드 주입에 대한 방벽을 통째로 벗기는 일이 됩니다. 먼저 CodeIntegrity 로그로 차단된 드라이버를 특정하고, 벤더의 업데이트 버전을 적용하는 것이 본줄기입니다. 검증용으로 일시적으로 끄는 경우에도, 영구 설정으로 두지 않는 운영을 권장합니다.

7.3. 「Credential Guard가 있으면 암호는 훔치지 못한다」

수비 범위를 혼동한 과신입니다. 서비스 티켓, 로컬 계정, 키 입력 그 자체, 앱이 독자로 저장한 자격 증명은 대상 밖입니다.⁸ 피싱이나 키로거에는 다른 대책(다요소 인증, Windows Hello, 앱 쪽 자격 증명 관리의 재검토)이 필요합니다.

8. 정리

• VBS는 하이퍼바이저로 격리 환경을 만들고, 커널 침해를 전제로 보안 기능을 지킵니다.²
• 격리의 단위는 VTL이며, 현재는 VTL0(일반 세계)과 VTL1(보안 커널과 IUM)의 두 수준이 구현되어 있습니다.³
• 경계의 실체는 SLAT의 메모리 접근 보호이며, 파티션 안의 소프트웨어──커널을 포함──는 바꿀 수 없습니다.³
• HVCI는 코드 무결성 검증을 격리 환경에서 수행하고, 「검증 합격까지 실행 불가」「실행 가능 페이지는 쓰기 불가」를 강제합니다.⁵ 대가로서 드라이버 호환성 관리가 필요합니다.⁶
• Credential Guard는 도메인 자격 증명의 NTLM 해시와 TGT를 VTL1의 LSAIso로 격리합니다. Windows 11 22H2 이후, 라이선스 요건(Enterprise·Education)과 하드웨어 요건을 충족하는 장치에서는 기본으로 켜집니다(동작 상태 확인과 함께 사용합니다).⁷¹
• 동작 상태는 Win32_DeviceGuard의 SecurityServicesRunning(1=Credential Guard, 2=HVCI)으로 확인할 수 있습니다.⁹

이어지는 글은 제3회 「몇 초 만에 시작되는 가상 머신 ── WSL2·Windows Sandbox·컨테이너」입니다.

여기까지는 가상화를 「격리의 강도」 쪽에서 봤습니다. 마지막 회는 반대로 「가벼움」 쪽에서, 풀 VM의 무게를 버린 경량 VM들이 어디서 힘을 빼고 있는지를 따라갑니다.

관련 글

• Windows 가상화의 심층(제1회) ── 지금 쓰는 Windows는 어디에서 실행되는가: 하이퍼바이저와 파티션
• Windows 메모리의 심층(제1회) ── 가상 주소가 물리 RAM으로 바뀌는 순간: 페이지 폴트의 전말
• Windows의 미니필터 드라이버
• Windows의 오류 코드 체계 ── Win32·HRESULT·NTSTATUS

관련 상담 영역

고무라소프트 합동회사에서는 Windows 애플리케이션과 보안 기능의 호환성 조사, 드라이버에서 비롯된 장애 분석, 사내 PC 환경의 기술 검증을 다룹니다.

• Windows 앱 개발
• 장애 조사·원인 분석
• 기존 자산 활용·마이그레이션 지원
• 문의

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

VBS(가상화 기반 보안)와 핵심 격리는 같은 것인가요?

엄밀히는 다릅니다. VBS는 하이퍼바이저로 격리 환경을 만드는 기반 기술이고, Windows 보안 앱의 「핵심 격리」는 VBS 위에 성립하는 여러 보호 기능을 묶은 화면 이름입니다. 대표가 「메모리 무결성」이며, HVCI(하이퍼바이저로 보호된 코드 무결성)를 가리킵니다. 개별 서비스의 동작 상태는 화면이 아니라 Win32_DeviceGuard 조회로 확인합니다.

VTL1 메모리는 관리자 권한으로도, 커널 드라이버로도 정말 읽을 수 없나요?

읽을 수 없습니다. VTL마다의 메모리 접근 보호는 하이퍼바이저가 파티션의 물리 주소 공간에 대해 관리하며, 파티션 안에서 동작하는 소프트웨어는 바꿀 수 없기 때문입니다. 커널(링 0)에서 동작하는 코드라도, VTL0에서 VTL1 메모리로의 접근은 허용되지 않습니다.

메모리 무결성(HVCI)을 켜면 드라이버가 동작하지 않는 경우가 있는 이유는 무엇인가요?

HVCI 환경에서는 커널 페이지가 무결성 검증을 통과한 뒤에야 실행 가능해지고, 실행 가능 페이지에 대한 쓰기는 허용되지 않습니다. 서명 없는 드라이버나, 실행 가능 메모리를 다시 쓰는 옛 설계의 드라이버는 이 제약에 맞지 않아 로드가 차단됩니다. 차단 기록은 CodeIntegrity 운영 로그(이벤트 ID 3087 등)에서 확인할 수 있습니다.

Credential Guard는 무엇을 지키고, 무엇을 지키지 않나요?

도메인 자격 증명의 NTLM 암호 해시, Kerberos TGT, 앱이 도메인 자격 증명으로 저장한 것을 격리 환경에서 보호합니다. 반면 Kerberos 서비스 티켓, 로컬 계정과 Microsoft 계정의 자격 증명, 키로거에 의한 입력 탈취, 물리 공격은 보호 대상이 아닙니다.

VBS가 동작 중인지는 어디서 확인할 수 있나요?

msinfo32의 「가상화 기반 보안」란, 또는 PowerShell로 root/Microsoft/Windows/DeviceGuard 네임스페이스의 Win32_DeviceGuard 클래스를 조회합니다. SecurityServicesRunning에 1이 포함되면 Credential Guard, 2가 포함되면 메모리 무결성(HVCI)이 동작 중입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.