GhostLocker: нейтрализация EDR на основе AppLocker

Введение

После моей статьи о Fairy-Law, где я использовал средства ядра для отключения решений Endpoint Detection & Response (EDR), diversenok указал, что исключения IFEO (Image File Execution Options) слишком инвазивны для сторонних приложений. Это привело к более удачному подходу: использованию той силы, которой администраторы уже легитимно обладают через AppLocker.

Концепция была вдохновлена diversenok, который подчеркнул, что администраторы могут легитимно контролировать любое программное обеспечение в своих системах. На основе этого наблюдения я разработал технику, использующую AppLocker как нативный механизм управления Windows. Данное исследование рассматривает техническую реализацию AppLocker для управления EDR, сравнивает её с WDAC и представляет практический proof-of-concept инструмент.

---

AppLocker: архитектура включения приложений в белый список

AppLocker был представлен в Windows 7 и расширен в Windows 8.1, 10 (Enterprise) и Windows Server 2012/R2/2016+. Это среда включения приложений в белый список, которая позволяет администраторам точно определять, какие исполняемые файлы, скрипты или установщики могут выполняться для конкретных пользователей или групп.

Внутренняя архитектура (с точки зрения внутренностей Windows)

Компоненты пользовательского режима и ядра:

AppIDSvc (служба удостоверения приложений)

• Выполняется под учётной записью LocalService
• Отслеживает изменения реестра в путях политик AppLocker
• Преобразует XML-определения правил в двоичный формат SDDL (Security Descriptor Definition Language)
• Передаёт обновления политик драйверу ядра через DeviceIoControl

AppID.sys (драйвер ядра)

• Перехватывает события создания процессов через механизмы обратных вызовов
• Выполняет оценку правил с помощью SeSrpAccessCheck
• Опционально отслеживает загрузку DLL (отключено по умолчанию из соображений производительности)

Уточнение:
Хотя AppID.sys выполняет оценку правил в режиме ядра, принудительное применение правил для DLL не является автономным.
Драйвер ядра сам по себе не отслеживает загрузку DLL активно. Вместо этого компоненты пользовательского режима должны явно запрашивать драйвер через IOCTL, чтобы определить, разрешена ли загрузка DLL.
Таким образом, правила AppLocker для DLL фактически действуют как клиентский механизм защиты.

Типы правил и их применение

AppLocker поддерживает две основные категории правил:

Разрешающие правила: явно разрешают выполнение определённых приложений

Запрещающие правила: явно блокируют выполнение определённых приложений

• Запрещающие правила всегда имеют приоритет над разрешающими
• Могут включать исключения для конкретных условий
• Поддерживают нацеливание на уровне пользователей и групп

Критерии правил (атрибуты AppID):

• Правила на основе пути: C:\Program Files\Security\*.exe
• Правила на основе хэша: проверка подлинности хэша SHA256 Authenticode
• Правила издателя: проверка цифровой подписи, версии, имени продукта
• Правила атрибутов файлов: имя компании, версия продукта и т.д.

Расположение хранилища в реестре:

HKLM\Software\Policies\Microsoft\Windows\SrpV2     (хранилище XML-политик, постоянное)
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  (двоичный формат SDDL, активное применение)
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore (кэш сертификатов)

Применение к службам и процессам SYSTEM (часто упускается из виду)

По умолчанию AppLocker не применяет правила к службам или процессам SYSTEM.
В графическом интерфейсе нет опции для включения такого поведения.

Применение правил к службам можно включить только через XML-политику с помощью RuleCollectionExtensions.

Следующий раздел политики необходим для применения правил AppLocker к службам:

<RuleCollectionExtensions>
  <ThresholdExtensions>
    <Services EnforcementMode="Enabled"/>
  </ThresholdExtensions>
  <RedstoneExtensions>
    <SystemApps Allow="Enabled"/>
  </RedstoneExtensions>
</RuleCollectionExtensions>

Как указано в названиях расширений, эти опции поддерживаются только в Windows 10+ и недоступны в более ранних версиях. См. Microsoft — расширения коллекций правил AppLocker

Процесс применения правил:

1. Windows уведомляет драйвер AppID о создании процесса
2. AppID.sys оценивает атрибуты приложения
3. На основе правил AppLocker разрешает или блокирует процесс
4. В случае блокировки создание процесса прерывается с ошибкой STATUS_ACCESS_DISABLED_BY_POLICY_OTHER

Критическое ограничение:

⚠️ AppLocker НЕ завершает работающие процессы.

Применение правил AppLocker распространяется только на события создания новых процессов. Уже запущенные процессы EDR продолжают выполняться до перезагрузки системы. Это фундаментальное архитектурное ограничение.

Примечание о телеметрии драйверов ядра:

Даже после блокировки исполняемых файлов EDR в пользовательском режиме драйверы ядра (*.sys) остаются активными и работоспособными. Эти драйверы продолжают:

• Регистрировать обратные вызовы ядра (процессы, потоки, загрузка образов, реестр)
• Собирать данные телеметрии
• Отслеживать системные события

Однако обширное тестирование показывает, что такая телеметрия становится функционально неэффективной. Без аналитических движков пользовательского режима, систем корреляции и механизмов отчётности, необработанные данные телеметрии не могут быть обработаны в действующие обнаружения. Решения EDR в значительной степени полагаются на компоненты пользовательского режима для:

• Корреляции событий и поведенческого анализа
• Машинного обучения и вывода
• Генерации оповещений и оркестрации реагирования
• Связи с консолями управления

---

GhostLocker: реализация Proof-of-Concept

Обзор инструмента

GhostLocker — это реализация на C++, которая автоматизирует развёртывание политик AppLocker для блокировки исполняемых файлов EDR.

Анализ технической реализации

Варианты реализации

GhostLocker предоставляет два варианта реализации:

main.cpp — версия с динамическим перечислением

Эта версия перечисляет запущенные процессы и определяет их полные пути к образам с помощью нативных API (NtQuerySystemInformation).
Полученные абсолютные пути затем используются для генерации точных запрещающих правил AppLocker.

Инструмент использует CreateToolhelp32Snapshot с TH32CS_SNAPPROCESS для перечисления всех запущенных процессов. Он сравнивает имена процессов с предопределённым списком целей, используя сравнение без учёта регистра (_wcsicmp).

Почему такой подход?

• Лёгкое и быстрое перечисление
• Для чтения списка процессов не требуются повышенные привилегии
• Сравнение без учёта регистра обрабатывает вариации имён

1. Перечисление процессов (FindTargetsAndQueryPaths)

const wchar_t* targetNames[] = {
    L"MpDefenderCoreService.exe",
    L"MsMpEng.exe",
    L"WinDefend.exe",
    L"EDR_Component_Name.exe",
};

2. Определение пути через NtQuerySystemInformation

SYSTEM_PROCESS_ID_INFORMATION spi = { 0 };
spi.ProcessId = PID;
spi.ImageName.MaximumLength = 1024;
spi.ImageName.Buffer = (PWSTR)allocBuffer;

status = NtQuerySystemInformation(
    SystemProcessIdInformation,
    &spi,
    sizeof(spi),
    0
);

Технические детали:

• Используется недокументированный класс информации SystemProcessIdInformation (0x58)
• Возвращает путь в формате NT-устройства: \Device\HarddiskVolume3\Windows\System32\...
• Требуется преобразование в формат пути Win32 для совместимости с AppLocker