Extending EDR Logs with Microsoft Defender for Endpoint Custom Data Collection

EDR solutions like Microsoft Defender for Endpoint (MDE) analyze behavior across multiple monitoring points in a system, but when it comes to log "storage," they typically filter and save only what appears "important." Without this filtering, log volumes would become unmanageable. While this approach is rational from bandwidth and storage cost perspectives, it may not fully address organization-specific monitoring requirements. Recently, MDE introduced a Custom Data Collection feature in preview that enables capturing logs that weren't previously collected. This article provides a brief overview.¹

Important Notes

• This article was written based on information as of January 6, 2026.
• Some information in this article relates to prerelease products that may be substantially modified before general availability.

What is Custom Data Collection?

Simply put, it's a feature that lets you "specify and record events that MDE would normally discard." Typically, MDE observes massive amounts of events across various system layers—kernel drivers, AMSI, and more—but storing everything in the cloud isn't feasible. Microsoft selects and formats only events deemed "likely important" for storage. This mechanism is similar across most EDR solutions.

While this filtering works well for general threats, it may discard necessary events when monitoring organization-specific application behavior. Additionally, "Living off the Land" attacks that abuse legitimate tools exploit blind spots in standard configurations. Custom Data Collection addresses these scenarios where events are "generally noise but signal in our environment."

Limitations

• License requirement: MDE P2 or M365 E5 is mandatory. P1 is not supported.
• Microsoft Sentinel integration is required: Collected data is sent directly to Sentinel's Log Analytics workspace, not the standard Defender portal. Since forced integration is coming in June 2026 anyway, this may not be a major concern.
• Collection limits: Maximum 25,000 events per rule per device per 24 hours. Loose filters can quickly hit this limit and stop collection.
• OS support: Windows 10/11 and Windows Server 2019/2022 only.

Supported Event Tables and Schemas

Custom Data Collection doesn't indiscriminately collect all system events. Currently, five specific categories are supported, each mapping to a unique table in Sentinel.¹

DeviceCustomScriptEvents deserves special attention. This table has no corresponding equivalent in the standard Advanced Hunting schema and represents a powerful capability unique to Custom Data Collection. While Advanced Hunting's DeviceProcessEvents captures command-line arguments for process launches, and MDE saves some scripts (filtered by high threat scores or alert associations) visible in alert screens as shown below, not all script executions are recorded. Scripts deemed benign or not triggering detections tend to be dropped to save storage capacity. (Note)

:::note alert
Note: To my understanding, executed script information is analyzed by MDE and viewable only when Defender raises an alert, and is not saved as Advanced Hunting logs. However, I couldn't find official documentation directly supporting this understanding. If anyone knows of such documentation or recognizes this as incorrect, I'd appreciate kind corrections.
:::

By utilizing the DeviceCustomScriptEvents table, you can explicitly preserve audit trails for specific interpreters and script files. This is presumed to leverage mechanisms like AMSI (Antimalware Scan Interface) to obtain decoded script content, offering the powerful advantage of viewing executed scripts, as described below.

Verification: Visualizing PowerShell Obfuscation

Let's simulate a common attacker technique and compare how it appears in the standard "DeviceProcessEvents" versus "Custom Data Collection (DeviceCustomScriptEvents)." The scenario involves "PowerShell Base64 obfuscation (EncodedCommand)," which attackers use to evade detection.

Background and Challenge

Attackers attempt to hide their commands to evade security monitoring. One popular method is Base64 encoding using PowerShell's -EncodedCommand option.

:::alert
This is a simplified demo. Real attacks use far more complex obfuscation.
:::

Standard MDE logs (DeviceProcessEvents) record the fact that a process launched, but the arguments (command line) appear as the attacker-concealed "meaningless alphanumeric string." While Defender analyzes the decoded version in the backend² and preserves evidence as alerts when deemed dangerous, events that don't trigger alerts are discarded, leaving only the obfuscated version.

:::alert
As repeatedly stated, backend decoding and MDE analysis occur. The issue is whether it's preserved as Advanced Hunting logs.
:::

DeviceCustomScriptEvents enables explicitly preserving audit trails for specific interpreters and script files. This presumably references AMSI buffers internally, offering the powerful advantage of viewing deobfuscated code, as described below.

Demo Scenario

Let's execute the following PowerShell command and compare log appearances. This scenario displays a harmless message simulating "Mimikatz execution," with the command concealed via Base64. While not particularly attack-like, it's clear for demonstration purposes.

Command before obfuscation:

# Just a message display command
powershell.exe -Command "Write-Host '【DEMO】Critical Alert: Mimikatz Execution Detected!' -ForegroundColor Red; Start-Sleep -Seconds 10"

How it appears in Defender portal (before obfuscation):

Test command to execute (obfuscated):

# Command to hide (payload)
$OriginalCommand = "Write-Host '【DEMO】Critical Alert: Mimikatz Execution Detected!' -ForegroundColor Red; Start-Sleep -Seconds 10"
# Convert command to Base64 (obfuscation)
$Bytes = [System.Text.Encoding]::Unicode.GetBytes($OriginalCommand)
$EncodedCommand = [System.Convert]::ToBase64String($Bytes)
# Execute in obfuscated state (this is the attack command logged)
Write-Host "Executing command: powershell.exe -EncodedCommand $EncodedCommand" -ForegroundColor Yellow
powershell.exe -EncodedCommand $EncodedCommand

Standard Log (DeviceProcessEvents) Appearance:
In existing process monitoring logs, it's recorded as follows:

It shows powershell.exe -EncodedCommand VwByAGkAdABlAC0ASABvAHMAdAAg..., making content auditing impossible. Note that DeviceProcessEvents only records new process launches, so commands within the encoding PowerShell session ($Bytes assignment, Base64 conversion, etc.) aren't recorded. These are in-process operations not involving process launches.

Custom Data Collection Configuration³

As prerequisite setup, integrate Sentinel with Defender portal.

Then configure collection conditions via [Defender Portal] > [Settings] > [Endpoints] > [Custom Data Collection] and save. For this verification, I set very broad log collection.

Custom Data Collection (DeviceCustomScriptEvents) Appearance

After enabling, logs showed the script immediately before execution recorded in Advanced Hunting. Interestingly, in-session commands not recorded in DeviceProcessEvents ($Bytes assignment, Base64 conversion, etc.) were recorded in DeviceCustomScriptEvents. This is because DeviceCustomScriptEvents captures entire code executed within PowerShell sessions through script execution monitoring mechanisms like AMSI, rather than process launch events.

Collecting All Logs = Fast Track to Bankruptcy

Custom Data Collection can skyrocket costs if used carelessly. Unlike flat-rate Advanced Hunting, Sentinel log ingestion is pay-as-you-go, making "collect everything" thinking dangerous. (Limits prevent full collection anyway...) Additionally, don't underestimate the volume of logs that weren't previously saved—Advanced Hunting already handles massive log volumes. Use wisely and plan accordingly.

Distinction from Azure Monitor Agent (AMA)

• TBD

Other Use Cases

While this article focused on PowerShell deobfuscation, DeviceCustomScriptEvents appears powerful for diverse scenarios. However, validation of effective scenarios including costs remains incomplete, so I'll update progressively or write separate posts.

Summary

Microsoft Defender for Endpoint's Custom Data Collection feature powerfully illuminates previously "black box" areas. While requiring balance with costs (Sentinel log ingestion volume), those interested should consider starting small with limited scope—critical assets or administrative endpoints—as a pilot.

1. Custom data collection in Microsoft Defender for Endpoint (preview) ↩

2. Antimalware Scan Interface (AMSI) ↩

3. https://learn.microsoft.com/en-us/defender-endpoint/create-custom-data-collection-rules ↩