GhostLocker: Neutralización de EDR basada en AppLocker

Introducción

Tras mi artículo sobre Fairy-Law, donde usé mitigaciones del kernel para deshabilitar soluciones de Detección y Respuesta de Puntos Finales (EDR), diversenok señaló que las exclusiones IFEO (Image File Execution Options) eran demasiado invasivas para aplicaciones de terceros. Esto llevó a un mejor enfoque: aprovechar el poder inherente que los administradores ya poseen a través de AppLocker.

El concepto fue inspirado por diversenok, quien destacó que los administradores pueden controlar legítimamente cualquier software en sus sistemas. A partir de esa idea, desarrollé una técnica que utiliza AppLocker como mecanismo de control nativo de Windows. Esta investigación explora la implementación técnica de AppLocker para el control de EDR, comparándola con WDAC y presentando una herramienta práctica de prueba de concepto.

---

AppLocker: Arquitectura de Lista Blanca de Aplicaciones

AppLocker se introdujo con Windows 7 y se mejoró en Windows 8.1, 10 (Enterprise) y Windows Server 2012/R2/2016+. Es un marco de lista blanca de aplicaciones que permite a los administradores definir con precisión qué ejecutables, scripts o instaladores pueden ejecutarse para usuarios o grupos específicos.

Arquitectura Interna (Perspectiva de Windows Internals)

Componentes de Modo Usuario y Kernel:

AppIDSvc (Servicio de Identidad de Aplicaciones)

• Se ejecuta bajo la cuenta LocalService
• Monitorea cambios en el registro en las rutas de política de AppLocker
• Traduce definiciones de reglas basadas en XML a SDDL binario (Security Descriptor Definition Language)
• Comunica las actualizaciones de políticas al controlador del kernel mediante DeviceIoControl

AppID.sys (Controlador del Kernel)

• Intercepta eventos de creación de procesos a través de mecanismos de callback
• Evalúa reglas usando SeSrpAccessCheck
• Opcionalmente monitorea cargas de DLL (deshabilitado por defecto por razones de rendimiento)

Aclaración:
Si bien AppID.sys realiza la evaluación de reglas en modo kernel, la ejecución de DLL no es autónoma.
El controlador del kernel no monitorea activamente las cargas de DLL por sí mismo. En su lugar, los componentes de modo usuario deben consultar explícitamente al controlador mediante IOCTL para determinar si se permite la carga de una DLL.
Como resultado, las reglas de DLL de AppLocker actúan efectivamente como un mecanismo de protección del lado del cliente.

Tipos de Reglas y Ejecución

AppLocker soporta dos categorías principales de reglas:

Reglas de Permiso: Permiten explícitamente la ejecución de aplicaciones definidas.

Reglas de Denegación: Bloquean explícitamente la ejecución de aplicaciones definidas.

• Las reglas de denegación siempre tienen prioridad sobre las reglas de permiso.
• Pueden incluir excepciones para condiciones específicas.
• Soportan segmentación a nivel de usuario y grupo.

Criterios de Regla (Atributos de AppID):

• Reglas basadas en ruta: C:\Program Files\Security\*.exe
• Reglas basadas en hash: Validación de hash SHA256 de Authenticode
• Reglas de editor: Firma digital, versión, verificación de nombre de producto
• Reglas de atributos de archivo: Nombre de compañía, versión del producto, etc.

Ubicaciones de Almacenamiento en el Registro:

HKLM\Software\Policies\Microsoft\Windows\SrpV2     (Almacenamiento de política XML, persistente)
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  (Formato binario SDDL, aplicación activa)
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore (Caché de certificados)

Ejecución en Servicios y Procesos del Sistema (A menudo Pasada por Alto)

Por defecto, AppLocker no aplica reglas en servicios o procesos del sistema.
No hay una opción de interfaz gráfica para habilitar este comportamiento.

La ejecución para servicios solo se puede habilitar mediante la política XML usando RuleCollectionExtensions.

La siguiente sección de política es necesaria para aplicar reglas de AppLocker en servicios:

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

Como indican los nombres de las extensiones, estas opciones solo son compatibles con Windows 10+ y no están disponibles en versiones anteriores. Consulte Microsoft - Extensiones de colección de reglas de AppLocker

Flujo de Ejecución:

1. Windows notifica al controlador AppID sobre la creación de un proceso.
2. AppID.sys evalúa los atributos de la aplicación.
3. Según las reglas de AppLocker, permite o bloquea el proceso.
4. Si se bloquea, la creación del proceso se aborta con STATUS_ACCESS_DISABLED_BY_POLICY_OTHER

Limitación Crítica:

⚠️ AppLocker NO termina procesos en ejecución.

La ejecución de AppLocker solo se aplica a eventos de creación de nuevos procesos. Los procesos EDR que ya estén en ejecución continúan funcionando hasta que se reinicie el sistema. Esta es una restricción arquitectónica fundamental.

Advertencia sobre la Telemetría del Controlador del Kernel:

Incluso después de bloquear los ejecutables de espacio de usuario de EDR, los controladores del kernel (*.sys) permanecen activos y operativos. Estos controladores continúan:

• Registrando callbacks del kernel (procesos, hilos, carga de imágenes, registro)
• Recolectando datos de telemetría
• Monitoreando eventos del sistema

Sin embargo, pruebas exhaustivas revelan que esta telemetría se vuelve funcionalmente ineficaz. Sin los motores de análisis de espacio de usuario, los sistemas de correlación y los mecanismos de reporte, los datos de telemetría sin procesar no pueden convertirse en detecciones procesables. Las soluciones EDR dependen en gran medida de los componentes de espacio de usuario para:

• Correlación de eventos y análisis de comportamiento
• Inferencia de aprendizaje automático
• Generación de alertas y orquestación de respuesta
• Comunicación con consolas de gestión

---

GhostLocker: Implementación de Prueba de Concepto

Resumen de la Herramienta

GhostLocker es una implementación en C++ que automatiza el despliegue de políticas de AppLocker para bloquear ejecutables de EDR.

Análisis de la Implementación Técnica

Variantes de Implementación

GhostLocker proporciona dos variantes de implementación:

main.cpp – Versión de Enumeración Dinámica

Esta versión enumera los procesos en ejecución y resuelve sus rutas de imagen completas usando APIs nativas (NtQuerySystemInformation).
Las rutas absolutas resueltas se utilizan luego para generar reglas de denegación precisas de AppLocker.

La herramienta usa CreateToolhelp32Snapshot con TH32CS_SNAPPROCESS para enumerar todos los procesos en ejecución. Compara los nombres de los procesos contra una lista objetivo predefinida usando coincidencia sin distinción de mayúsculas/minúsculas (_wcsicmp).

¿Por qué este enfoque?

• Enumeración ligera y rápida
• No se requieren privilegios elevados para leer la lista de procesos
• La coincidencia sin distinción de mayúsculas/minúsculas maneja variaciones de nombres

1. Enumeración de Procesos (FindTargetsAndQueryPaths)

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

2. Resolución de Rutas mediante NtQuerySystemInformation

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