Глубины виртуализации Windows (часть 2) — память, которую не видит даже ядро: как устроены VBS, HVCI и Credential Guard

Куда Windows кладёт секреты, которые не прочитать ни администратору, ни ядру? Часть 2 начинается с этого вопроса и следит, как работают VBS, HVCI и Credential Guard.

На традиционном Windows атакующий, который загрузил драйвер ядра от имени администратора и снял дамп памяти процесса LSASS, мог украсть хеши паролей и билеты Kerberos и использовать их для поперечного перемещения на другие машины.

На Windows 11, где работает Credential Guard, хеши защищаемых учётных данных домена нигде не лежат так, чтобы обычное ядро могло их искать. На устройствах, которые удовлетворяют лицензионным требованиям (Enterprise, Education и подобные) и аппаратным требованиям, эта защита по умолчанию включена начиная с 22H2.¹ Требования и фактическое состояние работы — разные вещи, поэтому там, где она не работает, прежняя опасность никуда не делась.

Часть 1 показала структуру, в которой хостовый Windows работает в корневом разделе поверх гипервизора. Что разбирает эта статья — ещё одна граница, проведённая уже внутри того же раздела.

«Глубины виртуализации Windows» — все 3 части

Один и тот же гипервизор Windows смотрим в порядке основа → изоляция безопасности → применение к лёгким ВМ.

Что предполагает эта статья

Как читать эту статью

1. Сначала вывод

Windows добавила ось привилегий под названием VTL (Virtual Trust Level) и положила секреты в VTL1. Обычное ядро, которое работает в VTL0, не может прочитать память VTL1. Границу держит не само ядро, а гипервизор, у которого таблицы трансляции SLAT.

Это каркас безопасности на основе виртуализации (VBS). VBS с помощью гипервизора создаёт изолированную среду и размещает там функции безопасности. Замысел такой: даже если ядро скомпрометировано, изолированная среда остаётся защищённой.²

flowchart TB
    accTitle: Два мира, которые создаёт VBS
    accDescr: Внутри одного раздела есть VTL0 и VTL1; в VTL0 — обычное ядро и приложения, в VTL1 — Secure Kernel и изолированные функции безопасности; границу обеспечивает гипервизор
    subgraph vtl0 ["VTL0 (обычный мир)"]
        apps["Приложения (кольцо 3)"]
        ntk["Ядро NT и драйверы (кольцо 0)"]
    end
    subgraph vtl1 ["VTL1 (изолированный мир)"]
        ium["Изолированные функции безопасности"]
        sk["Secure Kernel"]
    end
    hv["Гипервизор (обеспечивает границу через SLAT)"] --- vtl0
    hv --- vtl1
    ntk -.->|Читать нельзя| ium

Рис. 1: Внутри одного Windows два мира, и ядро VTL0 не может обратиться к памяти VTL1.

Важно, что это не «ещё одна виртуальная машина». 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. Гипервизор работает с привилегией выше ядра и с самого начала эксклюзивно управляет правами доступа к памяти ЦП (SLAT). Изолированная область, которую охраняет гипервизор, защищена даже от доступа со стороны системного ПО режима супервизора (кольцо 0).³

3. VSM и VTL — добавить ещё одну ось привилегий

Этот раздел идёт в порядке набор функций, который даёт изоляцию (VSM) → уровни изоляции (VTL) → механизм, который держит границу (SLAT) → код, который работает внутри. Имена похожи, но это не одно и то же.

3.1. Виртуальные уровни доверия (VTL)

Набор функций гипервизора, который даёт эту изоляцию, называется VSM (Virtual Secure Mode). VSM — основа для Device Guard, Credential Guard, виртуального TPM и подобных.³

Центральное понятие VSM — VTL (Virtual Trust Level). Ключевые пункты такие.³

• VTL иерархичны, и чем больше номер, тем выше привилегия. VTL0 — самый низкий; VTL1 привилегированнее VTL0.
• Архитектурно определено до 16 уровней, но сейчас реализованы два: VTL0 и VTL1.
• У каждого 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: Сделать отдельным миром не только память, но и состояние ЦП и прерывания — набор из трёх частей, который не оставляет глазка.

Если кольца (0 и 3) — ось, которая отделяет «ОС и приложения», VTL — вторая ось, которая отделяет «обычный мир и изолированный мир». Две оси ортогональны, и внутри VTL1 тоже есть режим ядра и пользовательский режим.

flowchart TB
    accTitle: Четыре области, которые создают две оси колец и VTL
    accDescr: Ось колец отделяет режим ядра от пользовательского режима, ось VTL отделяет обычный мир от изолированного, и сочетание даёт четыре области: обычные приложения, ядро NT, трастлеты IUM и Secure Kernel
    subgraph ax0 ["VTL0 (обычный мир)"]
        a0["Кольцо 3: обычные приложения"]
        k0["Кольцо 0: ядро NT и драйверы"]
    end
    subgraph ax1 ["VTL1 (изолированный мир)"]
        a1["Кольцо 3: IUM (трастлеты)"]
        k1["Кольцо 0: Secure Kernel"]
    end
    a0 --- k0
    a1 --- k1
    k0 ~~~ a1

Рис. 4: Теперь две оси привилегий, и «это ядро?» и «это изолированный мир?» стали разными вопросами.

3.2. Суть границы — SLAT

Часть 1 говорила, что таблицы трансляции второго уровня, которые отображают гостевые физические адреса (GPA) на фактическую ОЗУ (SPA), то есть SLAT, держит гипервизор. VSM пользуется именно этим свойством. Изоляция VTL строится с помощью гипервизора Hyper-V и SLAT.⁴

Когда VTL1 объявляет «эту память VTL0 не показывать», гипервизор снимает право доступа к этой странице из таблиц трансляции VTL0. С тех пор, даже если ядро VTL0 пытается тронуть этот адрес, ему отказывают на этапе трансляции адресов ЦП. Неважно, как ядро переписывает свои собственные таблицы страниц.

Таблицы страниц (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. Secure Kernel и IUM

Что работает внутри VTL1 — не обычное ядро NT, а маленькое ядро под названием Secure Kernel. Пользовательский режим в VTL1 называется IUM (Isolated User Mode), а программы, которые там работают, — трастлеты (доверенные процессы).⁴

Трастлет не может делать что угодно так, как обычный процесс. Большинство его системных вызовов маршализуются ядру NT на стороне VTL0, которому поручают работу.⁴ VTL1 — не «верхний мир, который может всё»; его нарочно делают маленьким, как хранилище, которое держит секреты. Чем меньше кода можно внести в хранилище, тем меньше поверхность атаки.

flowchart TB
    accTitle: Поток системных вызовов трастлета
    accDescr: Трастлет в VTL1 большинство системных вызовов сам не обрабатывает; он маршализует их ядру NT в VTL0 и получает только результат, поэтому VTL1 остаётся маленьким
    tl["Трастлет (IUM в VTL1)"] --> sc{"Нужен системный вызов"}
    sc -->|В большинстве случаев| mar["Просит ядро NT в VTL0"]
    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 Operational (событие 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 (событие 3087 — характерное).⁶

Во многих случаях именно это стоит за жалобой «после того как я включил целостность памяти, периферия перестала работать». Правильное исправление — обновить драйвер до версии, совместимой с HVCI; отключение целостности памяти следует считать последним средством, которое целиком сдаёт защиту.

Если вы участвуете в этой проверке со стороны разработки драйверов, см. также статью о драйверах-фильтрах («Минифильтры Windows»).

flowchart TB
    accTitle: Разбор, когда периферия перестаёт работать при целостности памяти
    accDescr: Определить заблокированный драйвер в журнале CodeIntegrity Operational; правильное исправление — обновить до версии, совместимой с HVCI, спросить у поставщика, если её нет, и считать отключение последним средством, которое никогда не делают постоянной настройкой
    sym["Устройство перестаёт работать после включения целостности памяти"] --> log2["Определить заблокированный драйвер в журнале CodeIntegrity"]
    log2 --> upd{"Есть драйвер, совместимый с HVCI?"}
    upd -->|Да| fix2["Обновить и закрыть, оставив HVCI включённым"]
    upd -->|Нет| ask2["Попросить у поставщика совместимую версию"]
    ask2 -.-> temp["Отключение — последнее средство, никогда не постоянная настройка"]

Рис. 10: Первое, на что смотреть, — не экран настроек, а журнал, и событие 3087 знает, какой драйвер заблокировали.

5. Credential Guard — хеши внутри LSAIso

Где HVCI охраняет целостность кода ядра, Credential Guard охраняет учётные данные. Мыслите приёмную, которая принимает аутентификацию, и место, где хранятся секреты, как две разные вещи — и устройство, и область защиты встанут на место.

5.1. LSASS и LSAIso

Вторая характерная функция, которая сидит на VBS, — ответ на загадку вступления: Credential Guard.

Традиционный Windows держал хеши NTLM и билеты Kerberos в памяти процесса LSA (lsass.exe). Когда Credential Guard включён, хранение защищаемых среди них секретов — хешей NTLM учётных данных домена и TGT Kerberos (Ticket Granting Tickets) — переезжает в LSAIso.exe, трастлет, который работает в IUM в VTL1.⁷

• lsass.exe (VTL0) продолжает работать как приёмная обработки аутентификации, как раньше.
• Фактические секреты держит LSAIso.exe (VTL1), и из VTL0 к ним доступа нет.
• Двое общаются через RPC (Remote Procedure Call).
• LSAIso не размещает драйверы устройств вовсе и держит только минимальный набор подписанных двоичных файлов. Подписи проверяются по сертификату, которому доверяет VBS.⁷

flowchart TB
    accTitle: Где лежат учётные данные, когда Credential Guard включён
    accDescr: lsass в VTL0 как приёмная аутентификации общается с LSAIso в VTL1 через RPC; фактические хеши и 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 VBS и Credential Guard по умолчанию включены на устройствах, которые удовлетворяют лицензионным требованиям (Enterprise E3/E5, Education A3/A5) и аппаратным требованиям. На редакциях вроде Pro Credential Guard автоматически не включают (есть исключения, например машина, которую включили под подходящей лицензией в прошлом и затем понизили).¹

Эта защита учётных данных — не вопрос особого дополнительного продукта; это стандартное состояние актуального Windows на подходящих редакциях.

flowchart TB
    accTitle: Поток учётных данных от входа до аутентификации
    accDescr: После входа фактические секреты хранятся в LSAIso в VTL1; каждый раз, когда нужна аутентификация, lsass в VTL0 запрашивает вычисление через RPC, и в VTL0 возвращается только результат обработки аутентификации, без самих защищаемых долгоживущих секретов
    signin["Пользователь входит"] --> front["lsass обрабатывает как приёмная"]
    front --> store["Фактические секреты хранятся в LSAIso"]
    auth["Позднейшие запросы аутентификации"] --> front
    front -->|Запрашивает вычисление через RPC| store
    store -->|"Возвращает результат (никогда секрет)"| front

Рис. 12: Сами защищаемые долгоживущие секреты никогда не покидают хранилище; что возвращается в VTL0 — результат обработки аутентификации, например билет.

5.2. Точно знать, что не защищается

Учётные данные, которые защищаются

Credential Guard — не универсальный щит. Что он защищает — хеши NTLM учётных данных домена, TGT Kerberos (Ticket Granting Tickets) и всё, что сохранено как учётные данные домена.

Вне области

Следующее в область не входит.⁸

• Служебные билеты Kerberos (TGT защищаются)
• Учётные данные локальных учётных записей и учётных записей Майкрософт
• Кража ввода кейлоггером и физические атаки
• Учётные данные на путях, которые используют 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. Проверить VBS и работающие службы в PowerShell

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 и экран настроек по-разному

Чтобы проверить состояние работы в графическом интерфейсе, смотрите поле «Безопасность на основе виртуализации» в msinfo32 (там перечислены работающие службы, например «Целостность кода, принудительно применяемая гипервизором»).

Переключатель «Целостность памяти» в «Безопасность устройства > Изоляция ядра» в приложении «Безопасность Windows» — экран, который отражает настройку. Он может выглядеть включённым, пока HVCI на деле не работает, например пока ждётся перезагрузка сразу после включения или когда при старте есть проблема совместимости, поэтому работаете ли вы судите по msinfo32 или по SecurityServicesRunning в Win32_DeviceGuard.⁶

6.3. Не судите «работает» только по наличию процесса

Есть и след на вкладке «Подробности» Диспетчера задач. На машине, где работает VBS, вы увидите процесс «Secure System». LsaIso.exe — процесс, который появляется, когда служба Isolated LSA размещена в VTL1, и в конфигурации, где включён только HVCI, он обычно не появляется.

Наличие или отсутствие процесса — только след, поэтому работает ли Credential Guard судите по SecurityServicesRunning (содержит ли 1), как выше. Оба — окна, видимые из VTL0, в мир на стороне VTL1.

flowchart TB
    accTitle: Порядок проверки, что функции, связанные с VBS, работают
    accDescr: Подтвердить, что VBS работает, запросом к Win32_DeviceGuard, судить, работают ли Credential Guard и HVCI, по значениям SecurityServicesRunning, и смотреть журнал CodeIntegrity при проблемах с драйверами
    q0["Запросить Win32_DeviceGuard"] --> q1{"Статус VBS равен 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 — один слой защиты в глубину, который предполагает компрометацию, и окупается он на клиентских ПК. На 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 (Secure Kernel и IUM).³
• Суть границы — защита доступа к памяти SLAT, которую программное обеспечение внутри раздела, включая ядро, не меняет.³
• HVCI выполняет проверку целостности кода в изолированной среде и принуждает «не исполняемо, пока проверка не прошла» и «исполняемые страницы не записываемы».⁵ Цена — нужно управлять совместимостью драйверов.⁶
• Credential Guard изолирует хеши NTLM и TGT учётных данных домена в LSAIso в VTL1. Начиная с Windows 11 22H2 он по умолчанию включён на устройствах, которые удовлетворяют лицензионным требованиям (Enterprise, Education) и аппаратным требованиям (используйте это вместе с проверкой состояния работы).⁷¹
• Состояние работы можно проверить по SecurityServicesRunning в Win32_DeviceGuard (1 = Credential Guard, 2 = HVCI).⁹

Продолжение — часть 3, «Виртуальные машины, которые загружаются за секунды — WSL2, Windows Sandbox и контейнеры».

До сих пор мы смотрели на виртуализацию со стороны «силы изоляции». Финальный выпуск смотрит с противоположной стороны, «лёгкости», и следит, где лёгкие ВМ, которые сбросили вес полной ВМ, срезают углы.

Похожие статьи

• Глубины виртуализации Windows (часть 1) — где на самом деле работает ваш Windows: гипервизор и разделы
• Глубины памяти Windows (часть 1) — момент, когда виртуальный адрес становится физической ОЗУ: ошибка страницы от начала до конца
• Глубины ввода-вывода Windows (часть 6, финал) — фильтры и минифильтры: почему Procmon и антивирусное сканирование могут перехватывать I/O
• Как читать коды ошибок Windows — Win32, HRESULT и NTSTATUS

Смежные области консультирования

KomuraSoft LLC занимается расследованием совместимости Windows-приложений с функциями безопасности, анализом сбоев, вызванных драйверами, и технической проверкой внутренних ПК-сред.

• Разработка Windows-приложений
• Расследование сбоев и анализ причин
• Использование и миграция существующих активов
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Одно и то же ли VBS (безопасность на основе виртуализации) и изоляция ядра?

Строго говоря, нет. VBS — базовая технология, которая с помощью гипервизора создаёт изолированную среду. «Изоляция ядра» в приложении «Безопасность Windows» — название экрана, на котором собраны несколько механизмов защиты, построенных поверх VBS. Главный из них — «Целостность памяти»: так в интерфейсе называется HVCI (целостность кода, защищённая гипервизором). Работает ли конкретная служба, смотрите не по экрану, а запросом к Win32_DeviceGuard.

Память VTL1 действительно нельзя прочитать даже с правами администратора и из драйвера ядра?

Нельзя. Защиту доступа к памяти для каждого VTL задаёт гипервизор на физическом адресном пространстве раздела; программное обеспечение внутри раздела её не меняет. Даже коду, который выполняется в ядре (кольцо 0), доступ из VTL0 к памяти VTL1 запрещён.

Почему после включения целостности памяти (HVCI) драйвер иногда перестаёт работать?

В среде HVCI страница ядра становится исполняемой только после успешной проверки целостности, а запись в исполняемые страницы запрещена. Неподписанный драйвер или драйвер старой конструкции, который патчит исполняемую память, этим правилам не удовлетворяет, и загрузка блокируется. Факт блокировки смотрите в журнале CodeIntegrity Operational (событие 3087 и соседние).

Что защищает Credential Guard и чего не защищает?

В изолированной среде он защищает NTLM-хеши паролей учётных данных домена, TGT Kerberos и то, что приложения сохранили как учётные данные домена. Служебные билеты Kerberos, учётные данные локальных учётных записей и учётных записей Майкрософт, перехват ввода кейлоггером и физические атаки в область защиты не входят.

Где проверить, что VBS работает?

Поле «Безопасность на основе виртуализации» в msinfo32 либо класс Win32_DeviceGuard в пространстве имён root/Microsoft/Windows/DeviceGuard через PowerShell. Если в SecurityServicesRunning есть 1 — работает Credential Guard; если есть 2 — работает целостность памяти (HVCI).

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.