EDR-GhostLocker - AppLocker-Based EDR Neutralization

项目说明

GhostLocker: AppLocker-Based EDR Neutralization

Introduction

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

The concept was inspired by di, who highlighted that administrators can legitimately control any software on their systems. From that insight, I de a technique using AppLocker as a nati 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:

AppIDS Identity Service)

AppID.sys (Kernel Driver)

> Clarification:
> While AppID.sys performs rule e 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 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

Rule Criteria (AppID Attributes):

Registry Storage Locations:

Service & SYSTEM Process Enforcement (Often O)

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:

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

Enforcement Flow:

1. Windows notifies AppID driver on process creation
2. AppID.sys e 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 Dri Caveat:

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

However, extensi reveals that this telemetry becomes functionally ineffecti 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:

---

GhostLocker: Proof-of-Concept Implementation

Tool O

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

Technical Implementation Analysis

GhostLocker provides two implementation :

#### main.cpp – Dynamic Enumeration
This enumerates running processes and resol full image paths using native APIs (NtQuerySystemInformation).
The resol 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-insensiti (_wcsicmp).

Why this approach?

#### 1. Process Enumeration (FindTargetsAndQueryPaths)

#### 2. Path Resolution tion

Technical Details:

Path Con Logic:

Limitation: Hardcoded Harddisk assumption. Should be improved to dynamically resol numbers.

#### 3. PowerShell Policy Generation

The tool embeds a complete PowerShell script that:

a) Target Paths

b) Generates Dynamic Deny Rules

Key Policy Elements:

c) Policy Application

#### 4. Base64 Encoding and Execution

Technical Reasoning:

#### main_improved.cpp – Static Wildcard-Based
After clarification from di, it became clear that AppLocker path rules support wildcard matching and do not require full executable paths.

This impro removes all process enumeration and native path resolution logic and instead relies on static wildcard rules such as: *\MsMpEng.exe

---

Requirements

⚠️ Prerequisites for Successful Deployment:

---

Research Results: Real-World EDR Testing

Testing Methodology

Extensi testing was conducted against multiple commercial EDR solutions to e effecti.

Test En:

Key Findings

#### Detection Capabilities Post-Block

Beha Analysis Failure:

Management Console Perspective:

#### Kernel Dri Analysis

Despite kernel drivers continuing to run and collect telemetry data streams, the absence of userland processing components rendered collected data ineffective.

What Continues Working:

Critical Insight:

Modern EDR architecture relies on a tight coupling between kernel drivers and userland analysis engines.
Breaking this coupling effectively blinds the EDR despite continued telemetry collection.

Screenshot (Enumerating and applying the AppLocker-Policy):
<img width="3102" height="1237" alt="Screenshot 2025-12-09 153050" src=" />

Screenshot (Deactivated WinDefend):

<img width="785" height="562" alt="Screenshot 2025-12-10 092525" src=" />

<img width="1242" height="927" alt="Screenshot 2025-12-10 123246" src=" />

Screenshot of 2
<img width="2192" height="517" alt="Screenshot 2025-12-19 152900" src=" />

---

Comparison: WDAC

What is WDAC?

Windows Defender Application Control (WDAC) was introduced in Windows 10 and represents Microsoft's modern application control framework.
It enforces policies on both user-mode and kernel-mode binaries.

#### WDAC Architecture:

Core Characteristics:

WDAC Policy Storage:

WDAC as Attack : Krueger

Krueger demonstrated WDAC abuse for EDR dri:

Key Difference:

Detailed Comparison Matrix

| Feature | AppLocker | WDAC |
|---------|-----------|------|
| Enforcement Scope | User-mode executables only | User-mode + kernel-mode drivers |
| Enforcement Timing | Process creation | Boot + runtime |
| User Granularity | Per-user/group rules | System-wide |
| Default Mode | Allow-by-default | Deny-by-default |
| Rule Types | Path, Hash, Publisher | Hash, Publisher, WHQLFile, |
| Blocks Drivers | ❌ No | ✅ Yes |
| Policy Complexity | Moderate | High |
| Audit Mode | ✅ Yes | ✅ Yes |

Practical Attack Considerations

When to Use AppLocker (GhostLocker):

When to Use WDAC (Krueger-style):

---

Detection & Pre Guidance

1. Pre-Execution Policy E

Windows provides the Get-AppLockerFileInformation API, which allows testing whether a specific executable would be blocked under the current AppLocker policy.

An EDR can use this mechanism to proactively whether its own binaries or services would be denied execution after a policy change.
If a core component transitions from allowed to denied, this should be treated as a high-confidence tamper condition.

2. AppLocker Policy Change Monitoring

AppLocker policy updates are communicated to AppID.sys IOCTL calls from user mode.
This provides a clear signal path indicating that enforcement state has changed.

Kernel drivers can obser notifications and correlate them with subsequent execution failures of protected services, enabling accurate detection of policy-based neutralization.

3. Persistence and Reboot Correlation

AppLocker policies are persisted across reboots in well-defined registry locations.
EDR solutions can snapshot relevant policy state before reboot and enforcement consistency after system startup.

A mismatch between expected execution state and post-reboot enforcement strongly indicates intentional policy manipulation.

4. Built-in Exclusion Mechanisms

Windows includes nati for excluding processes from SRP/AppLocker enforcement.
Security products are expected to integrate with these mechanisms to ensure operational continuity.

Failure to account for these exclusions is not a limitation of AppLocker, but rather an architectural o in the protected product.

Summary

None of these detection strategies require bypassing AppLocker or Windows security boundaries.
They rely solely on documented behavior and interfaces already provided by the operating system.

---

Conclusion

GhostLocker demonstrates that AppLocker, a legitimate Windows security feature, can be weaponized to neutralize EDR solutions through userland process blocking.
This research highlights fundamental architectural in current EDR designs that tightly couple kernel telemetry collection with userland analysis engines.

Key Takeaways:

1. AppLocker Effecti: Successfully blocks EDR userland processes across multiple
2. Architectural : Kernel drivers continue running but become functionally blind without userland processing
3. Detection Blindness: Tested EDRs showed complete detection failure post-blocking
4. Management Console Deception: Agents appear "online" and "protected" despite compromise
5. System-Nati: Uses legitimate Windows features

For future a C# Implementation:

---

Disclaimer

This research is provided for educational and defensi purposes only.
The techniques described should only be used in authorized testing en with explicit permission.

---

References & Further Reading

---

Community Contributions Welcome

If you are interested in contributing to GhostLocker, especially to the C# implementation, you are very welcome.

---

项目信息

开发语言：C

Star 数：343

技术要点

该项目属于病毒分析方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕AppLocker-Based EDR Neutralization展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。