DE1.12b Sysmon as Alternative Telemetry

The MDE-to-Sysmon translation table

Every Defender for Endpoint table used in DE3-DE8 has a Sysmon equivalent:

Figure DE1.12b — MDE to Sysmon mapping. Every MDE table has a Sysmon or Security log equivalent.

Translating a DE rule: worked example

DE8-002 (WMI Remote Execution) in MDE KQL:

1
2
3
4
5

// ORIGINAL (MDE): DE8-002
DeviceProcessEvents
| where InitiatingProcessFileName =~ "wmiprvse.exe"
| where FileName !in~ ("wmiprvse.exe", "WmiApSrv.exe")
| where AccountName !endswith "$"

Translated to Sysmon (Event ID 1):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// SYSMON TRANSLATION: DE8-002
Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1  // Process Create
| extend ProcessData = parse_xml(EventData)
| extend
    ParentImage = tostring(ProcessData.DataItem.EventData.Data[20].["#text"]),
    Image = tostring(ProcessData.DataItem.EventData.Data[4].["#text"]),
    User = tostring(ProcessData.DataItem.EventData.Data[12].["#text"])
| where ParentImage endswith "wmiprvse.exe"
| where not(Image endswith "wmiprvse.exe" or Image endswith "WmiApSrv.exe")
| where not(User endswith "$")

The translation requires: (1) changing the table from DeviceProcessEvents to Event (where Sysmon events are stored), (2) filtering for Sysmon Event ID 1, (3) parsing the XML EventData structure to extract the equivalent fields (ParentImage = InitiatingProcessFileName, Image = FileName, User = AccountName).

The Sysmon tax: Sysmon stores event data as XML within the EventData field. Every query must parse this XML, which adds computational overhead and query complexity compared to MDE’s pre-parsed columnar format. This is the performance cost of using Sysmon instead of MDE.

Sysmon configuration for DE rule coverage

Not all Sysmon Event IDs are enabled by default. A Sysmon configuration file must explicitly enable the events needed for DE rule translation:

1
2
3
4
5
6
7
8

// SYSMON CONFIG AUDIT: Which Event IDs are being collected?
Event
| where Source == "Microsoft-Windows-Sysmon"
| where TimeGenerated > ago(1d)
| summarize EventCount = count() by EventID
| sort by EventID asc
// Required for DE rules: 1, 3, 5, 7, 11, 12, 13, 14, 23
// If any are missing: update the Sysmon configuration XML

Recommended Sysmon configs for DE coverage: SwiftOnSecurity’s sysmon-config (community standard, good baseline) or Olaf Hartong’s sysmon-modular (modular approach, more granular control). Either provides the Event IDs needed for DE rule translation.

Troubleshooting

“Sysmon Event ID 1 is generating millions of events per day.” Sysmon process creation events include EVERY process on EVERY device. Apply Sysmon configuration filters to exclude known-good processes (e.g., exclude svchost.exe spawning expected children). Without filtering, Sysmon ingestion can exceed MDE ingestion costs.

Sysmon Event ID deep dive: what each event captures

The DE rule library uses 5 core MDE tables. Each maps to specific Sysmon Event IDs with distinct field structures:

Sysmon Event ID 1 (Process Create) — replaces DeviceProcessEvents: Captures: every process creation including full command line, parent process, user context, process hash, and current directory. This is the HIGHEST-VALUE Sysmon event for detection engineering — it powers DE5 (persistence/execution), DE6 (discovery/evasion), and DE8 (lateral movement) rules. The ProcessCommandLine field in MDE maps to the CommandLine field in Sysmon Event ID 1.

Critical difference from MDE: Sysmon Event ID 1 stores data as XML within the EventData field. Extracting individual fields requires XML parsing:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// SYSMON EVENT ID 1: Extracting process creation fields
// Compare with MDE: DeviceProcessEvents | project FileName, ProcessCommandLine
Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1
| parse EventData with * '<Data Name="Image">' Image '</Data>' *
| parse EventData with * '<Data Name="CommandLine">' CommandLine '</Data>' *
| parse EventData with * '<Data Name="ParentImage">' ParentImage '</Data>' *
| parse EventData with * '<Data Name="User">' User '</Data>' *
| parse EventData with * '<Data Name="ParentCommandLine">' ParentCommandLine '</Data>' *
| parse EventData with * '<Data Name="Hashes">' Hashes '</Data>' *
| project TimeGenerated, Image, CommandLine, ParentImage, User, Hashes

The parse operator extracts named XML elements efficiently. This pattern should be saved as a KQL function (SysmonProcessCreate()) to avoid repeating the XML parsing in every rule.

Sysmon Event ID 3 (Network Connection) — replaces DeviceNetworkEvents: Captures: outbound TCP/UDP connections including source/destination IP, port, process, and user. Required for DE7-007 (C2 beaconing detection). Important: Sysmon Event ID 3 is DISABLED by default in most Sysmon configurations due to high volume. Must be explicitly enabled in the Sysmon XML config with appropriate filtering (exclude known-good destinations).

Sysmon Event ID 7 (Image Load) — replaces DeviceImageLoadEvents: Captures: DLL loads including the loaded image path, hash, and the loading process. Required for DE5-012 (DLL sideloading detection). Also disabled by default — generates extremely high volume. Enable with strict path-based filtering (only log loads from non-standard directories).

Sysmon Event ID 11 (File Create) — replaces DeviceFileEvents: Captures: file creation events including the target filename, creation time, and the process that created the file. Required for DE7-003 (file discovery), DE7-004 (USB operations), DE7-009 (data staging). Moderate volume — enable with extension-based filtering (log only crown jewel extensions: .dwg, .step, .iges, .xlsx, .docx, .pdf).

Sysmon Event ID 12/13/14 (Registry) — replaces DeviceRegistryEvents: Captures: registry key/value creation (12), modification (13), and rename (14). Required for DE5-006 (registry run key persistence). Low-to-moderate volume — enable for HKLM\Software\Microsoft\Windows\CurrentVersion\Run and related persistence locations.

The Sysmon KQL function library

To avoid repeating XML parsing in every rule, create reusable KQL functions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

// SYSMON FUNCTION: SysmonProcessCreate()
// Save as a function in Sentinel for reuse across all translated rules
let SysmonProcessCreate = () {
    Event
    | where Source == "Microsoft-Windows-Sysmon"
    | where EventID == 1
    | parse EventData with * '<Data Name="Image">' Image '</Data>' *
    | parse EventData with * '<Data Name="CommandLine">' CommandLine '</Data>' *
    | parse EventData with * '<Data Name="ParentImage">' ParentImage '</Data>' *
    | parse EventData with * '<Data Name="User">' User '</Data>' *
    | parse EventData with * '<Data Name="ParentCommandLine">' ParentCmdLine '</Data>' *
    | parse EventData with * '<Data Name="OriginalFileName">' OriginalFileName '</Data>' *
    | project TimeGenerated, Computer, Image, CommandLine,
        ParentImage, User, ParentCmdLine, OriginalFileName
};
// Usage in translated rules:
// SysmonProcessCreate | where Image endswith "wmiprvse.exe"

With this function saved, translating DE rules becomes straightforward — replace DeviceProcessEvents with SysmonProcessCreate() and rename fields (FileName → Image, InitiatingProcessFileName → ParentImage, ProcessCommandLine → CommandLine, AccountName → User).

Performance comparison: MDE vs Sysmon in Sentinel

Query performance: MDE’s DeviceProcessEvents table uses a columnar storage format optimised for KQL queries. Each field (FileName, ProcessCommandLine, etc.) is a native column — no parsing required. Sysmon events are stored in the generic Event table with all data packed into the EventData XML field. Every query must parse this XML, adding 3-5x query execution time compared to native MDE queries.

Ingestion volume: Sysmon typically generates 20-40% MORE events than MDE for the same endpoint because Sysmon’s filtering is less granular than MDE’s cloud-side filtering. This means higher Sentinel ingestion costs for Sysmon-based environments.

Detection latency: MDE events reach Sentinel within 2-5 minutes of occurrence (cloud-to-cloud pipeline). Sysmon events must traverse: local event log → AMA agent → DCR → Sentinel workspace. This adds 5-15 minutes of latency depending on the AMA agent’s upload frequency configuration.

Recommendation for hybrid environments: If budget permits, use MDE for corporate workstations (P2 devices) and Sysmon for devices where MDE is not available (Linux servers, non-E5 endpoints, contractor devices). The DE rules run against MDE tables for MDE-enrolled devices and against the Sysmon function library for Sysmon-enrolled devices. A UNION query combines both:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// HYBRID DETECTION: DE8-002 across MDE and Sysmon sources
let mdeResults = DeviceProcessEvents
    | where InitiatingProcessFileName =~ "wmiprvse.exe"
    | where FileName !in~ ("wmiprvse.exe", "WmiApSrv.exe")
    | project TimeGenerated, DeviceName, FileName, AccountName, Source = "MDE";
let sysmonResults = SysmonProcessCreate()
    | where ParentImage endswith "wmiprvse.exe"
    | where not(Image endswith "wmiprvse.exe" or Image endswith "WmiApSrv.exe")
    | project TimeGenerated, DeviceName = Computer, FileName = Image,
        AccountName = User, Source = "Sysmon";
union mdeResults, sysmonResults

This union query provides DE8-002 detection across BOTH telemetry sources in a single analytics rule.

Sysmon deployment considerations for NE’s P1 devices

NE’s 58 P1 manufacturing workstations in Sheffield and Sunderland do not have Defender for Endpoint P2. These devices represent the CHAIN-FACTORY attack surface — the exact devices that need endpoint telemetry for detection. Deploying Sysmon to P1 devices fills this gap at zero licensing cost.

Deployment method: Group Policy deployment of the Sysmon installer + configuration XML. The configuration uses the SwiftOnSecurity template with NE-specific additions: Event ID 1 (process creation) with exclusions for known manufacturing application processes, Event ID 11 (file creation) filtered to crown jewel extensions (.dwg, .step, .iges), and Event ID 3 (network connections) filtered to non-manufacturing subnets only.

Collection path: Sysmon writes to the Microsoft-Windows-Sysmon/Operational event log. The AMA agent collects from this log and forwards to the Sentinel workspace via a dedicated DCR. The DCR applies additional filtering to reduce volume — dropping routine process creation events from known-good manufacturing applications while preserving all events from cmd.exe, powershell.exe, and other detection-relevant processes.

Expected volume: 58 P1 devices × approximately 500 Sysmon events/device/day = 29,000 events/day. At approximately 1 KB per event: 29 MB/day additional ingestion. Cost: approximately $0.12/day ($3.75/month) — negligible compared to the detection value gained.