GhostLocker: AppLocker-Based EDR Neutralization

Introduction

After my article on Fairy-Law, where I used kernel mitigations to disable Endpoint Detection & Response (EDR) solutions, diversenok pointed out that IFEO exclusions (Image File Execution Options) were too invasive for third-party applications. This led to a better approach: leveraging the inherent power administrators already possess through AppLocker.

The concept was inspired by diversenok, who highlighted that administrators can legitimately control any software on their systems. From that insight, I developed a technique using AppLocker as a native Windows control mechanism. This research explores the technical implementation of AppLocker for EDR control, comparing it with WDAC and presenting a practical proof-of-concept tool.

---

AppLocker: Application Whitelisting Architecture

AppLocker was introduced with Windows 7 and enhanced in Windows 8.1, 10 (Enterprise) and Windows Server 2012/R2/2016+. It is an application whitelisting framework that allows administrators to define precisely which executables, scripts, or installers may execute for specific users or groups.

Internal Architecture (Windows Internals Perspective)

User-Mode & Kernel Components:

AppIDSvc (Application Identity Service)

• Runs under LocalService account
• Monitors registry changes to AppLocker policy paths
• Translates XML-based rule definitions into binary SDDL (Security Descriptor Definition Language)
• Communicates policy updates to kernel driver via DeviceIoControl

AppID.sys (Kernel Driver)

• Intercepts process creation events through callback mechanisms
• Performs rule evaluation using SeSrpAccessCheck
• Optionally monitors DLL loads (disabled by default for performance reasons)

Clarification:
While AppID.sys performs rule evaluation in kernel mode, DLL enforcement is not autonomous.
The kernel driver does not actively monitor DLL loads by itself. Instead, user-mode components must explicitly query the driver via IOCTL to determine whether a DLL load is permitted.
As a result, AppLocker DLL rules effectively act as a client-side protection mechanism.

Rule Types and Enforcement

AppLocker supports two primary rule categories:

Allow Rules: Explicitly permit defined applications to execute

Deny Rules: Explicitly block defined applications from executing

• Deny rules always take precedence over allow rules
• Can include exceptions for specific conditions
• Support user and group-level targeting

Rule Criteria (AppID Attributes):

• Path-based rules: C:\Program Files\Security\*.exe
• Hash-based rules: SHA256 Authenticode hash validation
• Publisher rules: Digital signature, version, product name verification
• File attribute rules: Company name, product version, etc.

Registry Storage Locations:

HKLM\Software\Policies\Microsoft\Windows\SrpV2     (XML policy storage, persistent)
HKLM\SYSTEM\CurrentControlSet\Control\Srp\Gp\Exe  (SDDL binary format, active enforcement)
HKLM\SYSTEM\CurrentControlSet\Control\AppID\CertStore (Certificate cache)

Service & SYSTEM Process Enforcement (Often Overlooked)

By default, AppLocker does not enforce rules on services or SYSTEM processes.
There is no graphical user interface option to enable this behavior.

Enforcement for services can only be enabled via the XML policy using RuleCollectionExtensions.

The following policy section is required to enforce AppLocker rules on services:

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

As indicated by the extension names, these options are supported only on Windows 10+ and are not available on earlier versions. See Microsoft - AppLocker rule collection extensions

Enforcement Flow:

1. Windows notifies AppID driver on process creation
2. AppID.sys evaluates application attributes
3. Based on AppLocker rules, it allows or blocks the process
4. If blocked, process creation is aborted with STATUS_ACCESS_DISABLED_BY_POLICY_OTHER

Critical Limitation:

⚠️ AppLocker does NOT terminate running processes.

AppLocker enforcement only applies to new process creation events. Already-running EDR processes continue executing until system reboot. This is a fundamental architectural constraint.

Kernel Driver Telemetry Caveat:

Even after blocking EDR userland executables, kernel drivers (*.sys) remain active and operational. These drivers continue:

• Registering kernel callbacks (process, thread, image load, registry)
• Collecting telemetry data
• Monitoring system events

However, extensive testing reveals that this telemetry becomes functionally ineffective. Without userland analysis engines, correlation systems, and reporting mechanisms, the raw telemetry data cannot be processed into actionable detections. EDR solutions rely heavily on userland components for:

• Event correlation and behavioral analysis
• Machine learning inference
• Alert generation and response orchestration
• Communication with management consoles

---

GhostLocker: Proof-of-Concept Implementation

Tool Overview

GhostLocker is a C++ implementation that automates AppLocker policy deployment to block EDR executables.

Technical Implementation Analysis

Implementation Variants

GhostLocker provides two implementation variants:

main.cpp – Dynamic Enumeration Version

This version enumerates running processes and resolves their full image paths using native APIs (NtQuerySystemInformation).
The resolved absolute paths are then used to generate precise AppLocker deny rules.

The tool uses CreateToolhelp32Snapshot with TH32CS_SNAPPROCESS to enumerate all running processes. It compares process names against a predefined target list using case-insensitive matching (_wcsicmp).

Why this approach?

• Lightweight and fast enumeration
• No elevated privileges required for reading process list
• Case-insensitive matching handles naming variations

1. Process Enumeration (FindTargetsAndQueryPaths)

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

2. Path Resolution via 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
);

Technical Details:

• Uses undocumented SystemProcessIdInformation (0x58) information class
• Returns NT device path format: \Device\HarddiskVolume3\Windows\System32\...
• Requires conversion to Win32 path format for AppLocker compatibility

Path Conversion Logic:

std::wstring ForceHarddiskVolumeToC(const std::wstring& ntPath)
{
    const std::wstring prefix = L"\\Device\\HarddiskVolume3\\";
    if (ntPath.rfind(prefix, 0) == 0)
    {
        std::wstring rest = ntPath.substr(prefix.length());
        return L"C:\\" + rest;
    }
    return ntPath;
}

Limitation: Hardcoded HarddiskVolume3 assumption. Should be improved to dynamically resolve volume numbers.

3. PowerShell Policy Generation

The tool embeds a complete PowerShell script that:

a) Validates Target Paths

foreach ($exe in $ExeToBlock) {
    if (!(Test-Path $exe)) {
        Write-Host '[!] ERROR: File does not exist:' $exe -ForegroundColor Red
        exit 1
    }
}